Lets suppose we have a communication protocol given where messages $(1)$ and $(2)$ are send over an unsecure network.

There are some prerequisites like distributed certificates etc., but they should not matter for this question).

Message (1) is send as plaintext from $A$ to $B$ and does contain the identity of $A$. Party $B$ responds with a signature over the received identity and some other data (e.g. a public DH key) and sends it over to $A$.

A protocol that starts like this design allows an attacker to get a lot of signatures (as much as needed) and the input is even something under his control (the identity of $A$).

In my opinion this may open door to a lot of attacks the attacker can use. I don't know any but I can imagine that have been some and this kind of design should always be avoided.

I am open for any kind of comment on this. Especially if there were some relevant attacks in the past.


In my opinion this may open door to a lot of attacks the attacker can use.

Actually, public key signatures are designed to be used securely like this. When we design a signature method, we assume that the attacker can ask for a large number of messages of his choosing to be signed, and still try to ensure that the attacker cannot generate a valid signature for a message that he did not ask to be signed (or recover the private key) - if someone can show a method, we consider that signature method as broken, and discard it.

However, there is one possible avenue for the attacker; if he submits the identity $Eve$, and gets the signature for $(Eve, DHPublicKey)$, he now has a valid message/signature pair, which would verify just fine. If he can use that signature somehow in an attack, well, that's one thing that the signature method doesn't protect you against. Of course, it's possible that there is no such attack (for example, if the attacker doesn't know the $DHPrivateKey$ that corresponds the to $DHPublicKey$ in your message), however that is something you need to consider.

  • $\begingroup$ If I can send you an arbitrary binary blob, and you'll send me back a signature for that blob no questions asked, then that's just as good as having your private key in terms of what signatures I can produce. A good protocol should have something that the signer is checking before they produce a signature; some property that they are attesting they agree is true; or else why bother with a signature at all? $\endgroup$ – Daniel Wagner Oct 22 '19 at 0:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy