# Tag Info

8

There's no real difference between $p$ and $q$ in RSA. It looks like OpenSSL just has the agreement "$p$ has to be bigger than $q$" for conveniences. One of the numbers has to be bigger than the other (otherwise they would be the same number, and $p = q$ is very bad in RSA). Just use two examples: $p = 13$ and $q = 11$. $p$ is bigger than $q$, all right. ...

8

Is it true the longer the key length is the more secure the encryption? No. Key length does put an upper bound on security, because it determines the complexity of brute force iteration of the key space or factoring, discrete log, etc. for some asymmetric algorithms. However, once you have a long enough key to make brute force attacks impossible, there ...

7

For what it's worth, the OpenSSL developers have committed changes that improve this. I assume they will be in OpenSSL 1.0.2, but I don't know for sure. In any case, if you clone the git repo and compile the OpenSSL_1_0_2-stable branch (or master, I suppose), s_client will display the curve name: $OPENSSL_CONF=apps/openssl.cnf apps/openssl s_client -CApath ... 6 Short answer: There would be nothing (that isn't already wrong with TLS) necessarily wrong with a CTR + HMAC cipher suite, but the technical merits are only one factor in a technical feature getting to RFC status in the TLS working group. Without being discourteous to the TLS Working Group (WG) participants or process, other reasons can be: political ... 6 To make it easier for humans to read. 6 The main thing that makes HMAC secure in typical use even with MD5 is that it is used with a secret key. That means only preimage attacks are really relevant, since finding a collision is always an online attack if you don't know the key. With known attacks the preimage resistance of both MD5 and SHA-1 is > 100 bits. Additionally, HMAC may be secure even ... 6 I don't know about computing things in parallel, so I will ignore that part of the question. First, please note that the encryption algorithm is rarely the the weak point of the security. It is far more likely that you will have problems with the implementation, some spyware installed on your computer, a weak password (If you use qwerty as your password, ... 5 RFC 6176 lists four reasons why SSL 2.0 must not be used, in its section 2: Message authentication uses MD5 [MD5]. Most security-aware users have already moved away from any use of MD5 [RFC6151]. Handshake messages are not protected. This permits a man-in-the- middle to trick the client into picking a weaker cipher suite than it would ... 5 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 ... 5 First, I am assuming, per https://security.stackexchange.com/questions/29172/what-changed-between-tls-and-dtls, that the client handshake protocol in DTLS is not different from that in TLS over TCP. This seems a safe bet since the client/server encrypted handshake protocol in OpenVPN's UDP implementation is the same as in standard TLS over TCP. I am not ... 5 In a better world, TLS_FALLBACK_SCSV would not be necessary: SSL has been supporting downgrade-proof version negotiation since at least SSL 3.0, so a man in the middle should never be able to limit a connection to a version older than the mutually supported maximum. However, out there are some broken servers that don't really support that kind of version ... 4 Obviously, as long as the AES-128 (TLS) channel is keyed independently from the AES-256 (file encryption), the TLS encryption cannot damage the file encryption. Let us consider what would be true if it could. If that somehow did weaken the file encryption, this would allow this attack on an encrypted file – he could take that encrypted file, and send it ... 4 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 ...

4

Well, it is certainly possible to generate an RSA public/private key pair like what you're asking about -- I don't know what the OpenSSL API allows you can do, but if you don't restrict yourself to that, well, it is certainly possible to craft such a keypair. You'll come up with a public key with an enormous exponent (and I wouldn't be shocked if not ...

4

From RFC 5246, section 6.2.3.3: AEAD Ciphers: AEAD ciphers take as input a single key, a nonce, a plaintext, and "additional data" to be included in the authentication check, as described in Section 2.1 of [AEAD]. The key is either the client_write_key or the server_write_key. No MAC key is used. However in RFC 5246, section 5: HMAC ...

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

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 ...

3

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 ...

3

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 ...

3

Something tells me you didn't put much research effort into this one. Let me quote part of a distantly related Crypto.SE question by @D.W.: SSL 3 included special mitigations to prevent protocol downgrade attacks where a man-in-the-middle downgraded two SSL3-capable endpoints so they end up using SSL 2. This protection in SSL 3 was critical, because ...

3

You can use RSA to exchange the keys, But the problem is, it does not provide perfect forward security. This is what may happen if you use RSA for key exchange. If someone is able to store your SSL session and if he can get the server private key, He can get the secret key generated by the SSL session. So he can decrypt the entire SSL session. So we use ...

3

Feasible? Sure, there are lattice algorithms that are competitive in performance with RSA. However, there are drawbacks, like: They've been studied less than RSA or ECC, especially the individual algorithms. The most well studied system, NTRU, is patented. No generic proof that I know of that there isn't a quantum algorithm to solve them. The first one ...

3

SSL does not generate a private key. What is generated is shared secret key between the client and server.This shared secret key is only valid till the session lasts. So, this shared secret key resides in the RAM. It is not saved in to the hard disk.

3

In TLS, the key exchange step results in a key called the master secret which is then derived into as much key material as needed with a custom key derivation function, called in TLS terminology the PRF. It is not slow -- contrary to PBKDF2, the "PRF" of TLS is not for handling password and thus has no need to be slow.

3

Symmetric algorithms are secure post-quantum, only with less bits of security (usually about half). That means you only need to care about the authentication and key exchange parts of the cipher suite. Suites that don't use public key authentication or key exchange, i.e. preshared key suites, are post-quantum secure, but not useful in most usecases. There ...

3

Like all things in life, there are tradeoffs to be balanced. SSL can use RSA keys, right? So why not generate 2 billion bit RSA keys? Well, the efficiency of RSA goes down significantly as more bits are added. With too large of keys, RSA would be impractical to use in real life. Another answer to your question is that 5000-bit AES does not exist. We are ...

3

The certificate makes sure that whoever you're talking to is who they claim they are. With TLS/SSL without certs you wouldn't notice if you're communicating with an impostor over an encrypted channel instead of whoever you're expecting to communicate with. This leads to so called man-in-the-middle attacks. You really should read this, if you're going to use ...

3

So that the server knows who you are. After all, TLS protects the communication; however anyone can initiate a TLS connection to the server (unless the server insists that client authentication must be used; they rarely do). So, if the server needs to make any decision based on who the client is, it needs to find that out itself; TLS usually won't provide ...

Only top voted, non community-wiki answers of a minimum length are eligible