# Tag Info

9

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

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

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

7

Copy / paste that key into http://phpseclib.sourceforge.net/x509/asn1parse.php and you'll see that there are several different integers in there. p is there, q is there as is the exponent and several other integers to speed things up by taking advantage of the Chinese Remainder Theorem. The key is encoded using DER and derives semantic meaning via ASN.1. ...

6

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

6

To make it easier for humans to read.

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

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

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

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

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

5

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

5

It is correct that the given private key does not encode a single integer, and that it includes two primes $p$ and $q$. More precisely, that Base64 data encodes a string of bytes, which is an RSAPrivateKey encoded per ASN.1 DER-TLV (and thus BER-TLV) following PKCS#1v2 Appendix A.1.2 (likely restricted to version 0). It decodes to: 30 ASN.1 tag for ...

5

Designing your own crypto protocol (using existing primitives) is dangerous if you're not sufficiently familiar with cryptographic protocol design and the ways such protocols might be attacked. If you wish to gain such familiarity, I'd recommend taking a few introductory crypto courses that focus on protocol design and analysis.* This won't turn you ...

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

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

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

3

I do not know why the OpenSSL implementation specifically does this. However, a branch-less (constant time) implementation of the RSA private key operation, might be slightly more efficient if the parameter $c = q^{-1} \bmod p$ is calculated for $p$ being the greatest prime of the two. Otherwise the value of $J_q = I^{d \bmod q-1} \bmod q$ has to be taken ...

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

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

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

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

2

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

2

This question boils down to, "Are there known-plaintext attacks against AES-256-CBC?" The answer is: No, no such attacks better than brute force are known. This would constitute a catastrophic break in AES-256-CBC, and any cipher broken in such a way would be abandoned rapidly.

2

If the application completely trusts the public key (e.g., runs code signed by it), then you could add "master key change" messages that can be signed by it, that make the application change it's hard-coded key. For additional security, you could require that the new key be additionally signed by a key hopefully separated from the now-compromised one - here ...

2

Assuming this is "usual" HTTPS using SSL/TLS with RSA key exchange, the client generates a random secret, encrypts it with RSA (using the server's public key) and sends it to the server. The server then decrypts it (using its private key), and both generate from this (now shared) secret (and some public data depending on the messages) several keys which are ...

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