@eyedeekay
+R4SAS
+RN
+RN_
+StormyCloud
+T3s|4
+Xeha
+acetone
+dr|z3d
+hk
+orignal
+weko
FreeB
Irc2PGuest40608
Irc2PGuest41133
Irc2PGuest59134
Onn4l7h
aeiou
ardu
eyedeekay_bnc
not_bob_afk
profetikla
qend-irc2p
shiver_
u5657
x74a6h
eyedeekay
Terms of getting smarter about hashes, I can't seem to find anyone anywhere that thinks there's going to be a practical way to produce a hash collision with SHA2.
eyedeekay
I did learn about Grover's alorithm, but in at least one important thing about it is that it doesn't work faster than other(classical) algorithms that fail to break SHA2.
eyedeekay
I could actually find no known attacks that apply to how we use SHA2, but I did not evaluate whether or not our SHA2 usage is constant-time or not.
eyedeekay
Everything I could find that actually manages to attack SHA2 depends on an implementation issue with an exploitable surface.
eyedeekay
The most straightforward are length-extension attacks. We use HMAC effectively to prevent these.
eyedeekay
The thrust of the most reasonable argument I could make for something like Blake2B instead is that it's arguably easier to use well, I think.
eyedeekay
Blake2B, for reasons I don't fully understand yet, is supposed to be resistant to side-channel attacks.
eyedeekay
What I don't know for sure is whether it's because it is constant time by definition, or because it does not matter if it's constant time.
eyedeekay
It is also resistant to length-extension attacks regardless of HMAC.
eyedeekay
Does this matter much with our current use of SHA2? I also don't know this for sure yet, but it's looking a little like no, so far.
eyedeekay
I also don't know how much "agility" we have with hash implementations, if we could just switch on a dime or use multiple hash types that might affect the evaluation.