no bounty and still politely reports it. Good guys need more praise.
SHA-3 Buffer Overflow
61–70 of 186 posts
Re: SHA-3 Buffer Overflow
#62If you're familiar with SHA-256 and this is your first encounter with SHA-3: The main differences between the older SHA-256 of the SHA-2 family of FIPS 180, and the newer SHA3-256 of the SHA-3 family of FIPS 202, are: * Resistance to length extension attacks. * Performance. The SHA-2 functions—particularly SHA-512, SHA-512/224, and SHA-512/256—generally have higher performance than the SHA-3 functions. Partly this wa…
Note that truncated SHA-2 (SHA-224, SHA-384, SHA-512/224, SHA-512/256) are not susceptible to length-extensions attacks [1].
With the added benefit of better performance of SHA-512 (on 64 bit systems) [2], there's no good reason to use SHA-256 rather than SHA-512/256 for new cryptographic designs.
[1] https://en.wikipedia.org/wiki/Length_extension_attack
[2] https://crypto.stackexchange.com/questions/26336/sha-512-fas...
Re: SHA-3 Buffer Overflow
#63What dows generating preimages mean here? The preimage is the set of all messages that hash to some set of hashes. Is the author saying the the hash function is reversible in reasonable time?
It's a buffer overflow. They can get a vulnerable implementation to execute arbitrary code, so they can get it to return any value they want. The actual SHA-3 algorithm wouldn't return the same value as the vulnerable implementation, of course.
Re: SHA-3 Buffer Overflow
#64Earlier quoted context omitted.
SHA-3 is rarely used in general. Most applications still use SHA-2 hashes (such as SHA256).
Rare != bad && rare != unimportant. The point of NIST standardizing on SHA-3 is to gradually replace SHA-2 due to the rise of computing power and the likelihood it will become as weak as SHA-1 is now in the near future. Unfortunately, like American credit cards vs. European chip & pin, it's going to take forever to adopt.
No. The "rise in computing power" doesn't jeopardize SHA2. There are important design differences between SHA1 and SHA2 (here's where in my younger days I'd pretend that I could rattle off the implications of nonlinear message expansion off the top of my head). SHA2 is secure; don't take my word for it through, you can find one of the Blake2 designers saying SHA2 is unlikely ever to be broken, or Marc Stevens on a Twitter thread talking briefly about why his attacks on SHA1 don't apply at all to SHA2.
Re: SHA-3 Buffer Overflow
#65Didn't they find a vulnerability like this in the official MD5 implementation when they tried to port it to SPARK/Ada and the proofs didn't work? I wasn't able to just find it with web search, but here's a release about something similar happening with another one of the SHA3 candidates (Skein), before Keccak was chosen:
Re: SHA-3 Buffer Overflow
#66> The vulnerable code was released in January 2011, so it took well over a decade for this vulnerability to be found Ouch
Took well over a decade for this vulnerability to be disclosed.
Re: SHA-3 Buffer Overflow
#67Earlier quoted context omitted.
Rust isn't perfect. UB is a bug in rust, but it occasionally has bugs. Ideally you'd do rust and asan with good unit tests. And yes, if you only picked one, it should be rust, but don't just pick one. And just because you are using rust is no excuse to skip static analysis like prusti, coverage with gcov, llvm, or tarpaulin, and certainly not unit tests.
There is unlikely ever to be a perfect, but a getting better by constraining behavior that breaks things. Throw all of the compile-time, profiling, checked builds, and binary-level tools at projects for defense-in-depth and checklists, no matter the platform or the application. Fuzzing, valgrind, gperftools, dtrace, {[amt],ub}san, etc. and formal methods like seL4 if you can afford the investment. :>
Does valgrind add anything to asan given the same unit tests? I haven't used in years because it is so slow.
Re: SHA-3 Buffer Overflow
#68Earlier quoted context omitted.
i thought sha-2 included the message length in the head padding to prevent length extension attacks? just read the link you provided: it's sha-224 and above. i wonder if a similar issue exists in the sha-224+ padding code.
I think you've badly misunderstood what's going on here. SHA-2 includes SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256. Six functions. Of these SHA-256 and SHA-512 are subject to the length extension attack (and SHA-224 only has 32-bit worth of safety which is clearly inadequate). Since you probably only needed a 256-bit hash, SHA-512/256 is a choice available today which produces a 256-bit hash without…
> I think you've badly misunderstood what's going on here.
that sounds right. been almost a decade since i've dug into sha-2.
i do remember the lengths in sha-256 and sha-512 though and i remember not being a huge fan of the chunking/padding code.
come to think of it, there's another reason for the message length in the padding. i forget what it is now.
Re: SHA-3 Buffer Overflow
#69The vulnerability impacts 'the "official" SHA-3 implementation'. How widely used is it for SHA-3 hashing compared to something like OpenSSL?
SHA-3 is rarely used in general. Most applications still use SHA-2 hashes (such as SHA256).
An obvious issue is that many protocols do two-sided negotiations of crypto algorithms during a handshake - so one of "most applications" which uses SHA-2 hashes by default could be vulnerable to a network connection saying "I don't support SHA-2, let's use SHA-3 pls?" and then exploiting the buffer overflow.
In a similar manner, apps that verify signatures/certificates often let the certificate specify which algorithm is used, so again effectively an attacker may be able to force the app to use SHA3 as long as it uses a library that has some support for it.