Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SHA-3 Buffer Overflow

mouha.be

Post reply on HN
Print view View original

181–186 of 186 posts

Re: SHA-3 Buffer Overflow

#181

Post by UncleMeat »

raydiatian wrote: post #119
yieldcrv wrote: post #115

Bro what? This is a big deal right? Like NSO Group hacking everyone for the next 5 years deal?

> The vulnerable code was released in January 2011, so it took well over a decade for this vulnerability to be found. It would have already been a big deal for the past five years, if anything. Furthermore you have to induce a bufferoverflow first. I’m no security researcher, but to my mind that means you’re either (a) trusting idiots to write sensitive code without a IT Sec team reviewing it, or (b) you’ve got a mal…

Absolutely not. Buffer overruns aren’t something that only idiots introduce.

Re: SHA-3 Buffer Overflow

#182

Post by remram »

GTP wrote: post #179
remram wrote: post #166

Earlier quoted context omitted.

What if the server doesn't support version X? Then the client will try again with version X-1. This is a negotiation, it is just an inefficient one (client might have to try X-1, X-2, X-3 in turn if more versions are still co-existing; and contrarily, if client doesn't support any version the server does, you will not get a detailed error about the version mismatch, because they are entirely different protocols).

>Then the client will try again with version X-1 Who says that? Either it is specified in the protocol, and then you're right that this is still a negotiation, or it is not specified in the protocol, so if the client does that is implementing some out of spec behavior. Which is true that already happened on the Internet for compatibility's sake, but keep in mind that there is still an advantage, as an adversary can't…

If you don't have this downgrade, then clients can't talk with servers that haven't been upgraded yet! This means either that:

* you expect all servers to upgrade immediately, or at least faster than clients, or

* you delay upgrading clients you know to be insecure until servers had time to upgrade, or

* you are ok with breaking a significant portion of the network for every protocol update.

Either way, your proposal makes no sense for the internet.

Additionally, this is already possible with the current negotiation scheme. You can have clients refuse old algorithms (and they do). Your proposal doesn't improve anything there or anywhere else.

Re: SHA-3 Buffer Overflow

#183

Post by lmm »

galangalalgol wrote: post #180
lmm wrote: post #173

Earlier quoted context omitted.

Coverage numbers are misleading (to the point that I find they did more harm than good). There are definitely cases where you can't (or aren't clever enough to) express what makes your business logic valid in the type system and need to write a test, but IME they're the exception rather than the rule (both because you generally can encode things in types, and because the majority of code ends up being "plumbing" with…

I like that article! It doesn't say to do away with coverage though, it simply talks about using good typing to make coverage easier to get with fewer tests. Like you said, sometimes you can't get the type system to enforce correctness, and sometimes you may think you have done so when you haven't, you always need tests to see.

I'm not sure what you mean by "coverage" - the article is advocating deleting (or not writing) tests if you can move the corresponding check into the type system, and the end result is that you will naturally end up with codepaths that aren't covered by tests (because those codepaths essentially "can't go wrong"). That makes the things that I've normally heard called "coverage" pretty useless.

Re: SHA-3 Buffer Overflow

#184

Post by dcow »

tinglymintyfrsh wrote: post #176
dcow wrote: post #116

Earlier quoted context omitted.

We use Blake 3. So far so good…

I'm always leery when primitives mention their speed as a selling point because I'm thinking about the memory and CPU/GPU/ASIC costs required for adversary X years from now. Sure, one can hash or encrypt using N repeated rounds to up the cost but still: speed isn't everything.

Like the sibling says, speed is not really related to hash security. Either the hash is good at any speed or it’s broken. Speed is important if you’re hashing often. Systems that hash often, in my experience, tend to have a stronger security posture than systems that use bearer tokens. So… fast strong hashing is good for applications because it enables good crypto to be applied more thoroughly. And that’s why we use Blake3, fast strong hash/kdf/xof that we can use anywhere (from powerful servers to wasm) without much of a second thought.

Re: SHA-3 Buffer Overflow

#185

Post by johannsg »

all_these_years wrote: post #78

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

Released a fix earlier today (Oct 23rd) (v1.0.5)

Re: SHA-3 Buffer Overflow

#186

Post by GTP »

remram wrote: post #182
GTP wrote: post #179

Earlier quoted context omitted.

>Then the client will try again with version X-1 Who says that? Either it is specified in the protocol, and then you're right that this is still a negotiation, or it is not specified in the protocol, so if the client does that is implementing some out of spec behavior. Which is true that already happened on the Internet for compatibility's sake, but keep in mind that there is still an advantage, as an adversary can't…

If you don't have this downgrade, then clients can't talk with servers that haven't been upgraded yet! This means either that: * you expect all servers to upgrade immediately, or at least faster than clients, or * you delay upgrading clients you know to be insecure until servers had time to upgrade, or * you are ok with breaking a significant portion of the network for every protocol update. Either way, your proposal…

Negotiation makes the protocol more complicated, so more room for bugs. Additionally, sometimes (or maybe all times?) you need to explicitly configure a client or server to not accept broken algorithms during the negotiation, so you would need to keep track for yourself for which algorithms are safe to use and which are not. Anyway it would be interesting to look at how the Wireguard folks would handle this, as Wireguard is a protocol with opinionated crypto.
Post reply on HN