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

[Peter Gutmann]

Thor Lancelot Simon <tls at rek.tjls.com> writes:

>I think we're largely talking past one another.  As regards "new horrible
>problems" I meant simply that if there _are_ "new horrible problems_ such
>that we need to switch away from SHA1 in the TLS PRF, the design mistakes
>made in TLS 1.1 will make it much harder.

Well, let's move the TLS 1.2 aspect out of the discussion and look at the
underlying issues.  If you're looking at this purely from a theoretical point
of view then it's possible that the ability to use SHA-2 in the PRF is an
improvement (it may also be a step backwards since you're now relying on a
single hash rather than the dual hash used in the original design).  Since no-
one knows of any attacks, we don't know whether it's a step backwards, a step
forwards, or (most likely) a no-op.

However there's more to it than this.  Once you've got the crypto sorted out,
you need to implement it, and then deploy it.  So looking at the two options
you have:

Old: No known crypto weaknesses.
     Interoperable with all deployed implementations.
     Only one option, so not much to get wrong.

New: No known crypto weaknesses.
     Interoperable with no deployed implementations.
     Lots of flexibioity and options to get wrong.

Removing the common factors (the crypto portion) and the no-op terms
("interoperable with existing implementations") we're left with:

Old: -
New: Non-interoperable.
     Complex -> Likely to exhibit security flaws (from the maxim that
       complexity is the enemy of security).

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 I read Ben's comments, they were _advocating_ those kinds of design
>mistakes, advocating hard-wiring particular algorithms or their parameter
>sizes into protocols,

You keep asserting that this is a mistake, but in the absence of any
cryptographic argument in support, and with practical arguments against it, it
looks like a feature to me.

>In fact, it is radically harder to replace an entire protocol, even with a
>related one, than to drop a new algorithm into an existing, properly-designed
>protocol.

A properly-designed security protocol is one that's both cryptographically
sound and simple enough that it's hard to get wrong (or at least relatively
easy to get right, admittedly not necessarily the same thing).  Adding a pile
of complexity simply so you can make a crypto fashion statement doesn't seem
to be helping here.

>If TLS 1.{0,1} had been designed to make the hash functions pluggagle
>everywhere

... like that model of security protocol design IKEv1 was [0], then we'd have
all kinds of interop problems and quite probably security issues based on
exploitation of the unnecessary complexity of the protocol, for a net loss in
security and interoperability, and nothing gained.

Peter.

[0] Apologies to the IPsec folks on the list, just trying to illustrate the
    point.

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