101–110 of 186 posts
SHA-3 in Ruby: $ gem install sha3 $ irb > require 'sha3' > s = SHA3::Digest::SHA224.new > s.update("\x00") > s.update("\x00" * 4294967295) [ Segmentation fault... ] Tested with Ruby 3.1.2 Gem's code (including C native extension): https://github.com/johanns/sha3
Didn'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: https://www.adacore.com/press/spark-skein See also: https://www.adacore.com/papers/sparkskein
Earlier quoted context omitted.
There is a good reason to use SHA-256 and not SHA-512. Many modern CPUs, e.g. all AMD Zen, most Intel Atom, Intel Ice Lake and newer, most 64-bit ARM, have hardware implementations of SHA-256, which are much faster than software computing SHA-512. Only some more recent 64-bit ARM CPUs also have hardware for SHA-512 and SHA-3. Whenever the speed matters, SHA-256 is the best choice, unless you choose different hash alg…
Interesting, in general I've noticed SHA-256 hashing is relatively CPU intensive and slow.. is the 2024 Xeon CPU in my server too old to include the hardware implementation?
Ouch, thats not looking good for a reference implementation for a piece of software deployed on billions and billions of machines that was written by experts and reviewed (and modified) by even bigger egg heads.
Can someone ELI5 the severity of this over the whole internet? What breaks/what not
The full advisory is linked at https://github.com/XKCP/XKCP/security/advisories/GHSA-6w4m-2... . In order for an application to be vulnerable, it must: 1. Break the file into multiple chunks and pass them to SHA-3 individually. 2. Make one of those chunks larger than 4 GB in size. (This requires using 4 GB of memory.) This is kind of an unlikely thing for an application to do. If you're breaking the file into chunks,…
(mmap() can be reasonably used for streaming usecases like this provided you use madvise() hints on whether you want the data kept resident after use, probably non unix platforms have similar apis)
“I’ve also shown how a specially constructed file can result in arbitrary code execution, ” Ouch, thats not looking good for a reference implementation for a piece of software deployed on billions and billions of machines that was written by experts and reviewed (and modified) by even bigger egg heads.
It looks pretty difficult to exploit. Untrusted 4GB input with non-chunked update.
4+ GB inputs are often fed to hashing functions. Verifying the integrity of file downloads before running them for example.
Edit: Turns out there was another comment like this, and a response was that the file could be mmap'd.
Earlier quoted context omitted.
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-fa…
There is a good reason to use SHA-256 and not SHA-512. Many modern CPUs, e.g. all AMD Zen, most Intel Atom, Intel Ice Lake and newer, most 64-bit ARM, have hardware implementations of SHA-256, which are much faster than software computing SHA-512. Only some more recent 64-bit ARM CPUs also have hardware for SHA-512 and SHA-3. Whenever the speed matters, SHA-256 is the best choice, unless you choose different hash alg…
Earlier 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.
> 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. It absolutely is, and this kind of absolutism is what holds back the adoption of things like rust. In most real world software development, the target defect rate is not zero. The value proposition of something like rust for most businesses isn't that it lets yo…
Earlier quoted context omitted.
> 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. It absolutely is, and this kind of absolutism is what holds back the adoption of things like rust. In most real world software development, the target defect rate is not zero. The value proposition of something like rust for most businesses isn't that it lets yo…
So your assumption is that most to all defects are language related and not programmer error? I will bet the farm your defect rate will remain the same without any actual validation of what people write. Plenty of errors due to language quirks but lots of times I see missing statements, fixed values which should be variable, input checking failures due to unknown input, incorrect assumptions and lots of non language…