GNU bug report logs - #41382
[PATCH 0/6] Allow for a cryptographic hash function migration

Previous Next

Full log

Message #29 received at 41382 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>, 41382 <at> debbugs.gnu.org
Cc: guix-devel <at> gnu.org
Subject: Re: [bug#41382] [PATCH 0/6] Allow for a cryptographic hash function
 migration
Date: Tue, 19 May 2020 20:00:34 +0200

[Message part 1 (text/plain, inline)]

Ludovic,

(+ guix-devel)

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hello,
>
> Ludovic Courtès <ludo <at> gnu.org> skribis:
>
>> Another option would be to create a <hash> data type that specifies
>> its algorithm and its value.  We’d replace the ‘sha256’ field with
>> a ‘hash’ field of that type (in a backward-compatible way).  Thinking
>> about it, this is perhaps the better option.
>
> Here’s a v2 that does that: instead of adding a ‘sha512’ field to
> <origin>, it replaces the ‘sha256’ field with ‘hash’ and introduces a
> <content-hash> data type (similar to the <uuid> data type we have).
>
> One can now write things like:
>
>   (origin
>     ;; …
>     (hash (content-hash (base64 "…") sha512)))
>
> Since it’s a bit verbose, one can also pass a literal string directly,
> in which case it’s base32-decoded:
>
>   (origin
>     ;; …
>     (hash (content-hash "…")))
>
> ‘content-hash’ uses macrology to validate as much as possible at
> macro-expansion time.
>
> There’s a compatibility ‘origin’ macro intended to allow people to keep
> writing:
>
>   (origin
>     (url …)
>     (method …)
>     (sha256 …))
>
> and to automatically “convert” the ‘sha256’ field specification to a
> ‘content-hash’.  Due to the way identifiers are matched, there are cases
> where we can’t preserve the illusion of compatibility, as can be seen
> with the patch below.  Perhaps that’s acceptable, though.
>
> Thoughts?

This is a great initiative, and the patches LGTM.

I think that if we are to move away from SHA256, we should go with
something that is immune to length extension attacks[0] such as BLAKE2/3
or SHA-3 (Keccak).

Although I don't know any Guile implementations of those as of yet.

SHA512 does not improve much security-wise IMO, but maybe it's
worthwhile as s stop-gap.

0: https://en.wikipedia.org/wiki/Length_extension_attack

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.