Re: [gentoo-dev] Manifest2 hashes, take n+1-th

["Hanno Böck" <hanno@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

On Fri, 20 Oct 2017 11:23:06 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Fri, 20 Oct 2017, Dirkjan Ochtman wrote:  
> 
> > As Hanno was saying, we'll have decades of warning before a break
> > becomes practical, so I don't think this is a real concern.  
> 
> How can we be sure of that? I guess the same reasoning was applied
> when MD5 and SHA1 hashes were used.

MD5 warning 1996:
ftp://ftp.iks-jena.de/mitarb/lutz/crypt/hash/dobbertin.ps

MD5 broken 2005:
http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf

SHA1 warning 2005:
https://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf

SHA1 broken 2017:
https://shattered.io/


It's reasonable to assume that modern hash functions will have a far
longer warning period. For two reasons:
* their safety margin is much higher to begin with, particularly if
  you choose something like SHA512 (256 bit collission resistance). It
  was more or less always clear that MD5 (64 bit) and SHA1 (80 bit) are
  in risky terrain even without any cryptographic breakthrough.
* hash function research in 2017 is lightyears ahead of hash function
  research in the 90s and early 2000s. One major outcome of the
  research after the big hash breakdown in 2005 was that SHA-2 is much
  safer than people previously thought.


I don' have a very strong opinion on this. Having two hash functions
probably won't harm. Though I tend to prefer the simplest solutions if
it's secure. And all my cryptographic knowledge tells me that "What if
sha512 is broken?" isn't a realistic problem to be concerned about.


I do feel it's a bit ironic that we have these lengthy discussions
about hash functions while at the same time they provide little
security to begin with, because they aren't transmitted over a secure
channel and not signed...

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]