Tag Info

Hot answers tagged

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

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


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


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


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

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


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

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

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

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

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


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

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



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