Allow Verifying Signatures with Recoverable Keys Without Specifying Public Key

[billyb2]

The sign function has an option of creating a signature with a recoverable public key. However, the verify function does not take advantage of this, and the public key still needs to be specified. Though the recover function can be used like so:

curve.verify(signature, data, curve.recover(signature, data))

This is kind of redundant, and could be done by the user simply not specifying a public key i.e. curve.verify(signature, data). The verify function, inside of the check for recoverable signatures, could simply extract the public key, and then use that, unless a different public key is specified.

[billyb2]

Having issues getting it to work, and not understanding where I'm going wrong necessarily. Much more info in https://github.com/imachug/sslcrypto/commit/48a2e5a771c70f7024f0870ce0cb5a9c0a4f5654

[purplesyringa]

I am not sure about the use case of this. Verification without a public key only validates the format of the message, not the integrity and security. If someone accidentally forgets to specify the key, they get a security problem. What about a separate function validate_signature_format instead?

[billyb2]

I apologize, would you mind explaining why it would only validate the format? Also, I'd be happy to do that.

[purplesyringa]

recover and verify are normally used in the following cases:

• You want to make sure the message was received from the expected party. That's when you use verify.
• You want to make sure the message was received from one of the trusted parties, or you want to find out who it came from. That's when you use recover.

I think what you're suggesting is to allow verify work without the key specified.

• In case the signature is correct, recover returns some public key, which may or may not be someone whom you trust, and then verify returns True. As this check does not verify data authorship and does not handle authorization, it is almost always not safe to use the signature without further verification.
• In case the signature is invalid, recover throws an error.

I'm afraid that if verify worked without an explicit public key, someone might accidentally forget to specify it and thus introduce a security hole. On the other hand, if one doesn't know authorship beforehand, it is almost always necessary to call recover at some point to check it, and I don't see a reason not to call recover right at the moment.

TL;DR: Introducing verify without an explicit key increases a security hole probability, while its behavior, if absolutely necessary, can be simulated by calling recover inside a try..except block.

[billyb2]

I understand much better now, thank you. Although, even if it doesn't check the data's authorship, would it not be able to check the message's integrity? If so, would that be useful as a separate function?

[purplesyringa]

That might be useful for, say, transit traffic if you want to filter out invalid data (not signatures) but you don't know what public key to verify them against. So I agree this might sometimes be useful. What about validate_signature_integrity?