The situation: We have a custom PKI with clients communicating with the server over standard SSL/TLS encrypted channel. PKI uses ECC, server certificate supports ECDHE_ECDSA key exchange mechanism and is signed using our custom CA. Clients are authenticated to the server using their client certificates containing ECDSA public keys.

In addition, clients also communicate with each other - this channel is not encrypted and we only use a simple challenge-response protocol for unilateral authentication (only one side needs to be authenticated). The challenge-response protocol is taken from the Handbook of Applied Cryptography (10.3.3(ii)2., PDF) and goes as follows:

$A ← B : r_B$

$A → B : cert_A , r_A , id_B, S_A (r_A, r_B, id_B)$


  • $r_B$ is a random challenge generated by $B$.
  • $cert_A$ is $A$'s certificate.
  • $id_B$ is an identifier of $B$.
  • $r_A$ is a random number generated by $A$ to prevent chosen-text attacks.
  • $S_A(r_A, r_B, id_B)$ is a signature computed over concatenated values of $r_A$, $r_B$ and $id_B$ using $A$'s private key corresponding to $cert_A$'s public key.

So, $cert_A$ and corresponding $A$'s private key are reused in SSL/TLS and the challenge-response protocol. Are there any bad consequences of this approach? Any suggestions? Thanks.

  • $\begingroup$ I'm curious: Why don't you use TLS for peer-to-peer communication as well? $\endgroup$
    – SEJPM
    Apr 2, 2016 at 18:45
  • $\begingroup$ Clients are mobile devices and communication is done over NFC, so we wanted to keep the number of messages low and make it as simple as possible. Also, encryption is not required for this channel. $\endgroup$
    – mirocslav
    Apr 4, 2016 at 6:41

1 Answer 1


No, there are no problems (which I could see) with re-using the signature key in this scenario.

There are two potential concerns:

  1. It may be possible to learn something about the private key using the challenge-response protocol
  2. It may be possible to re-use the signature of a run of the challenge-response protocol for TLS

The first concern is clearly invalid, as any decent signature won't allow you to learn anything about the private key just be asking for signatures of (chosen) messages (this is the standard security notion for signature schemes). The same argument holds for TLS' client authentication.

The second concern is also invalid as an attacker can't control the messages being signed in neither TLS nor the challenge-response protocol. In TLS, the client signs the complete transcript being exchanged yet, including the client's random and the server's random value, which the attacker can't control both. The same argument holds for this scheme. While the attacker can control $r_B$, he can't control $r_A$ and thereby he would have to hope that the random values repeat in the protocol (extremely unlikely) or that the hash to be signed is the same in TLS, which would imply a collision on the hash function, which is extremely unlikely if the hash function is chosen somewhat decently (like SHA-256).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.