Subject: [Dcrup] DKIM-Signing hashes with Ed25519

From: Дилян Палаузов <[email-masked]>
Date: Wed, 14 Nov 2018 21:44:22 +0000

Hello,

the algoritm described in RFC 6376 “DomainKeys Identified Mail (DKIM)
Signatures” for signing a message is:

1. Normalize/Canonicalize (Section 5.3)
2. Compute hash (Section 5.5): “The Signer MUST compute the message
hash as described in Section 3.7 and then sign it using the selected
public-key algorithm.”
3. Sign the hash (Section 5.6):  “The DKIM-Signature header field MUST
be the same as used to compute the hash as described above, except that
the value of the "b=" tag MUST be the appropriately signed hash
computed in the previous step…”

This RFC describes the rsa-sha256 algorithm for signing (for the
aforementioned hash).

RFC 8463 “A New Cryptographic Signature Method for DomainKeys
Identified Mail (DKIM)” adds the Ed25519-SHA256 signing algorithm
(Section 3): “The Ed25519-SHA256 signing algorithm computes a message
hash as defined in Section 3 of [RFC6376] using SHA-256 [FIPS-180-4-
2015] as the hash-alg.  It signs the hash with the PureEdDSA variant
Ed25519, as defined in RFC 8032, Section 5.1 [RFC8032].”

At https://www.ietf.org/mail-archive/web/dcrup/current/msg00501.html is
stated, that GnuTLS does ED25519 signing of data, but not of hashed —
ED25519 is not meant for the latter.  The answer at 
https://www.ietf.org/mail-archive/web/dcrup/current/msg00502.html says,
that “if the spec says there’s a pure version that doesn’t hash its
input, the library would implement it.”

I asked at https://gitlab.com/gnutls/gnutls/issues/613 to enhance
GnuTLs to sign per RFC 8463.  The answer is, that there is a pure
EdDSA, which can sign data.  A pre-hashed-EdDSA version, which can sign
hashes, is not standardized.

Please join https://gitlab.com/gnutls/gnutls/issues/613 to explain what
signing ED25519 hashes mean and how and shall it be implemented.

Regards
  Дилян

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 14 Nov 2018 23:28:43 +0000

> hashes, is not standardized.

It certainly confused me when I was implementing it for Exim.  Despite
being called "pure" it does a hash on the data, and signs the hash.
You can't sign raw data, and you can't sign a separately computed
hash.  What DKIM requires is that you precompute a sha256 hash
(just like you would for RSA-signing) and then feed it to this
(oddly-named) "pure" routine for signing.

So you get the signature of a SHA512-hash of a SHA256-hash of the
headers.  Yup, hashed twice.  No, I don't know why.

But you _can_ do it with the provided interfaces in both GnuTLS and
OpenSSL.
-- 
Cheers,
  Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 14 Nov 2018 18:39:24 -0500

> On Nov 14, 2018, at 4:44 PM, Дилян Палаузов <[email-masked]> wrote:
> 

Suppose a + b = c, then we also say: a = c - b.

This just boils down hair-splitting as to what is the message, and what
is the signature function.

Traditionally, you take a message M and sign it with a signature function
that employs a signing algorithm S combined with a hash function H:

  let f = Sign(S, H, keys)
      signature = f(metadata || M)

Now with Ed25519 the signature primitive signs data directly, it is not
parametrized by a hash algorithm.  So the RFC boils down to:

	let f = Ed25519(keys)
	    signature = f(metadata || H(M))

i.e. instead of signing the "message" M, you sign the message H(M).
That's it.  All that changes is whether the hash H is part of the
signature function, or is used separately to prepare the message.

In general uses of Ed25519, whether to pre-hash the message or
not is an implementation choice.  The pure construction with
no pre-hash has better collision-resistance than you get with
pre-hashing, but it requires the whole message to be in memory
at the same time, so is only well-suited to sufficiently short
messages:

  https://tools.ietf.org/html/rfc8032#section-4

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 14 Nov 2018 23:37:06 -0500

>headers.  Yup, hashed twice.  No, I don't know why.

We asked around and the advice we got was that the pure version of
ed25519 was likely to be much more widely implemented than HashEdDSA.  We found
the single and double hash thing pretty confusing too, but as I read
RFC8032, PureEdDSA does *not* do the second sha-512 hash while HashEdDSA does.

By the way, have you checked that your code validates the ed25519
example signature in RFC 8463?  I don't think hashing twice will get
the right result.  You might also see whether it interoperates with Scott
Kittermans python DKIM module.

R's,
John

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 15 Nov 2018 10:00:31 +0000

On 15/11/2018 04:37, John Levine wrote:
>   You might also see whether it interoperates with Scott

Scott and I verified interworking, back in February:

https://www.ietf.org/mail-archive/web/dcrup/current/msg00668.html

-- 
Cheers,
  Jeremy

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 15 Nov 2018 13:18:40 +0000

The use of the term "pure" comes from the  cryptographer side of the world, where these deterministic ECC signatures were created.  It is confusing.  Just like "perfect forward secrecy."
	/r$