[HN Gopher] BLAKE2: "Harder, Better, Faster, Stronger" Than MD5 ...
___________________________________________________________________
BLAKE2: "Harder, Better, Faster, Stronger" Than MD5 (2014)
Author : 0xedb
Score : 22 points
Date : 2022-01-23 20:50 UTC (2 hours ago)
(HTM) web link (leastauthority.com)
(TXT) w3m dump (leastauthority.com)
| dcomp wrote:
| "Work it harder, make it better
|
| Do it faster, makes us stronger
|
| More than ever, hour after hour
|
| Work is never over"
| PrimeDirective wrote:
| -Wayne Gretzky
|
| -Michael Scott
| goldenkey wrote:
| - Captain Jean-Luc Picard, U.S.S. Enterprise
| londons_explore wrote:
| Can we have a hash function that is theoretically secure, rather
| than just "we shuffled a bunch of bits, and nobody yet knows how
| to unshuffle them, but in 20 years someone might discover how
| to"?
|
| For example, encrypting the data with a public key where nobody
| knows the private key ought to do the job, for example, public
| key=pi. Then use the encrypted data as the 'hash' (or some
| shortened version of it by discarding bits).
|
| Yes, I know it would be slower, but it might be better to pay the
| performance cost than to have to move everything to a new
| algorithm every 20 years.
| acchow wrote:
| > Can we have a hash function that is theoretically secure,
| rather than just [...] and nobody yet knows how
|
| > For example, encrypting the data with a public key where
| nobody knows the private key ought to do the job
|
| Errr... public key cryptography is only "theoretically secure"
| because we assume "nobody yet knows how..." to solve some hard
| problems like prime factoring, discrete log, etc.
| poizan42 wrote:
| If you can compute a hash in polynomial time then you can also
| verify a potentiel pre-image (i.e. input) in polynomial time,
| which puts the problem of finding a pre-image in NP. Hence
| proving pre-image attack resistency would imply P!=NP unless
| computing the hash itself can't be done in polynomial time.
|
| So for the time being the answer is no, we can't have a hash
| function that is theoretically secure. Your suggestion just
| moves the problem onto proving that the public key cryptography
| is secure, which suffers from the same problem.
| contravariant wrote:
| Technically the time is constant since some finite set of
| inputs is enough to generate all hashes. At the very least
| we'll need to be careful with respect to _what_ the time is
| 'polynomial'.
|
| For what it's worth I see no reason you couldn't identify
| some NP-hard problem for which the original input is the
| solution. This means that reversing the hash directly is out
| of the question, but this only works if you the way you
| generate the NP-hard problem is itself difficult (or ideally
| random) enough that it can't be reverted.
|
| Sounds like a lot of effort, but who knows, it might be worth
| the effort in some cases.
| ogogmad wrote:
| There's this (called SWIFFT): https://en.wikipedia.org/wiki/SWI
| FFT#:~:text=In%20cryptograp....
|
| There are also trivial constructions that exploit the
| difficulty of Discrete Log. But they are slow.
|
| You do have to be careful when using these hash functions,
| because they satisfy potentially undesirable properties like
| H(a + b) = H(a) + H(b), which make them unusable as _random
| oracles_.
|
| There haven't appeared any cracks in SHA2 for the nearly two
| decades in which it's existed. So unless it's possible to have
| a sudden and totally inexplicable break, we'll probably be safe
| for many decades hence.
| capableweb wrote:
| > Yes, I know it would be slower, but it might be better to pay
| the performance cost than to have to move everything to a new
| algorithm every 20 years.
|
| What if your way reveals to be insecure as well in 20 years?
| Who knows what will happen in that time-frame, it's a long time
| in our interconnected world.
|
| What if instead of trying to find something that works forever,
| you embrace change and make it easy to change the algorithm
| instead? So when you need to change in the future (not "if"),
| you can easily just switch a value to change to the new one.
| Have solid testing created already for. Don't assume invariants
| that changes between the different hash functions, like length
| or what bytes there will be in them.
| TillE wrote:
| What's different about encryption algorithms that make them not
| fundamentally "shuffling a bunch of bits"?
|
| Anyway, BLAKE is based on ChaCha.
| tptacek wrote:
| It would be slower but it would also likely be _less_ secure.
| Hashes are (roughly) based on a block cipher cryptography,
| which is arguably a more straightforward research project ---
| the rate of practical advancements on (say) finite field dlog
| cryptography is scarier than that of (say) new applications of
| differential cryptanalysis on block cipher cores.
|
| Hashes have kind of a bad rap because we happened to get a
| whole string of 1990s-vintage hash functions that survived into
| the 2010s. AES had mostly just DES-EDE to replace. You can find
| somewhere a tweet from JP Aumasson, one of the
| Blake/Blake2/Blake3 authors, suggesting that we might _never_
| break SHA-2. SHA1 had a low (again: 1990s) security margin
| (2^80 collision resistance), among other problems (notably:
| susceptibility to differential cryptanalysis).
|
| (It's also possible that I've said something dumb enough that
| one of the other Blake authors will smack me down and improve
| the thread).
|
| The reasons for looking at SHA3 and Blake2 or Blake3 don't have
| _that_ much to do with security, as much as they have to do
| with speed and flexibility.
| sshine wrote:
| In the meantime,
|
| https://github.com/BLAKE3-team/BLAKE3
| encryptluks2 wrote:
| Hoping to see a BLAKE3 implementation in whatever library is
| necessary for distros like Arch to verify package checksums
| soon.
| 2bluesc wrote:
| Wow, totally unaware of the performance speed-up 5x over sha1
| and blake2b. Even more for others!
|
| Are there cases where the benchmark doesn't hold true?
| Different architectures?
|
| I'm inclined to use this on some less security sensitive things
| I need a hash for.
| staticassertion wrote:
| There shouldn't be any meaningful reduction in security
| afaik. Most of the performance comes from reducing the number
| of rounds used because it was shown that it was unnecessary
| iirc.
| bawolff wrote:
| Well i'm sure there are usecases where it matters, in general
| sha-256 is already really fast. Why bother with something faster?
| Hanschri wrote:
| I found the footnote quite interesting:
|
| > Some software, notably git, is still using SHA-1, and relying
| on the fact that the best publicly-known method of generating
| SHA-1 collisions costs 269 computations, which is expensive. I
| think it is unwise to rely on this for two reasons. One is that
| there could be more efficient techniques to compute SHA-1
| collisions that we don't know about. Another is that the cost of
| doing 269 computations is falling rapidly--at the time of this
| writing (March 22, 2014), the Bitcoin network is performing
| enough computation to generate SHA-1 collisions every 131
| minutes!
|
| By guesstimating from just looking at the graph to the linked
| site, it seems the Bitcoin network was at about 100 PH/s, with
| the network at 185 EH/s, which is close to a 2000x in hashrate
| since this blogpost went live.
| staticassertion wrote:
| And Linus was told of this and, in typical Linus fashion, he
| dismissed it.
___________________________________________________________________
(page generated 2022-01-23 23:00 UTC)