Re: [Dcrup] I do not like the dcrup ECC document

[Scott Kitterman <[e-mail]>]

On Sunday, July 09, 2017 05:14:13 PM John R Levine wrote:
> >> 3.  EdDSA-SHA256 Signing Algorithm
> >> 
> >>   The eddsa-sha256 signing algorithm computes a message hash as defined
> >>   in section 3 of [RFC6376], and signs it with Ed25519, the EdDSA
> >>   algorithm using the edwards25519 curve, as defined in in RFC 8032
> >>   section 5.1 [RFC8032].  The signing algorithm is PureEdDSA as defined
> >>   in RFC 8032 section 4, since the input to the signing algorithm has
> >>   already been hashed.  The DNS record for the verification public key
> >>   MUST have a "k=eddsa" tag to indicate that the key is an EdDSA rather
> >>   than RSA key.
> >> 
> >> If that's not right, please send text.
> > 
> > PureEdDSA does not take a hash as input, it takes the whole to-be-signed
> > content.
> RFC 6376 describes in great detail in section 3.7 how to create the
> material to be signed.  What it ends up with is a sha-256 hash, but that's
> not the signing algorithm's problem.  I say PureEdDSA to emphasize that it
> doesn't get hashed again.
> 
> As it stands now, the RSA and EdDSA signing algorithms sign the same
> thing.  I suppose I could extensively rewrite the signing instructions so
> that stuff to be signed by RSA is hashed while stuff to be signed by EdDSA
> is not because it'll use HashEdDSA, but that seems a lot of work and a lot
> of code changes for no benefit.

The python crypto library I plan to use for this (python-nacl) supports both.  
Given the current structure of the dkimpy code, it would be much simpler to 
support PureEdDSA.  Having looked at how I would implement this (but not 
having done it yet) I agree with your contention about implementation 
complexity.

Scott K