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

[Bill Cox]

On Tue, Feb 16, 2016 at 8:19 AM, Markus Wanner <address@hidden> 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