Wireshark mailing list archives
Re: seeking a info for clearing a confusion
From: Peter Wu <peter () lekensteyn nl>
Date: Thu, 28 Sep 2017 10:53:58 +0100
Hi Sadik, On Wed, Sep 27, 2017 at 07:14:02PM +0200, Sadik Sikder wrote:
Hello all I am developing for myself own Decryption system for my own packet analyzer. During developing stage i have some confusion following i hava confusion regarding pre_master_secret. according to IETF 8.1 <https://tools.ietf.org/html/rfc5246#section-8.1>. Computing the Master Secret For all key exchange methods, the same algorithm is used to convert the pre_master_secret into the master_secret. The pre_master_secret should be deleted from memory once the master_secret has been computed. master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47]; The master secret is always exactly 48 bytes in length. The length of the premaster secret will vary depending on key exchange method. ----------------------------------------------------------------------- my question is about pre_master_secret, is this pre_master_secret generated by encrypting client.rando[32][] by server public exponent?
No, the client creates *another* random value of 48 bytes (not 32) as mentioned in https://tools.ietf.org/html/rfc5246#section-7.4.7.1 That is the case for the RSA key exchange method. In case of (EC)DHE, the premaster secret is the shared secret obtained from the Diffie-Hellman key exchange.
6.3 <https://tools.ietf.org/html/rfc5246#section-6.3>. Key Calculation The Record Protocol requires an algorithm to generate keys required by the current connection state (see Appendix A.6 <https://tools.ietf.org/html/rfc5246#appendix-A.6>) from the security parameters provided by the handshake protocol. The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. Each of these is generated from the byte sequence in that order. Unused values are empty. Some AEAD ciphers may additionally require a client write IV and a server write IV (see Section 6.2.3.3 <https://tools.ietf.org/html/rfc5246#section-6.2.3.3>). When keys and MAC keys are generated, the master secret is used as an entropy source. To generate the key material, compute key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); Q: my question is here about "SecurityParameters.master_secret" , what is this master_secret? is this same value (if i am not wrong )of master.secret generated by CLIENT_RANDOM <space> <64 bytes of hex encoded client_random> <space> <96 bytes of hex encoded *master secret*>?
That master_secret is indeed written to the keylog file, search for "CLIENT_RANDOM" in the packet-ssl-utils.c for a comment describing this. It is computed per section 8.1 which you linked above. Note that if the Extended Master Secret TLS extension is in use, the master secret would include the whole handshake and not just the client+server random. See https://tools.ietf.org/html/rfc7627 and https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10686 for a pcap. -- Kind regards, Peter Wu https://lekensteyn.nl ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- seeking a info for clearing a confusion Sadik Sikder (Sep 27)
- Re: seeking a info for clearing a confusion Peter Wu (Sep 28)