Clarify Ed25519ph implementation against GlobalPatform TEE Internal Core API Specification and RFC 8032

[desmetbruno]

Refrences

RFC 8032:
https://datatracker.ietf.org/doc/html/rfc8032#section-5.1
GlobalPlatformTEE Internal Core API Specification:
https://globalplatform.org/wp-content/uploads/2023/07/GPD_TEE_InternalCoreAPI_Spec_v1.3.1.35_PublicRvw.pdf table 6-8
OP-TEE:
https://github.com/OP-TEE/optee_os/blob/master/core/lib/libtomcrypt/src/pk/ed25519/ed25519_sign.c#L91

Context

1. GlobalPlatform states:

• If TEE_ATTR_EDDSA_PREHASH is set to 1 (a=1), then:
  • The algorithm selected is Ed25519ph.
  • The digest parameter is the pre-hashed message.
• If TEE_ATTR_EDDSA_PREHASH is set to 0 (a=0), then:
  • The digest parameter is the message in full.

2. RFC8032 states:
   For Ed25519ph, phflag=1 and PH is SHA512 instead. That is, the input is hashed using SHA-512 before signing with Ed25519.

3. OP-TEE implements:
   According to ed25519ph_sign(), the input buffer is hashed before it is signed.

Issue

GlobalPlatform TEE Internal Core API Specification contradicts both RFC statement and OP-TEE implementation.

Can you confirm whether the GlobalPlatform TEE Internal Core API Specification needs to be fixed or not?
Thanks

[etienne-lms]

I think the GP TEE spec is fine.
In my understanding, "The digest parameter is the pre-hashed message." means the digest used for signing is the caller message, pre-hashed (with SHA512 as per Ed25519ph spec) before signature cmoputation.
And "The digest parameter is the message in full" measn the digest used for signing is the caller raw message without any pre-hashing prior signature computation.

[desmetbruno]

That makes sense as long as digest refers to the buffer passed to the signing algorithm (e,.g. s_ed25519_sign() in OP-TEE).
But table 6-8 in GP TEE spec describes TEE_AsymmetricSignDigest() and its parameters, and digest is one of them, which is confusing.