0

I am using ECDSA P-384 for signing and verifying messages. The messages are basically stringified JSON.

Should the public key be included inside the message (aka the JSON which gets stringified)? Or should I send the public key separately along with the stringified JSON and the signature?

Does it make any difference?

The reason I ask is because if the public key is included inside the message (stringified JSON), then on the recipient side, first, I have to parse the JSON, then extract the public key, then do the verification. This seems a bit wasteful.

Instead, if I simply included the public key separately along with the message and the signature of the message, then I won't have to parse the message first to extract the public key.

sudoExclaimationExclaimation
  • 7,992
  • 10
  • 47
  • 105
  • This isn't really a programming or development problem. It doesn't matter to security whether the key (or even the keyid) is included in the signature; some schemes do include and some don't, mostly depending on which is convenient. And assuming your recipient is going to actually do something with these messages (not just chuck them all in the garbage bin) it will need to parse the JSON anyway so I don't see how that's wasteful. ... – dave_thompson_085 Jun 26 '23 at 06:14
  • ... However if your relier (recipient) _uses_ a key from the message (signed by the sender or not) it is insecure and specifically will accept a forged message as valid; the relier must either get the key by a secure method (which by definition must not be over a channel that needs signature) or in a form which is itself secure (such as a certificate). (And this is the same for all signing algorithms, not just the one you ask about.) – dave_thompson_085 Jun 26 '23 at 06:15
  • @dave_thompson_085 I don't understand your second comment at all. Why is insecure? Why will it accept a forged message? The recipient still has to verify the signature with the key and message, so how is that insecure? – sudoExclaimationExclaimation Jun 26 '23 at 07:18
  • @sudoExclaimationExclaimation: How do you know *who* the message is from? – President James K. Polk Jun 26 '23 at 13:18
  • @PresidentJamesK.Polk Since the recipient receives the: 1. message, 2. public key, 3. signature, it will verify the signature using that message and public key. If verification succeeds, that would confirm the message is from the public key. If it fails, then it would mean the message has been tampered with or someone trying to impersonate and can be discarded. I just need to figure out if there's any need to put the public key inside the message before signing or can it be sent as a separate thing along with the message and signature. In both cases, signature verification will happen. – sudoExclaimationExclaimation Jun 26 '23 at 19:20
  • 1
    If relier trusts the (bare) publickey in the message, attacker just provides a fake message, signature _AND_ publickey. This is trivial. I'm sorry to be cruel, but if you don't see that, you have no hope of designing (or implementing) a protocol that is secure. – dave_thompson_085 Jun 27 '23 at 06:39
  • A better place for this discussion is https://security.stackexchange.com/ or https://crypto.stackexchange.com/. I see you already asked that so putting link here and voting to close. https://crypto.stackexchange.com/questions/106989/when-using-ecdsa-p-384-for-signing-and-verifying-messages-should-the-public-key – Juraj Martinka Jun 27 '23 at 07:15
  • I’m voting to close this question because it's better suited for crypto / security and already there: https://crypto.stackexchange.com/questions/106989/when-using-ecdsa-p-384-for-signing-and-verifying-messages-should-the-public-key – Juraj Martinka Jun 27 '23 at 07:16
  • [cross-posted to crypto](https://crypto.stackexchange.com/q/106989/676). – President James K. Polk Jun 27 '23 at 15:33

0 Answers0