crypto/ed25519: Implement Ed25519ph

[titanous]

Update, Apr 6 2022: The proposed API is in #31804 (comment).

---

The Ed25519ph variant specified in RFC 8032 allows signing/verifying a message that has already been hashed with SHA-512 without risking the collision-resistant properties of "PureEdDSA" when using the same keys for messages signed using both schemes.

This is useful in at least two scenarios:

1. When the private key is isolated to another piece of hardware and passing the entire message to be signed is not possible, for example when using a HSM and signing messages larger than a few KB.
2. When working with large messages that are too large to be reasonably buffered for the current one-shot API.

This variant can be implemented minimally using the existing crypto.Signer API plus an additional verification function, without encouraging unsafe use by providing easy access to an API that takes an io.Reader or io.Writer.

Due to the additional internal hash initialization, there is no way to implement this without forking the package or upstreaming an implementation patch.

I will send a CL with a proposed implementation.

Relevant: #31727

/cc @zx2c4 @FiloSottile

[gopherbot]

Change https://golang.org/cl/174941 mentions this issue: ed25519: Implement Ed25519ph

[x30n]

+1

[Hades32]

Thanks @titanous , this is just what we needed. Confirmed to behave as the reference implementation (libsodium). 👍

Not sure if this is still in time for 1.13... @FiloSottile

[FiloSottile]

Too late for Go 1.13, targeting Go 1.14. (crypto/ed25519 is now in the standard library.)

[Yawning]

While I understand that the crypto.Signer interface is fixed in stone and can't be changed, if this is going to happen, it would be nice if it supported the full Ed25519ph algorithm as described in the RFC.

As it stands right now, the proposed implementation does not support a domain separation context.

Since there already is a Sign method in the package, and the PR adds VerifyHashed, this could be done by adding SignHashed(privateKey PrivateKey, context, message []byte) []byte and changing the proposed VerifyHashed to take another byte slice.

[FiloSottile]

RFC 8032 defined context independently of pre-hashing, so to support the whole spec we'd also have to support pure Ed25519 with custom context.

I am really not a fan of extending the API surface of a standard library package that should be what we point users to for basic public key signatures. How about this alternative API, which is more extensible and still makes it very opt-in to select the variants?

// Options can be used with PrivateKey.Sign or VerifyWithOptions
// to select Ed25519 variants.
type Options struct {
    // Hash can be zero for regular Ed25519, or crypto.SHA512 for Ed25519ph.
    Hash    crypto.Hash
    Context string
}

func (*Options) HashFunc() crypto.Hash

func VerifyWithOptions(publicKey PublicKey, message, sig []byte, opts *Options) bool

[Yawning]

If this proposed API is accepted, then VerifyHashed as proposed in the PR will go away right? I would be in favor of this, since it seems like a cleaner way to support the functionality.

Nitpicking: Is there any particular reason why Context is a string over []byte? I understand they are fairly interchangeable (and string may be more const friendly). I personally would make it a []byte to make it clear that it is an arbitrary "octet string of at most 255 octets" (and include the size limit in a doc string comment).

[FiloSottile]

If this proposed API is accepted, then VerifyHashed as proposed in the PR will go away right? I would be in favor of this, since it seems like a cleaner way to support the functionality.

Yep.

Nitpicking: Is there any particular reason why Context is a string over []byte? I understand they are fairly interchangeable (and string may be more const friendly). I personally would make it a []byte to make it clear that it is an arbitrary "octet string of at most 255 octets" (and include the size limit in a doc string comment).

Mostly consistency, we've used string for contexts elsewhere, in some cases to make it a different type from the message itself (which is not relevant here). I personally think it fits better the nature of the value, because it's usually fixed or at least immutable, often human-readable, and as you say can be a const.

We should definitely document the max length, thank you.