# Tag Info

34

Academically speaking, RC4 is terrible; it has easy distinguishers ("easy" means "can really be demonstrated in lab conditions"). It is also hard to use properly. However, SSL/TLS uses RC4 correctly, and in practice the shortcomings of RC4 have no real importance. The power-that-be at Google decided to switch to RC4 by default because of the recent "BEAST" ...

34

1 - How feasible is it that the chip's manufacturer can predict the output of this PRNG when it passed tests from the people applying the use of this RdRand instruction in kernels? A strong stream cipher's output is random and unpredictable to anyone not knowing the key. See where this is heading? Just because something looks random doesn't mean it's ...

23

The SSL and TLS protocols (on which HTTPS is based) are designed in a way that no attacker (neither a passive nor an active one) can read anything of the encrypted part (if the cryptographic assumptions hold - and if you don't use the NONE cipher, which does no encryption). Of course, the attacker can read the negotiation part. But this part will not ...

20

In the beginning SSL handshake, the client sends a list of supported ciphersuites (among other things). The server then picks one of the ciphersuites, based on a ranking, and tells the client which one they will be using. This step is the one that determines whether or not the future connection will have perfect forward secrecy. Note that, at this point, ...

15

The reason why you see that is because Camellia is the highest-preference cipher in NSS (Chrome and Firefox). Servers that support Camellia and use the client-preferred cipher suite will use Camellia. NSS's rationale for this ordering is: National ciphers such as Camellia are listed before international ciphers such as AES and RC4 to allow servers ...

14

The recently demonstrated attack against SSL (BEAST) was an IV misuse attack and not really the same thing as what happened to XML Encryption. Non the less, here is what happened with SSL. Basically they found two things: A way to get the browser to encrypt data under the session key used by an existing SSL connection and A mistake in the way SSL was ...

14

I wouldn't assume that the NSA has cracked AES ciphers. I would assume that most crypto systems that use AES have implementation flaws that the NSA exploits when they feel it is worth it. In any case, when the only possible way a state can know something is by breaking a cipher, it's difficult for them to use that information; doing so would reveal that ...

13

Say you encrypt a message with a key $k$. With symmetric encryption (ie. symmetric ciphers), $k$ must be secret. The sender and recipient must agree (somehow) on $k$. No-one else can be allowed to find out $k$. Anyone else who finds out $k$, can decrypt all the messages encrypted with $k$. For that reason, symmetric ciphers are often called "secret key" ...

13

Wikipedia has a decent writeup on the known attacks on RC4. Most of them are from biases of the output. To give you an idea of the severity of the attacks see the following quotes from the Wikipedia page: The best such attack is due to Itsik Mantin and Adi Shamir who showed that the second output byte of the cipher was biased toward zero with probability ...

13

Have you heard of the strange story of Dual_EC_DRBG? A random number generator suggested and endorsed by the government that exhibits some very suspicious properties. http://www.schneier.com/blog/archives/2007/11/the_strange_sto.html From that article: This is how it works: There are a bunch of constants -- fixed numbers -- in the standard used to ...

13

TLS 1.0 uses initialization vector (IV) to refer to two different processes. TLS 1.1 introduces a new type of IV that causes an entire block to be discarded and isn't directly comparable to the old series of IVs based on CBC residue. By simply changing an operation at the beginning of a record, the hope was apparently to make implementations easy to patch ...

12

That's not quite correct. In SSL, two things happen: First, a session key is negotiated using something like the Diffie-Hellman method. That generates a shared session key but never transmits the key between parties. Second, that session key is used in a normal symmetric encryption for the duration of the connection. SSL does use public/private in one ...

12

An interesting thing about some modern standardized ciphers, like AES, is that the government is "eating its own dogfood" by using them internally. (AES 192 and 256 are approved for top-secret data.) Back in the day (up through the 90s), U.S. government internal encryption standards was not closely aligned with public sector cryptography, and we largely had ...

12

There are several effects coming into play. But the most important property is that with increasing keylengths, the attacker's work becomes exponentially expensive, whereas the defenders work only becomes slightly more expensive. Looking at the different kinds of cryptography in use: Symmetric cryptography Originally we used DES and 3DES. DES had a ...

12

By George, you're on to something. To answer the question you asked, I don't know of anyone actually attempting to recover a password this way, or it even being discussed. However, it does appear to be feasible, given enough encrypted streams. How many are enough? Well, I've started running a few simulations; preliminary results indicate that with ...

11

1 - How feasible is it that the chip's manufacturer can predict the output of this PRNG when it passed tests from the people applying the use of this RdRand instruction in kernels? As nightcracker correctly stated, any strong cryptographic PRNG will produce a stream of numbers that pass statistical tests. However, the manufacturer has some constraints: ...

10

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

9

Only two people can communicate with each other with the chat program. No group conversations. This is fairly limited, but let's admit. The people will be communicating over the internet. So, an insecure channel. OK. The chat program will just handle basic characters, numbers and symbols that are on a standard US keyboard. This is to keep ...

9

The server doesn't sign the data itself. It only signs part of the handshake if you're using a signing based suite. That means you can prove to a third party that a handshake with a certain server happened, and what data was exchanged in that handshake. If you're using a RSA encryption suite, it doesn't even sign the handshake, but authenticates indirectly ...

9

I am the designer of the random number generator that is behind the Intel RdRand instruction. How feasible is it that the chip's manufacturer can predict the output of this PRNG when it passed tests from the people applying the use of this RdRand instruction in kernels? It isn't. We cannot. It passes the tests because it is a cryptographically ...

8

You can use TLS 1.0 as guidance: it is the direct successor of SSL 3.0, so many things are quite similar, and in some respects TLS 1.0 is a bit clearer. In section 6.3 you will find the key generation process, with the exact sentence: To generate the key material, compute [...] until enough output has been generated. Then the key_block is ...

8

In TLS (that's the standard name for SSL; TLS 1.2 is like "SSL version 3.3"), client and server ends up with a shared secret (the "master secret", a 48-byte sequence; when using RSA key exchange, the master secret is derived from the "premaster secret" which is the 48-byte string that the client encrypts with the server public key). That shared secret is ...

8

To complete what @CodesInChaos explains: If the server has a RSA key in a certificate which is suitable for encryption, then anybody can forge a completely fake conversation without the server being involved at all. In the SSL/TLS protocol, when using a "RSA" cipher suite, the client generates the random "pre-master secret" which it then encrypts with the ...

8

Annex E.1 of RFC 5246 contains the following text which is a nice summary of the situation: Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will ...

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 TLS the IV for the first packet is generated from the shared secrets; quoting the RFC 2246: To generate the key material, compute key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); until enough ...

7

Well, what SSL uses to negotiate the symmetric keys depends on the ciphersuite that both sides agree upon. By far, the most common method is that the client picks a random value (the premaster secret), and encrypts it with the server's RSA public key. However, it is not that unusual for the ciphersuite to specify that the client and the server agree upon a ...

7

Personally I like the modes that support integrity checking and authentication, e.g. GCM, as they only require one key, and are not vulnerable to changes in the cipher text. One particular important problem area is padding oracle attacks, which are much more common than people seem to admit. Note that GCM/AES is - just like CTR - a block cipher in stream ...

7

CRAM-MD5 is a protocol to demonstrate knowledge of a password. In the context of email, it is sometime used by an email client to authenticate to a POP, IMAP, or/and SMTP server. Basically, the password is used as the key of HMAC-MD5 in a challenge-response protocol. Among positive things there are to say about CRAM-MD5: The password is not exchanged in ...

7

Short answer: Because the browser developers have long thought interoperability to be more important than security and standard compliance. Slightly longer answer: Some SSL/TLS server implementations do not negotiate the protocol version correctly, but terminate the connection with a fatal alert if the client attempts to negotiate a protocol version that ...

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