This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 50 lines
!!! Overview
In [TLS], the [{$pagename}] is the [Symmetric Key] used for [Encryption] between the [Protocol Client] and [Protocol Server].[1]
For all [Key-Exchange] methods, the same algorithm is used to convert the [Premaster Secret] into the [{$pagename}]. The [Premaster Secret] should be deleted from memory once the [{$pagename}] has been computed.
The [{$pagename}] is always __exactly 48 bytes in length__. The length of the [Premaster Secret] will vary depending on [Key-Exchange] method.
The [Premaster Secret] is the secret value we sent [ClientKeyExchange]. The [{$pagename}] is simply a string whose [ASCII] bytes (e.g. "6d 61 73 74 65 72 ...") are used. We then concatenate the random values that were sent in the [ClientHello] and [ServerHello].
The [PRF] is the "[Pseudorandom function]" that's also defined in the [TLS] specification and is quite clever. The [Pseudorandom function] combines the secret, the ASCII label, and the seed data we give it by using the keyed-Hash [Message Authentication Code] (HMAC) versions of both [MD5] and [SHA-1] [Cryptographic Hash Functions].
Half of the input is sent to each [Cryptographic Hash Functions]. It's clever because it is quite resistant to attack, even in the face of [Cryptographically Weak] in [MD5] and [SHA-1]. This process can feedback on itself and iterate forever to generate as many bytes as we need.
Following this procedure, we obtain a 48 byte [{$pagename}] of
{{{
4C AF 20 30 8F 4C AA C5 66 4A 02 90 F2 AC 10 00 39 DB 1D E0 1F CB E0 E0 9D D7 E6 BE 62 A4 6C 18 06 AD 79 21 DB 82 1D 53 84 DB 35 A7 1F C1 01 19
}}}
!! Generating Lots of Keys
Now that both sides have a [{$pagename}], the spec shows us how we can derive all the needed session keys we need using the [PRF] to create a "key block" where we will pull data from:
{{{
key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random);
}}}
The bytes from "key_block" are used to populate the following:
{{{
client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]
}}}
Since we're using a stream [Cipher] instead of a block [Cipher] like the Advanced Encryption Standard [AES], we don't need the [Initialization Vectors] ([IVs]). Therefore, we just need two [Message Authentication Code] ([MAC]) keys for each side that are 16 bytes (128 bits) each since the specified [MD5] hash digest size is 16 bytes. In addition, the [RC4] cipher uses a 16 byte (128 bit) key that both sides will need as well. All told, we need 2*16 + 2*16 = 64 bytes from the key block.
Running the [Pseudorandom function], we get these values:
{{{
client_write_MAC_secret = 80 B8 F6 09 51 74 EA DB 29 28 EF 6F 9A B8 81 B0
server_write_MAC_secret = 67 7C 96 7B 70 C5 BC 62 9D 1D 1F 4A A6 79 81 61
client_write_key = 32 13 2C DD 1B 39 36 40 84 4A DE E5 6C 52 46 72
server_write_key = 58 36 C4 0D 8C 7C 74 DA 6D B7 34 0A 91 B6 8F A7
}}}
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [The First Few Milliseconds of an HTTPS Connection|http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html|target='_blank'] - based on information obtained 2015-03-15
* [#2] - [Client Key Exchange|http://www.umsl.edu/~sbxvd/Client%20Key%20Exchange.html|target='_blank'] - based on information obtained 2015-03-16