Re: [Cfrg] Poll: hash functions for Ed448 (ends on December 22nd)

[Ilari Liusvaara <[e-mail]>]

On Wed, Dec 09, 2015 at 09:56:08AM +0100, Simon Josefsson wrote:
> 
> I have started to feel that the fact that we can have this poll with no
> real-world feedback from experience with deployed Ed448 implementations
> is a sign that standardizing Ed448 is premature.  There simply appears
> to be little interest from implementers, at least from what I can see
> From my perspective.  I suppose it may be too late to back down from
> this tree though.

Well, if we had deployed Ed448 implementations, this whole poll would
likely have been unnecressary...

That said, there doesn't appear to be that much disagreement on the
main hash, just on prehash (which I think is more of invitation to
misuse, anyway).


That said, having written Python (reference) and C implementations for
Ed448, I would consider following proposals above others in
implementation annoyance (at least for modifying the present
implementation):


1) Twoshakes-d:
---------------
The contexts percollate all the way to the global API, and aren't
supported on Ed25519 anyway. Hashes are now multi-input and there
is now coupling between the prehash and primary.

(Yes, my proposal while back did similar things, but the API I
had in implementations was designed differently and cut in different
place).


2) Ilari 2:
-----------
Multi-input structure of HKDF is poor match for hash-function-like
construct. Needs IUF in IKM for efficient operation (wonder how many
ready-made implementations are capable of that?).


... Then there are non-implementation problems like speed problems
(SHA3-512) and bad usecases (SHA-512 prehash).




-Ilari