SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)

[Fuzzy Hoodie-Monster]

On Mon, Sep 7, 2009 at 6:02 AM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:

> That's a rather high cost to pay just for the ability to make a crypto fashion
> statement.  Even if the ability to negotiate hash algorithms had been built in
> from the start, this only removes the non-interoperability but doesn't remove
> the complexity issue.

As usual, I tend to agree with Peter. Consider the time scale and
severity of problems with cryptographic algorithms vs. the time scale
of protocol development vs. the time scale of bug creation
attributable to complex designs. Let's make up some fake numbers,
shall we? (After all, we're software engineers. Real numbers are for
real engineers! Bah!)

cryptographic algorithm weakness discovery rate: several per decade

cryptographic algorithm weakness severity: 5 badness points per decade
the weakness has been known; 7 badness points is considered fatal.
Let's say MD5's badness is 8 and SHA-1's is 3. AES-256's is 1, because
even after the attack it is still strong enough for most real uses.

protocol development rate: 1 per year

bug creation rate (baseline): tens per day per project

bug creation rate for bugs due to complex designs: half of baseline
(the other half is due to just regular mistakes)

Although the numbers are fake, perhaps the orders of magnitude are
close enough to make the point. Which is: your software will fail for
reasons unrelated to cryptographic algorithm problems long before
SHA-256 is broken enough to matter. Perhaps pluggability is a source
of frequent failures, designed to solve for infrequent and
low-severity algorithm failures. I would worry about an overfull \hbox
(badness 10000!) long before I worried about AES-128 in CBC mode with
a unique IV made from /dev/urandom. Between now and the time our
ciphers and hashes and signatures are broken, we'll have a decade to
design and implement the next simple system to replace our current
system. Most software developers would be overjoyed to have a full
decade. Why are we whining?

What if TLS v1.1 (2006) specified that the only ciphersuite was RSA
with >= 1024-bit keys, HMAC_SHA256, and AES-128 in CBC mode. How
likely is it that attackers will be able to reliably and economically
attack those algorithms in 2016? Meanwhile, the comically complex
X.509 is already a punching bag
(http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
and http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf,
including the remote exploit in the certificate handling code itself).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com