So if we ported this library to rust sha3 seems peachy? No doubt an interesting port but it now seems inevitable.
SHA-3 Buffer Overflow
11–20 of 186 posts
Re: SHA-3 Buffer Overflow
#12> The vulnerable code was released in January 2011, so it took well over a decade for this vulnerability to be found
Ouch
Re: SHA-3 Buffer Overflow
#13If 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…
My understanding was that sha-3 should be faster than sha-2, in a general sense, but sha-2 has hardware acceleration. Is that incorrect?
I think SHA-3 is almost always slower in software, in theory SHA-3 could be hardware accelerated of course, but on both current AMD and Intel systems it's not, where SHA-2-256 is.
Re: SHA-3 Buffer Overflow
#14Re: SHA-3 Buffer Overflow
#15> The vulnerable code was released in January 2011, so it took well over a decade for this vulnerability to be found Ouch
Between this and "beacown" I came to a realization. I work on codebases worth way less than these amd we do lots of different static analyzers two compilers, lots of unit tests with coverage checks and asan/ubsan. The linux kernel and sha are worth tons of money. Thus, someone wrote all the pipelines and unit tests for that software too. The problem is, the people who paid for all that work aren't the people that rely on thos software's security. It's paid for by people that rely on it's insecurity. So we don't know about this stuff until they or the people they sold it too use these exploits.
Edit: in case the solution I propose isn't obvious, organizations like red hatand google need to pay for these pipelines and unit tests. Getting good unit test coverage is expensive and ubsan and asan don't work without that coverage. So since no one has mentioned it yet, you could rewrite this stuff in rust as a poor man's substitute. It will catch some of the aame things, but ultimately there is no substitute for test coverage with sanitizers. Well, maybe formal analysis?
Re: SHA-3 Buffer Overflow
#16Interesting they both say "Official Sha3" and "by its designers", which as I remember it isn't that accurate. Keccak was chosen and then NIST added what is affectionately known as the 'mystery padding' before certification. What we know as official is not the way the designers submitted the proposal. This isn't an attempt at a scary accusation, but as a pedant, this got me. For those wondering, here is an explanation…
No post body was provided.
Re: SHA-3 Buffer Overflow
#17The vulnerability impacts 'the "official" SHA-3 implementation'. How widely used is it for SHA-3 hashing compared to something like OpenSSL?
The version in the Golang stdlib defaults to a pure-go implementation... unless you're compiling for amd64, in which case you get an assembler variant apparently directly derived from the XKCP package (https://github.com/golang/crypto/blob/master/sha3/keccakf_am...).
Slightly concerning news for the (mostly-Golang-based) Ethereum ecosystem, which relies on SHA3-256 for pretty much everything...
Re: SHA-3 Buffer Overflow
#18If 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…
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.
Re: SHA-3 Buffer Overflow
#19Can someone ELI5 the severity of this over the whole internet? What breaks/what not
SHA3 is relatively infrequent compared to sha1/2 and md5. SHA3 also has a few variants, and I don't know for sure if this vulnerability is present in all variants.
The vulnerability is only present in the reference implementation. So it's unlikely that other implementations (rush as Rust or Go) are vulnerable.
I tested with the latest released and master branches of PHP, both of which segfaulted for the code samples mentioned in the article. The article says Python is also vulnerable.this is because both of the languages apparently use the reference implementation.
Ethereum uses SHA3 quite extensively, but I doubt it's vulnerable post migration from PoW, let alone it's unlikely that they use the vulnerable implementation/variant.
Re: SHA-3 Buffer Overflow
#20Interesting they both say "Official Sha3" and "by its designers", which as I remember it isn't that accurate. Keccak was chosen and then NIST added what is affectionately known as the 'mystery padding' before certification. What we know as official is not the way the designers submitted the proposal. This isn't an attempt at a scary accusation, but as a pedant, this got me. For those wondering, here is an explanation…
Quoted post unavailable.
You're responding to a post that links to the Keccak designers saying that the padding change isn't nefarious. You have to be able to do better than "NIST bad" in comments on threads like these.