In #65, we removed the public key as a parameter in sign() operations, re https://github.com/MystenLabs/ed25519-unsafe-libs. What wasn't caught back then and remains now, is the possibility to construct two different AsymmetricSecretKey's, with the same secret seed but different public keys, as the format is seed || pk. This is relevant in settings where the keys can come from to-some-degree untrusted sources.
Therefor, I wish to introduce a check that recomputes the public key from the seed and compares it to the provided. Whether or not this should be an optional check I'm not sure of yet. But at first glance, it seems as if this would be best added in Version::validate_secret_key() impl for V2 and V4, and simply fail if the public keys do not match. It does add some overhead, but increases misuse-resistance.
Edit: InVersion::validate_secret_key() is where the check will be and remain for now.
In #65, we removed the public key as a parameter in
sign()operations, re https://github.com/MystenLabs/ed25519-unsafe-libs. What wasn't caught back then and remains now, is the possibility to construct two differentAsymmetricSecretKey's, with the same secret seed but different public keys, as the format isseed || pk. This is relevant in settings where the keys can come from to-some-degree untrusted sources.Therefor, I wish to introduce a check that recomputes the public key from the seed and compares it to the provided. Whether or not this should be an optional check I'm not sure of yet. But at first glance, it seems as if this would be best added in
Version::validate_secret_key()impl for V2 and V4, and simply fail if the public keys do not match. It does add some overhead, but increases misuse-resistance.Edit: In
Version::validate_secret_key()is where the check will be and remain for now.