SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)
Thor Lancelot Simon
tls at rek.tjls.com
Thu Aug 27 11:23:41 EDT 2009
On Thu, Aug 27, 2009 at 11:30:08AM +1200, Peter Gutmann wrote:
>
> Thor Lancelot Simon <tls at rek.tjls.com> writes:
>
> >the exercise of recovering from new horrible problems with SHA1 would be
> >vastly simpler, easier, and far quicker
>
> What new horrible problems in SHA1 (as it's used in SSL/TLS)? What old
> horrible problems, for that matter? The only place I can think of offhand
> where it's used in a manner where it might be vulnerable is for DSA sigs, and
> how many of those have you seen in the wild?
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.
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, because -- as I understood him -- both replacing
and algorithm and replacing a whole protocol are just "software upgrades"
and all software upgrades are alike.
Well, I don't think it's true that all software upgrades are alike in the
relevant way. 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. It may be no different for _users_,
but the difference for _implementers_ is vast, and that greatly delays the
availability of the relevant software upgrade to users, which is not a
good thing.
I think the current TLS 1.2 debacle is about the best evidence of this one
could ask for. If TLS 1.{0,1} had been designed to make the hash functions
pluggagle everywhere they're used, then users would have new software which
didn't rely on SHA1 (even in a way we currently think is still safe)
available now, rather than having to wait quite a bit longer before the
possibility of upgrading even arose.
Thor
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list