# Tag Info

3

rand() is bad because it's not a random function - not even a mediocre one. Every library, operating system, yahoo with a keyboard, can write his own rand and get away with it. The purpose of rand is to give output that looks random enough to be used in non-critical applications, usually with an LCG. Once in a blue moon you might come across some library ...

3

In the example you linked, the current time (specifically, a value representing the number of seconds elapsed since Jan 1, 1970 UTC) is used as the seed. If an attacker knows which year you generated your key, then that leaves only about 2^25 possible values for the seed --- and therefore only about 2^25 possible values for your key. At this point, he can ...

2

($\hspace{.02 in}$packet $\approx$ chunk) They put a packet number into the plaintexts, and mac-then-encrypt the packets separately.

3

To use the proper terminology: in TLS, cipher suites which include "some Diffie-Hellman" are: Anonymous Diffie-Hellman: DH_anon Static Diffie-Hellman: DH-RSA, DH-DSS... Ephemeral Diffie-Hellman: DHE-RSA, DHE-DSS... There is no "plain DHE" cipher suite in TLS; it is called "DH_anon". As the name indicates, with DH_anon, the server is "anonymous": you ...

2

No, DHE is secure and allows to share a common secret between two parties over an insecure channel. But you cannot know, if the one you share the secret with is the one you want (DHE is vulnerable to man in the middle attacks). So DHE-RSA uses DHE to share a common secret and signs the communication with RSA to make sure, that both persons communicate with ...

4

Yes, you're misinterpretting the PRF. It's not just a hash function (and when you hit the end of the function function, start back at the beginning). Instead, if is a function that generates a rather long (actually, infinite) output; we use the first $N$ bits of that output to populate the various key values. See section 5 of RFC5246; we have: TLS's ...

2

A Diffie-Hellman key agreement has the following general form, presuming it is done in a group $G$ of order $q$ with generator $g$: $A$: Generate $x \in \mathbb{Z}_q$ at random. Calculate $X = g^x$ $B$: Generate $y \in \mathbb{Z}_q$ at random. Calculate $Y = g^y$ $A \to B$: $X$ $B \to A$: $Y$ $A$: Calculate $S = Y^x$ $B$: Calculate $S = X^y$ First ...

2

It is unclear if you wanted to compare TLS 1.1 PRF or TLS 1.2 PRF. Different TLS versions have different PRFs. Assuming you meant TLS 1.1 PRF although you linked TLS 1.2 RFC. TLS 1.1 PRF Short: HKDF is commonly a better choice than TLS 1.1 PRF, but not always. Consider these aspects: HKDF is a generic construct. HKDF is extract and expand. TLS1.1 PRF ...

3

Switch from plain to encrypted is marked by a special record type called change_cipher_spec (which is neither handshake, alert or application_data); it is unambiguous. Plus, the moment the switch occurs is quite clear from the client point of view, given the previous handshake messages. If unsure, have a look at the actual standard, which is quite clear ...

0

The SSL/TLS handshake consists of a series of messages which do keyexchange and (usually) authentication together. See rfc5246 or its predecessors or Wikipedia for details. The handshake actually results in one "premaster secret" and one "master secret" which is then used to derive multiple keys: an encryption key for each direction (for an algorithm that ...

2

Yes, you have the basic idea. Session-id info is stored (cached) at both ends; ticket is stored only at client, encrypted by server. Both re-use the "key exchange" which in SSL/TLS is actually key exchange combined with authentication; although authentication can be both directions (server and client) and thus an "exchange" of certs, it is usually ...

Top 50 recent answers are included