Dealing with Ed25519 fingerprinting #6
Replies: 1 comment 1 reply
-
|
From what I understood from the document at the link you gave OpenSSL's behaviour is common with a number of other implementations (i.e. those based on the ref10 reference implementation). Whereas BC is consistent with the strict RFC8032 requirements. But even being consisten 8000 t with the RFC doesn't fix the problem for protocols requiring consensus because: "...the RFC allows either the batched or unbatched verification, even if there were two implementations conforming to the RFC, there would still be no guarantee of compatible behavior." So, it seems to me without some additional spec that is stricter that RFC8032, Ed25519 is not useable in a consensus protocol because you can never be sure that consensus will be reached. I'm not sure this can be fixed without that further spec work. |
Beta Was this translation helpful? Give feedback.
-
|
Oh I'm not thinking about consensus so much (the doc was written by a Zcash person, who is), but more whether it's a security goal to have indistinguishability of implementations based on observing their behaviour. That is, should a new implementation change its behaviour to pretend to be, or at least copy, the behaviour of a widely-used implementation like OpenSSL, or potentially introduce yet another uniquely fingerprintable version? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
@mattcaswell @dghgit There's been some discussion around fingerprinting Ed25519 signatures based on what validation criteria they apply. This means that you can distinguish, for example, OpenSSL from BC from anything else based on how they handle signatures. Is there any value to trying to unify handling to avoid the validation inconsistency/fingerprinting issues, or should we all emulate OpenSSL's handling and hide in the crowd?
Beta Was this translation helpful? Give feedback.
All reactions