161–170 of 186 posts
Earlier quoted context omitted.
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...
All the Go code is safe. No bugs.
Earlier quoted context omitted.
As you say, it could be that an algorithm gets broken before its "expiry date" or remains secure well past that (look e.g. at AES). There is a similar but better alternative, usually called "opnionated cryptography". A protocol specifies a single cryptographic primitive for each type needed (hash function, block cipher etc) so no negotiation is needed. If one of the primitives gets broken, a new version of the protoc…
And then you still have a roll-out period during which those two protocols are available, so the two parties still need to negotiate which version they want. It's not clear to me what the advantage over the current situation is?
Not necessarily. If the client contacts the server using version X, the server will reply with version X.
Earlier quoted context omitted.
And then you still have a roll-out period during which those two protocols are available, so the two parties still need to negotiate which version they want. It's not clear to me what the advantage over the current situation is?
>the two parties still need to negotiate which version they want Not necessarily. If the client contacts the server using version X, the server will reply with version X.
Earlier quoted context omitted.
Last time when I have checked what sha256sum (from coreutils) does was one year ago. At that time, on x86 CPUs (I have not tested on ARM) neither sha256sum nor sha224sum nor sha1sum used the hardware instructions (and I have compiled them from sources, with the appropriate flags). Because I have a Zen CPU (but that would also be true on Atom CPUs or Core CPUs since Ice Lake), I have to use "openssl dgst -r -sha256" i…
I also see similarly slow performance when using the Go built-in Sha256 hashing library. Thanks for the info! Fortunately for my purposes of integrity checking, slow is okay.
On the other hand, on older Skylake/Kaby Lake/Coffee Lake etc. CPUs, both programs have the same speed.
The 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...
Read it yourself here:
https://cs.opensource.google/go/x/crypto/+/refs/tags/v0.1.0:...
There's obviously no problem.
Earlier quoted context omitted.
And then you still have a roll-out period during which those two protocols are available, so the two parties still need to negotiate which version they want. It's not clear to me what the advantage over the current situation is?
>the two parties still need to negotiate which version they want Not necessarily. If the client contacts the server using version X, the server will reply with version X.
FYI in the healthcare space to meet ONC Cures Update regulations for bulk patient export, its a requirement to use SHA384 (RS384 or ES384). I would think most implementations will be safe due to the 4GB payload criteria, but if anyone is doing anything funky they'll need to look at this closely.
Earlier quoted context omitted.
WG21 (the C++ Standards Committee) feels that since idiomatic C++ was unsafe (e.g. array operations don't have bounds checks) it is consistent for new C++ features to also be unsafe by default, even if the whole point of those features in other languages is to provide an idiomatic safe way to do things. So for example in Rust you have a native slice type reflecting a dynamically sized view into a contiguous sequence,…
Tragically, what I would call idiomatic C++ with compiler provided frameworks pre-ISO C++98, made use of bounds checking in their collection classes, and then the C++ Committee went completly to the other way. Naturally we have now ways to enable them on all major compilers, but many still don't. This is one point I kind of agree with you.
The crucial trick is providing the unchecked operations (with improved performance) as unergonomic alternatives. *(five.get_unchecked_mut(20)) = k; // looks horrible. Nobody wants to write that, so when they don't need it they won't write it. The fact calling get_unchecked_mut requires unsafe is part of how Rust could achieve its goals, but the choice to not make this ergonomic is why it actually delivers in practice.
What CppFront wants here, and P2687 proposes, and lots of other C++ work has suggested, is roughly:
[[suppress(bounds_check)]] { five[20] = k; }
Earlier quoted context omitted.
it's a public standard, who would pay such a bounty?
I'm sorry, we lost millions of dollars due to an exploit. Don't you have bug bounties to find and fix these things? But this was in a public standard that we were using, we don't cover those. Do I look like I care?
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…