Discussion: Removing signature parameter from Ed25519 verification

[hmatthieu]

Hello :),

First, thank you for your work on this example. I was able to set up and test the implementation, and it works great.

I've been reviewing the Ed25519 verification logic and believe we can safely remove the sig parameter from the verification functions without compromising security. Here's my reasoning and I would love to have your feedback:

1. Signature is already embedded in the instruction: We retrieve the signature directly from the Ed25519Program instruction data.

2. Message is a cryptographic hash: The message being signed is typically a hash (using solana_program::hash::hashv or SHA256) of our program's instruction arguments, plus additional parameters like expiration timestamps.

3. Our verification logic already handles the essential checks: We verify that:

   • The public key matches between our instruction and the Ed25519Program instruction
   • The reconstructed message hash matches the one passed to the Ed25519Program
   • The signature is the result of message hash signed by public key

The verification logic would still validate without this extra signature passed as a parameter.

Does this analysis make sense? I believe this change would simplify the API without reducing security.

I'd love to hear your thoughts on whether this approach is sound or if there are security considerations I might be missing.

Thanks :)

[GuidoDipietro]

Hi!

Thanks for the feedback. Looking back on my implementation, I feel like I included the message on the custom program instruction data to be extra cautious in case I was missing any possible exploit or something. Better safe than sorry, I thought. But your analysis makes sense to me.

I think points 1. and 3. are enough to prove that it isn't needed. The signature check against the native program ix data is irrelevant as it is already checked on the native program; we just care to check that the pubkey and signed message are what we expect. I think this not only simplifies the API, but also the program logic and compute slightly - so I like it!

Makes me think if the entire program could be significantly simplified, given we just care about two parameters...

I'll note however that point 2. and the second subitem on point 3. are not correct; I'm not passing a hash as the message here, but rather the raw message before hashing. Moreover, why is it relevant for the inclusion or not of the sig parameter?

Anyway, feel free to open a PR with these changes. I'd love to review them as well. Also I think all this applies for Secp256k1 similarly.

Mandatory disclaimer, I'm not a cryptography expert and rather just an engineer who was curious enough to come up with this as there weren't any other resources online. There still might be exploits I'd have no idea about. Love if anybody with more knowledge on the matter could contribute to this in this discussion here.