Re: [gentoo-dev] Manifest2 hashes, take n+1-th

[R0b0t1]

Hello,

On Thu, Oct 19, 2017 at 2:08 PM, Michał Górny <mgorny@g.o> wrote:
> Hi, everyone.
>
> The previous discussion on Manifest2 hashes pretty much died away
> pending fixes to Portage. Since Portage was fixed a while ago, and we
> can now safely switch, I'd like to reboot the discussion before
> submitting the item for the next Council meeting.
>
> Considering all arguments made so far, I'd like to propose changing:
>
>   manifest-hashes = SHA256 SHA512 WHIRLPOOL
>
> to:
>
>   manifest-hashes = SHA512 SHA3_512
>
> In other words, removing SHA256 and WHIRLPOOL, and adding SHA3_512.
>

In general I do not mind updating the algorithms used, but I do feel
it is important to keep at least three present. Without at least three
(or a larger odd number) it is not possible to break a tie.

That may ultimately be beside the point, as any invalid hashes should
result in the user contacting the developers or doing something else,
but it is hard to know.

>
> Rationale
> ---------
>
> 1. The main argument for using multiple hashes is to prevent the (very
> unlikely) possibility that if a weakness is discovered in one of
> the hashes, the other would still hold. This is given by using two
> algorithms; more than two do not increase security significantly, while
> they do increase performance cost.
>
> 2. For the above to hold, the hashes should be diverse. SHA256
> and SHA512 are the same algorithm, so a weakness discovered in either
> would probably apply to both -- keeping both does not make sense at all.
> Furthermore, both SHA2 and WHIRLPOOL use the same construct (MD), so
> a weakness in the construct would apply to both.
>

Algorithms of different block sizes can easily have different
cryptographic properties.

Notable is https://en.wikipedia.org/wiki/Advanced_Encryption_Standard,
see box. More relevant is https://en.wikipedia.org/wiki/SHA-2.

In general only the computational complexity is affected, but in the
case of AES some attacks work for the larger key lengths that do not
work for smaller ones. There is one other case I am having problems
remembering where a longer keylength led to a massively easier to
attack function.

For SHA3_512, I am worried that some of the novel properties of the
function that do not currently lead to attacks may in the future lead
to attacks.

> 3. Keeping one of the three old hashes is necessary for compatibility
> reasons. Furthermore, the current versions of Portage consider SHA512
> obligatory, so we can't remove it without redesigning Portage first
> (though I think this applies only to developer installs, i.e. those
> creating Manifests).
>
> 4. The new hashes that are stronger and commonly available are
> SHA3/Keccak (using sponges) and BLAKE2 (HAIFA). Both are diverse from
> our current algorithms, so either is a good candidate. The choice of
> Keccak is purely arbitrary (because it's the winner?).
>
> All the above considered, I think it's most reasonable to use two hashes
> with diverse constructs. SHA512 needs to be one of them, for
> compatibility reasons. The other could be either SHA3_512 or BLAKE2B,
> as a strong, future-proof hash. SHA3 is probably a better choice because
> it's going to have more support as the official recommendation.
>

I would like to present my suggestions:

SHA512, (RIPEMD160 | WHIRLPOOL | BLAKE2B), (SHA3_512 | BLAKE2B);

or more definitively:

SHA512, RIPEMD160, BLAKE2B.

My understanding is that whirlpool is the least secure of the 512 bit
hashes, but it would still be a serious undertaking to generate a
collision. If there is any cause to replace it RIPEMD160 is likely a
good candidate. It is similar in operation to the SHA1/2 functions but
was produced by the academic community and is quite dissimilar from
the SHA1/2 family. The "definitive" suggestions provide a wide sample
of time, size, and implementation.

SHA3_512 is novel and may be resistant to attack in ways the others
are not, but it is my opinion that BLAKE2B's author is better known
and respected.

I could also see the combination SHA512, BLAKE2B, SHA3_512 being
desirable, as that selection represents 3 very diverse algorithms.

If the suggestion of RIPEMD160 seems odd, realize that some
distribution platforms still use MD5 along with other functions. It is
fast to compute and with another hash function quite credible. If the
time taken to generate the hashes is a legitimate concern then using a
older, simpler, and heavily optimized function may be better for one
of the choices.

Respectfully,
     R0b0t1