Mailing List Archive

DKIM mesages with ED25519
Hi together,

im currently finishing my DKIM module for s/qmail genenerically
interfacing with it, given the modules qmail-dksign and qmail-dkverify.

It is based on libdkim (C++) and works already well for RSA-type
message signatures.

Since John Levine is here on this list, I got to have a question for
him:

As far as I understand your RFC 8463 and the underlying ED25519
signature scheme, we have the following situation:

a) The message header and body needs to be hashed (following
canonicalization) given SHA256.

b) The resulting hash value is now subject of ED25591 signature
generation/verification (using itself SHA512 for the input data prior
of computing the 'points' on the curve).

Thus, we end up with the following situation:

c) We have the build the following hash:
sha256(msg-header || msg-body) - after canonicalization.

d) Since ED25591 signatures can't use the 'streaming' format available
  for RSA signatures, we have to feed the above result into 
- EVP_DigestSign (for signing) or
- EVP_DigestVerify (for verification).

Thus, on the bottom line given ED25519, we do not sign the message, but
rather its SHA256 value?

Regards.
--eh.





--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 20FD6E671A94DC1E
PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
Re: DKIM mesages with ED25519 [ In reply to ]
It appears that Erwin Hoffmann <feh@fehcom.de> said:
>d) Since ED25591 signatures can't use the 'streaming' format available
>  for RSA signatures, we have to feed the above result into 
> - EVP_DigestSign (for signing) or
> - EVP_DigestVerify (for verification).
>
>Thus, on the bottom line given ED25519, we do not sign the message, but
>rather its SHA256 value?

DKIM always signs a hash of the headers, which in turn includes a hash of
the body in the (not yet signed) DKIM-Signature header. See section 3 of
RFC 6376. The hash to use is a parameter but in practice should always
be SHA256.

What's a little confusing is that the ed25519 signature uses
PureEdDSA, not HashEdDSA, which skips a second useless rehash inside
the signing algorithm.

R's,
John