Wonder if they'll ever get this added to Alpine/Busybox as a default package? Even b2sum is missing.
BLAKE3 1.0
101–110 of 126 posts
Re: BLAKE3 1.0
#102Earlier quoted context omitted.
And if you're designing hardware (or on an FPGA) ChaCha (and BLAKE2/3) are actually really freakin' fast for the die area they take. IIRC ChaCha20 beats AES in hardware. It's just extremely rare (FPGA only) to find it in hardware, since there's not enough demand. I expect that to eventually change.
Given that all these are ARX cores, I wonder if a fused ARX instruction could cover a wide range of them?
ARMv8.2 has rotate-and-xor and xor-and-rotate so that the (extremely cheap) xor can be saved.
Re: BLAKE3 1.0
#103Is this 1.0 ready indeed? a comment in blake3_neon.c: // TODO: This is probably incorrect for big-endian ARM. How should that work?
I know ARM in principal supports BE, but never heard real BE ARM products yet. Is there one? I am just curious.
TMS570 dual-lockstep automotive safety controllers are hardwired to be big-endian.
Their close cousins the RM57 line look like nearly identical parts that are little-endian. I believe, but cannot prove, that the only difference in silicon is a factory one-time-programmable setting (fuse).
"Why would anyone want to build a BE machine?" In this case, they are trying to gain market-share from big-endian POWER microcontrollers.
Re: BLAKE3 1.0
#104Is this 1.0 ready indeed? a comment in blake3_neon.c: // TODO: This is probably incorrect for big-endian ARM. How should that work?
IMO, this shouldn't be a TODO. This should be an #error based on the standard C macros for detecting endianness at compile-time.
Re: BLAKE3 1.0
#105This is awesome. We have been using BLAKE3 in Wasmer for more than a year [1] and has been working great for us. We were trying to find a hash function for WebAssembly files that is crypto-safe. The only alternatives that were fast enough (>1Gbps) were not crypto-safe (ahash, murmur, crc32), so BLAKE3 was the obvious choice to not sacrifice on speed while getting a cryptographic hash function. [1] https://github.com/…
Yeah it's a bummer that a highwayhash is only cryptographically strong (but not cryptographically secure) as it can be significantly faster (3x). But BLAKE3 does seem to offer the best compromise when a cryptographically secure hash is required.
> a highwayhash is only cryptographically strong (but not cryptographically secure)
Can you let me know what you mean by strong vs. secure? When would you use one vs. the other? I've heard both of these terms used but they seem almost interchangeable[1].
I've also heard things like "this would be suitable for encrypting a password which is stored at rest" vs. "this could be suitable for a short lived one-time key", but I don't know what the correct terminology is there.
Re: BLAKE3 1.0
#106If I had a BLAKE3 implementation available in the programming language of choice, is there any reason to still prefer the SHA family over it (for integrity checks, not for password hashing, as mentioned in the readme)?
BLAKE3 has a large state, it's a tree hash, so you need to keep the tree of hashes, which is proportional to logarithm of the message size. SHA has fixed state for any message.
Huh, I didn't know that.
https://github.com/BLAKE3-team/BLAKE3/blob/b404c851c284ed01f...
I peeked at the reference impl (380 lines of safe Rust) and found this. It has a 1,728-byte array for tree state, which is enough for 2 ^ 64 bytes.
So in practice it's also fixed.
Re: BLAKE3 1.0
#107Earlier quoted context omitted.
Yeah it's a bummer that a highwayhash is only cryptographically strong (but not cryptographically secure) as it can be significantly faster (3x). But BLAKE3 does seem to offer the best compromise when a cryptographically secure hash is required.
> a highwayhash is only cryptographically strong (but not cryptographically secure) Can you let me know what you mean by strong vs. secure? When would you use one vs. the other? I've heard both of these terms used but they seem almost interchangeable[1]. I've also heard things like "this would be suitable for encrypting a password which is stored at rest" vs. "this could be suitable for a short lived one-time key", b…
It's weird terminology. highwayhash aims to be cryptographically secure for its problem domain. But it's designed by (afaik) non-cryptographers, has weird security claims (they gauge security from statistical tests) and hasn't (afaik) received any formal peer review; it can also be instantiated in sub-secure hash sizes. You shouldn't use it to protect secrets, beyond the kind of incident secrecy you'd ask from something like SipHash.
It would be better if people would be clear about this stuff; you see the same thing from the PCG RNG people, who say that their generator isn't a CSPRNG, but is somehow more secure than other non-CSPRNGs.
Re: BLAKE3 1.0
#108Earlier quoted context omitted.
Security-wise they are roughly equivalent. While SHA has had more eyes on it I doubt either construction will ever be practically broken at hash sizes like 384 or 512 bits. Someone may find an "academic break" at some point. BLAKE3 is faster, sometimes a lot faster, on hardware without SHA instructions. On hardware with SHA instructions SHA may be faster. Same as the AES story where AES is faster than ChaCha on CPUs…
One aspect of security is also the misuse resistance. You can of course create a secure MAC with SHA256 in the HMAC configuration, but it usually takes a masters level course on cryptography to know what is Merkle-Damgård construction, and why it's design is imperfect: You can't just do SHA256(key + message) to generate a safe MAC. With BLAKE (and all SHA3 finalists) you can do that safely. It's true every time you m…
You can with the truncated versions, though.
Re: BLAKE3 1.0
#109Earlier quoted context omitted.
> a highwayhash is only cryptographically strong (but not cryptographically secure) Can you let me know what you mean by strong vs. secure? When would you use one vs. the other? I've heard both of these terms used but they seem almost interchangeable[1]. I've also heard things like "this would be suitable for encrypting a password which is stored at rest" vs. "this could be suitable for a short lived one-time key", b…
It's weird terminology. highwayhash aims to be cryptographically secure for its problem domain. But it's designed by (afaik) non-cryptographers, has weird security claims (they gauge security from statistical tests) and hasn't (afaik) received any formal peer review; it can also be instantiated in sub-secure hash sizes. You shouldn't use it to protect secrets, beyond the kind of incident secrecy you'd ask from someth…
Without intending to endorse the wording, I suspect what's being communicated might be something related to the difficulty for an attacker to derail your system by cheaply predicting hashes. IIRC, the standard Java runtime HashMap implementation was susceptible to this at one point - an attacker could easily and cheaply force all values into only a few buckets.
The idea being, you might not care about actual cryptographic security but instead only the feasibility of some sort of cheap online collision attack.
Re: BLAKE3 1.0
#110Earlier quoted context omitted.
It's weird terminology. highwayhash aims to be cryptographically secure for its problem domain. But it's designed by (afaik) non-cryptographers, has weird security claims (they gauge security from statistical tests) and hasn't (afaik) received any formal peer review; it can also be instantiated in sub-secure hash sizes. You shouldn't use it to protect secrets, beyond the kind of incident secrecy you'd ask from someth…
Without intending to endorse the wording, I suspect what's being communicated might be something related to the difficulty for an attacker to derail your system by cheaply predicting hashes. IIRC, the standard Java runtime HashMap implementation was susceptible to this at one point - an attacker could easily and cheaply force all values into only a few buckets. The idea being, you might not care about actual cryptogr…
Right, that's what SipHash tries to do too (SipHash was designed by two very reputable cryptographers).