how on earth does openssh not only have incredibly fucked versioning but is the only package i've ever seen to mention a "privilege separation" chroot path which actively breaks non-root builds. are you fucking kidding me bruh. "privilege separation chroot" defaulting to /var/empty and it immediately errors if it can't create it????? why are your version strings like that bruh?????
137
Replies
·
0
Boosts
ok so python sucks. it sucks terribly. however i think returning int would be a reasonable API for a lot of compiled languages
obviously it would be neat if the bit width were a compile-time generic instead. but i think you do have to be careful here, because the reason making your hash function conform to the standard mathematical definition of a hash function over bit strings is so that the user can meaningfully influence not just the collision rate "averaged" across "all" inputs (literally never defined), but how known ranges of inputs spread across the output bits
i was going to say "rust's type system literally can't do that API" but i think you can do fn hash<const N: usize>(&self) -> [u8; N] in a trait. you can't do const fn hash on stable, so you can't do this in a library, because rust fucking hates its users, but you can do it in a library inside google
anyway, what rust does instead is pretty great because it's deeply fucking mysterious, has a confusing and nonstandard signature, and absolutely 100000% ensures you cannot meaningfully influence which bits of output correspond to which bits of input
it's been several months since i last considered this problem and i'm delighted to find not only was i right before to say "cryptographic hashes are unnecessary computation for 100% of hash tables because the threat model is obviously fucked", but it's also now very clear to me that hash tables have COMPLETELY distinct goals for hashing than cryptographic message digests
in fact, i think i'm literally not going to call them hash functions at all, but message digests
the fact that they (usually) reduce the bit width of a message is not really significant at all
in fact i wouldn't say a message digest satisfying indifferentiability "reduces the bit width of a message" because that absolutely implies that bits of the message are simply compressed lossily, which IS how the COOL fucking hash functions work
a message digest like SHA-512 is initialized to a fixed or maybe random value, and then it does something much much closer to stream encryption
like it's not "cryptographic" just because it does more work. anything can be "cryptographic". it specifically produces output that does not leak the input bytes. i suppose the distinction between digests and encryption, to cryptographers, is very much just that its output can be smaller than the input
BOOOO WIKIPEDIA IS INCORRECTLY OVERSPECIFIC https://en.wikipedia.org/wiki/Hash_function
A hash function is any function that can be used to map data of arbitrary size to fixed-size values, though there are some hash functions that support variable-length output.[1]
this is definitionally a message digest. variable-length output doesn't even make sense for something like a bloom filter which often consumes the output of a message digest
wikipedia also said some oxford guy in the 70s did computational logic "more general" than turing 'because it didn't impose a specific model of computation". that's called a non-constructive proof. every wikipedia "mathematician" is british and homophobic
i checked the blake3 paper to see what they call the step that makes each fixed-length chunk into a smaller fixed length https://raw.githubusercontent.com/BLAKE3-team/BLAKE3-specs/master/blake3.pdf they call it the "compression" function. good fucking grief
The compression function applies a 7 round keyed permutation
v0 = E(m, v)to the statev0 ... v15, keyed by the messagem0 ... m15.
i would call that an iterated keyed permutation, not a "compression"
The output of the compression function is most often truncated to produce 256-bit chaining values.
[2 pages later] "the output of the compression function is truncated in order to achieve the compression which is attributed to the function" very good. more like this please
see i kept trying to start this implementation of BLAKE3 for AMD's aocl-crypto library because of intel hater reasons (and because the library seems good and i want to support cpu vendors doing this) but my eyes kept glazing over and now i see it's because they keep fucking around like this.
