[Dcrup] Re: [standards] [Editorial Errata Reported] RFC8463 (7930)

[Alessandro Vesely <[e-mail]>]

On Mon 13/May/2024 14:26:48 +0200 Viktor Dukhovni wrote:
> On Mon, May 13, 2024 at 01:15:59PM +0200, Alessandro Vesely wrote:
> 
>> I'm not much into crypto, so I don't understand why Section 4 of RFC
>> 8032 says HashEdDSA would be less collision resistant (after SHA256)
>> than PureEdDSA. However, I understand single-pass interface for
>> creating signatures.
> 
> The construction of pure EdDSA makes it difficult to exploit collisions
> in the underlying hash function, because the message is prefixed with
> an octet-string that an attacker cannot predict, and depends on both
> the message and the signer's secret key (a deterministic variant of
> Schnorr signatures).
> 
> This is not the case with the Hash (ph) variants, which digest the
> input before signing.


Fine.  Yet, SHA256 should itself be collision resistant, so it doesn't seem 
there are practical ways to obtain collisions.


>> It seems to me we're using HashEdDSA, aren't we?
> 
> No, because of "domain separation", HashDSA(m) != PureDSA(hash(m)), even
> if the chosen hash is SHA512, but in any case HashDSA always uses
> SHA512, whereas with DKIM, SHA256 is the more likely choice.


Would it be called HashEdDSA-SHA256?  The eleventh parameter of EdDSA is 
described as:

    11.  A "prehash" function PH.  PureEdDSA means EdDSA where PH is the
         identity function, i.e., PH(M) = M.  HashEdDSA means EdDSA where
         PH generates a short output, no matter how long the message is;
         for example, PH(M) = SHA-512(M).

It says /for example/, which can be understood to mean that one could use 
another hash function.  Albeit it later says "For Ed25519ph, phflag=1 and PH is 
SHA512 instead", /Ed25519ph/ is not HashEdDSA.

However, in practice, we neither pass the whole message nor the hash function. 
It looks like we pass the hash as if it were the message.  Isn't this pre-hashing?


Best
Ale
--