In a TLS handshake using ECDHE-RSA, the ServerKeyExchange frame must include the ECDHE ServerPublicKey, signed with its RSA private key, as specified in the RFC 4492. Got it.

Trying to implement an ECDHE-RSA-like exchange this with crypto++, I'm facing a little interrogation : what is the scheme used for signing the frame ?

Is it

  • Signature Schemes with Appendix (SSA)


  • Signature Schemes with Recovery (PSSR) ?

The only advantage of using the PSSR, as said here, it's that you don't send the message, it's incorporated in the signature.

Besides, it's mentioned nowhere in the RFC 5246, nor in the RFC 4492.

Is it a the discretion of the programmer ?

1 Answer 1


The exact signature scheme depends on the protocol version; however, in all cases, it relates to what Crypto++ calls "signature schemes with appendix".

PKCS#1 describes two signature schemes (and two asymmetric encryption schemes, which are not relevant here): the "old one" (called "v1.5") and the "new one" (called "PSS"). SSL/TLS relies on the old one (v1.5).

In PKCS#1 v1.5 signature generation, the following occurs:

  • The data which is to be signed is hashed, with some hash function. Let's call x the resulting sequence of bytes. E.g., if the hash function is SHA-256, then the length of x is 256 bits, i.e. 32 bytes.

  • A header t is added to x. The header is a fixed sequence of bytes that identifies the hash function (technically, x is used as parameter in a DER-encoded ASN.1 structure that also identifies the hash function with an OID; however, it is simpler to think of it as a fixed header).

  • Some bytes are added before the concatenation of t and x, so as to obtain the following structure:

       00 01 FF FF ... FF 00 t x

    That is, a byte of value 0, then a byte of value 1, then some bytes of value FF, then a byte of value 0, then t, then x, are concatenated in that order. The number of "FF" bytes is adjusted so that the total length is exactly the length, in bytes, of the RSA modulus (i.e. 256 bytes for a 2048-bit RSA key). This step is called "PKCS#1 type 1 padding".

  • The padded string is then interpreted as a big integer (using big-endian convention), which then goes into the modular exponentiation that is at the core of the RSA signature scheme.

With TLS-1.2, the signature scheme must be exactly the one above, with a hash function that depends on what the client and server support. With the Signature Algorithms extension, the client specifies in its ClientHello message what kinds of hash functions it can use with the RSA algorithm; if that extension is lacking then the server must assume that the client supports SHA-1. The value of the t header is given explicitly, for the most common hash function, in section 9.2 of PKCS#1.

In previous TLS versions (SSL-3.0, TLS-1.0 and TLS-1.1), the scheme is subtly different: the t header is empty, and x is the concatenation of the MD5 and the SHA-1 hashes of what is to be signed. Thus, the length of t is 0, and the length of x is 36 bytes (16 bytes for the MD5, 20 bytes for the SHA-1). There is no discussion between client and server about which hash functions to use; it is always MD5+SHA-1.

A cursory look at the manual seems to indicate that at least "normal" signatures (for TLS-1.2) can be computed with Crypto++ using RSASS<PKCS1v15, H> where H will be SHA1, SHA256... I do not know if Crypto++ includes code for the older scheme where the hash is the concatenation of MD5 and SHA-1, and there is no header.

  • May I ask you how the t is made? I know that it is a asn1 notation.. but how exactly it is made?
    – Zeta
    Aug 23, 2018 at 13:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .