1

I'm implementing a TLS-like system, which uses ECDHE-RSA-AE-GCM-SHA, and I've faced two interrogations.

At the end of the handshake ( and before the ChangeCipherSpec message), both the client and the server have to build the same Pre-Master Secret.

On what data is based this secret ? Since I haven't found the answer in the RFS's (4492 and 5246), I'd say this :

  • the Server Public ECDHE Key (send within ServerKeyExchange message)
  • the Client Public ECDHE Key (sent, ciphered, with the ClientKeyExchange message)

It's, for me, the logical components, since Mallory couldn't retrieve the Client Public ECDHE Key, because encrypted with the server PublicKey. If yes, the signature of the ServerkeyExchange message would be wrong, and the Client would know that attempt.

I'm aware that this isn't a proper justification at all, and, when speaking of cryptography, these kinds of reasoning are bad (when not wrong), but since I haven't found the answer in the RFC, all what's left is here...

And moreover, what algorithm do we use to actually build the Pre-Master secret ? Is it a classical hash function (SHA, ...) ?

I know that SHA is used for expanding the MasterSecret (from the random numbers and the Pre-Patser Secret), but for its little brother I'm in the fog...

Community
  • 1
3isenHeim
  • 313
  • 2
  • 13
  • I want to mention that writing your own crypto is hard and writing secure crypto is really hard. If there's anyway you can use an existing, well-tested system, you'll likely be better off. – Neil Smithline Sep 11 '15 at 03:57
  • 1
    @RoraZ 81597 is mostly about the derivation of masterkey and working keys for TLS1.0 and 1.1, not TLS1.2 as referenced here. EisenHeim: the key-derivation uses MD5 *and* SHA1 in SSL3 and TLS1.0 and 1.1 but in TLS1.2 it uses SHA256 for most ciphersuites and SHA384 for a few. But the *premaster* for ECDHE or ECDH is specified in rfc4492 5.10: "the premaster secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string". – dave_thompson_085 Sep 11 '15 at 06:24

1 Answers1

6

"ECDHE" means "ephemeral Diffie-Hellman (with elliptic curves)". This is what the pre-master secret comes from. The client generates a random DH key pair (a DH private key and the corresponding public key). The server also generates a random DH key pair. They send to each other the public parts of their respective key pairs.

The client uses its private DH key, combined with the DH public key from the server, to obtain the premaster secret.

The server uses its private DH key, combined with the DH public key from the client, to obtain the premaster secret.

By the magic of Diffie-Hellman, they both obtain the same value for the premaster secret. But, still by that magic, eavesdroppers, who only saw the public keys from both client and server but no private DH key at all, cannot rebuild the premaster secret.

("ciphered" is not a word; you probably mean "encrypted". But no, there is no encryption here. The DH public keys are public and, indeed, sent as-is over the wire.)

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • OK, thanks ! I though we had to use a specific algorithm to compute the Pre-Master Secret. And sorry for *cipher*, in french we have a difference between "chiffrer" and "crypter"... – 3isenHeim Sep 11 '15 at 07:38
  • 2
    "Crypter" is not a French word either (although its use is widespread). The correct terms are _chiffrer_ and _déchiffrer_. There is also _décrypter_, which means obtaining the plaintext without knowning the key (i.e. breaking through the encryption systems). The terms _crypter_ and _encrypter_ are tentative imports from the corresponding English terms, but they are not proper. Beware the wrath of the _Académie française_ ! – Thomas Pornin Sep 11 '15 at 12:47
  • Yeah that's what I wanted to explain :P Did that too fast :) – 3isenHeim Sep 11 '15 at 17:44