Re: [Crypto-practicum] Monotone's usage of SHA1

On Tue, Feb 16, 2016 at 8:19 AM, Markus Wanner <[email protected]> wrote:

> Hi,
>
> On 02/09/2016 09:45 PM, grarpamp wrote:
> > Subscription to the archives is required as said, and is also
> > documented on the list page. It's free, no human is involved.
> > Bug them on policy, not me. The context for this thread begins
> > there and would be of interest to those with interest.
> >
> > https://lists.sonic.net/mailman/listinfo/crypto-practicum
>
> Okay, thanks, I've read through the archives, now.
>
> One thing I'm curious about is the proposal to use Argon2 (a password
> hash) over SHA3 or Blake2b for user facing hashes (or portions thereof).
> Do I understand correctly that this "only" makes it (proportionally)
> harder for Mallory to come up with a collision on the first few bytes of
> the resulting hash? Or put another way: Is there any point in using
> Argon2 (compared to Keccak or Blake2), if the full hash is used?
>
>
SHA3 is slower than SHA1, and would slow down Monotone somewhat.  BLAKE2b
is faster than MD5, and would speed up Monotone, but it has a bit less
formal analysis at this point than SHA3.

Showing Argon2 derived hashes to users is an interesting concept.  One
problem: do we need to ever verify these hashes, or do can we generate them
once during a commit (when an extra 100ms or so wont hurt much) and keep
them around.  Verification of Argon2 hashes is very expensive.  I would not
want to download 1 million commits and have to verify 1 million Argon2
hashes.  There are some algorithms with "short-cuts" where verification is
faster than hashing.  One of those might be better.  The best ones are only
"bandwidth hard" rather than memory hard, so their security is a bit lower.


> Monotone is pretty rigorous in checking its data's hashes. For example,
> it checks not just after receiving from another node, but even after
> loading a revision from disk. Therefore, I'd be pretty hesitant to
> impose that additional computational cost for the normal user.
>

An Argon2 hash here would be a real problem if it had to be verified every
time.  Maybe the resulting hash could be signed by the committer so you
only have to verify a signature?


> I rather thought about using a more compact encoding, like base58 as
> used by Bitcoin. That way you'd get 45% more information into those 5-7
> chars that humans can comfortably pass around (compared to hex),
> resulting in 29 - 40 bits of hash.
>

That might be a small improvement.


> I'm not saying that's enough, either. But in the case of monotone, I'm
> less concerned, because there we have integrated certs, which check
> against the full hash. And just to identify a revision out of the set of
> already validated revisions, 5-7 chars usually are enough. (Sounds
> suspiciously similar to Linus' argument, except that certs are external
> to git, AFAIUI.)
>
> Kind Regards
>
> Markus Wanner
>

It sounds like switching away from SHA1 is even more important for Monotone
than git, since Monotone does intend to provide data integrity against
malicious attackers.

Bill

_______________________________________________
Monotone-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/monotone-devel