On Tue, Aug 11, 2015 at 9:21 AM, Peter Gutmann
<pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz>
wrote:
Phillip Hallam-Baker <phill(_at_)hallambaker(_dot_)com> writes:
There is a very clear need for 512 bits and there is a case for 256 bits.
What's the clear need for -512? By which I mean a demonstrated practical
need
for a hash size of 64 bytes, not a hypothesised need given an imaginary
attack. I can see a need for SHA-256 (to replace SHA-1), but for something
like SHA3-512 all I can see are downsides (compared to SHA2-256).
The CFRG replacement for ECDSA will almost certainly use the 512 bit wide
pipe hash internally.
Dan Bernstein put together a Perl script that shows every algorithm and
every option. If you are going to sign a 1Gb file then you are going to
need multiple trips through the digest function. Now there is of course a
good argument to be made for a faster 256 bit hash for the bulk digest on
that 1Gb file. But you also need one or more digests of fixed bits of data
internally.
So the practical upshot is that if we were to define an absolutely minimal
cryptolib it would almost certainly include the 512 bit digest. The 256 bit
is optional.
Constrained devices still exist. But the constraint on processing speed is
easing up much more quickly than the constraint on code space and working
memory.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp