After modified version have been broken in the past, this time around
it's The Real Thing: https://shattered.it/
What's nice is that the attack vectors can be detected and a "hardened"
version of SHA-1 that returns the same value in "normal" cases and
different-but-secure values on attack vectors can be substituted.
On 2/24/17, Lapo Luchini <[hidden email]> wrote:
> What's nice is that the attack vectors can be detected and a "hardened"
> version of SHA-1 that returns the same value in "normal" cases and
> different-but-secure values on attack vectors can be substituted.
Repos should address keeping / 'fixing' broken sha-1 as needed.
They also really need to create new native modes so users can
initialize and use repos with (sha-3 / sha-256 / whatever) going forward.
Backward compatibility with sha-1 or 'fixed sha-1' will be good. Clients
can taste repos for which hash mode to use, or add it to their configs.
Make things flexible, modular, configurable, updateable.
I don't see much point in 'fixing / caveating' their use of broken sha-1,
without also doing (sha-3 / optionals) in the first place, defaulting
new init's to whichever strong hash looks good, and letting natural
migration to that happen on its own through the default process.
To be in some relative perspective, there are probably lot
more fixes, updates, and developments to do for monotone
more important than immediate practicality of sha1 attack
this very moment. So all those can come as can be made :)
On Sat, Feb 25, 2017 at 12:52:14AM -0500, grarpamp wrote:
> To be in some relative perspective, there are probably lot
> more fixes, updates, and developments to do for monotone
> more important than immediate practicality of sha1 attack
> this very moment. So all those can come as can be made :)
At least one source repository has been completely corrupted by adding
two pdf's with the same SHA1 hashes. Granted, it was a Subversion
repository (for Webkit) and not monotone, but the problem may be
urgent and important.
(1) start using a better hash code for all new files we commit, so
that no *new* files will cause a conflict if there isn't already on
ein the data base.
(2) provide a mechanism for recertifying all the old changes. Perhaps
a second-order certificate that certifies all the old certificates s
being valid. This would at least be a bit of a mess, because old
repositories will have both hashes -- old hashes for old changes and
new ones for new files.
Or is there a valid way of rehashing and recertifying everything and
starting afresh with a completely new database?