Re: [Monotone-devel] SHA- collision found

2017-02-26 Thread Hendrik Boom 
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.

https://soylentnews.org/article.pl?sid=17/02/26/1724226

How to fix?

(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?

-- hendrik

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] SHA- collision found

2017-02-24 Thread grarpamp 
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 :)

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] SHA- collision found

2017-02-24 Thread grarpamp 
On 2/24/17, Lapo Luchini  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.

___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] SHA- collision found

2017-02-24 Thread Lapo Luchini 
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.


--
Lapo Luchini - http://lapo.it/


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel