Re: [Dcrup] I-D draft-ietf-dcrup-dkim-crypto-06

[Jeremy Harris <[e-mail]>]

On 15/09/17 01:32, John R Levine wrote:
>> JL> I haven't looked in detail at the APIs for Ed25519 crypto, but
>> naively
>> JL> assumed that if the spec says there's a pure version that doesn't
>> hash
>> JL> its input, the libraries would implement it.
>>
>> I thought that the consensus was the opposite.  Wasn't esr demanding
>> that and everyone else arguing the opposite?
> 
> No, that was an unrelated issue of how to publish the verification keys.
> See the WG archives.
> 
>> It is certainly the case the the "pure" version of eddsa is unlikely to
>> get much support by the crypto libraries.
> 
> That seems strange, since the difference between pure and hash is that
> the pure version just skips the hash.  But if it is really the case that
> it will be hard to find pure versions it would be silly buy harmless to
> change the spec to say that it calls the hash version of Ed25519 so it
> rehashes the hash we give it.
> 
> As far as I know rehashing a hash with a reasonable second hash function
> doesn't make it any weaker.

Wouldn't it be more aesthetically pleasing to decouple, for dkim
a=ed25519-sha256 signing, the hash used for the body (sha256 as
specified by the 'a' tag) from the hash used for signing headers
(sha512, I think, but whatever the libraries have tied to
Ed25519 signing)?

[I think we should specify the hash method that goes with
 the signing, too]

The hash of the headers does not appear to be used for anything
but debug output and feeding to the signing stage, at least in
the current Exim implementation of dkim signing.  Doing the
above would avoid the rehash.  Either way (this or the rehash),
Ed25519 signing is going to be different to RSA signing.
-- 
Cheers,
  Jeremy