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

171–180 of 186 posts

Re: SHA-3 Buffer Overflow

#171

Post by pjmlp »

tialaramex wrote: post #168
pjmlp wrote: post #145

Earlier quoted context omitted.

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 in Rust is not that the index operations are bounds checked, that's easy, as you observed plenty of C++ toolchains can do that. 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…

Given that on some domains, there is no way around C or C++, unless one wants to be part of building the ecosystem, I was having big hopes on the clang and VC++ static analysis work for those kind of scenarios.

I can't speak for clang, but in what concerns VC++ is mostly useless still, unless one wants to annotate everything with those kind of annotations + SAL, and even then it is only half way there.

Which is not really inspiring.

Re: SHA-3 Buffer Overflow

#172

Post by aliqot »

baby wrote: post #73
aliqot wrote: post #6

Interesting 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…

I'm not sure what's your point, the XKCP is the official SHA-3 implementation.

> I'm not sure what's your point

You're just a baby. There's time.

Re: SHA-3 Buffer Overflow

#173

Post by lmm »

galangalalgol wrote: post #170
lmm wrote: post #92

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…

I'll give you the static analyzer is much less important with rist, but that is the easy part anyway. I stand firm that tests are always important, and you don't know how well you tested without coverage. I'm not even sure I'd say you need less coverage with rust, not all errors are resource safety related.

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 no real business logic anyway); I like to follow something like https://spin.atomicobject.com/2014/12/09/typed-language-tdd-... .

Re: SHA-3 Buffer Overflow

#174

Post by tinglymintyfrsh »

saagarjha wrote: post #123
galangalalgol wrote: post #67

Earlier quoted context omitted.

Does valgrind add anything to asan given the same unit tests? I haven't used in years because it is so slow.

Address sanitizer is not precise and can miss certain classes of bugs that Valgrind would catch.

Yeap. Although Google killed off afl, exercise code with fuzzing too that unit and integration tests didn't catch.

Re: SHA-3 Buffer Overflow

#175

Post by tinglymintyfrsh »

tptacek wrote: post #64
tinglymintyfrsh wrote: post #51

Earlier quoted context omitted.

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 Tw…

SMH. You're conflating "broken" by mathematical attack and having enough computing power to brute it (GPUs or quantum). Rise in computing power always jeopardizes the baseline brute cost of every algorithm, which is why standards shift over time, otherwise 3DES would still be recommended for new applications instead of AES.

Re: SHA-3 Buffer Overflow

#176

Post by tinglymintyfrsh »

dcow wrote: post #116
baby wrote: post #75

Earlier quoted context omitted.

Blake2/3 also doesn't suffer from length extension attacks, but SHA-256 is what everyone uses unfortunately.

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.

Re: SHA-3 Buffer Overflow

#177

Post by duskwuff »

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.

Outside of password hashing applications, which message digests like the SHA and Blake families aren't ideal for anyway, hash functions don't really derive their strength from being slow. If a hash is seriously broken -- in the kind of way that MD4 is, for example -- attacks against it may require so few operations that the speed of the hash doesn't matter at all. But, so long as the hash function remains unbroken, any attack against it requires so many operations as to make it completely infeasible, regardless of how fast it is.

Re: SHA-3 Buffer Overflow

#178

Post by Too »

kevincox wrote: post #156
thayne wrote: post #94

Earlier quoted context omitted.

And even if they are, you probably aren't going to do a digest on the whole thing all at once.

IDK, I see a lot of "non-production" code that likes to read whole files into a in-memory buffer rather than bothering with streaming. With modern memory sizes it is completely possible that you could read a 4GiB file into memory without having issues.

Thinking about it, it's strange that hashlib doesn't have a function that accepts a file-object as input, to make the efficient method default pit of success. Naive implementations like hash(f.read()) are all too common to see. Such an api would also allow the entirety of the tight loop to be done outside of slow interpreted code.

Guessing the rationale is that if you read a file, you also want to use the content for something else, not only compute its hash.

Re: SHA-3 Buffer Overflow

#179

Post by GTP »

remram wrote: post #166
GTP wrote: post #162

Earlier quoted context omitted.

>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.

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 easily mess in the connection setup phase in a way that protocol version X looks like protocol version Y.

Re: SHA-3 Buffer Overflow

#180

Post by galangalalgol »

lmm wrote: post #173
galangalalgol wrote: post #170

Earlier quoted context omitted.

I'll give you the static analyzer is much less important with rist, but that is the easy part anyway. I stand firm that tests are always important, and you don't know how well you tested without coverage. I'm not even sure I'd say you need less coverage with rust, not all errors are resource safety related.

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.
Post reply on HN