Re: seeking a info for clearing a confusion

[Peter Wu <peter () lekensteyn nl>]

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