# Tag Info

30

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

12

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

12

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

12

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

9

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

7

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

6

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

5

BEAST is not affected at all if the keys are derived with Perfect Forward Secrecy. If you were to derive fresh keys quite frequently (that is, issue a Change Cipher Suite every couple of TCP segments), that would frustrate BEAST, however it wouldn't matter if the new ciphersuite used PFS or not. In addition, there are cheaper ways to foil BEAST. What PFS ...

5

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

4

If all the components share the same certificate, then they share the same private key. This raises the two following points: When a secret is shared by more than two people, can it still be considered really secret ? Secrecy dilutes fairly fast. If all components share the same secret value, then breakage of any single component reveals the private keys ...

4

If the NSA has chosen the elliptic curve parameters (the "constants") in a way that makes the elliptic curve cryptographically weak, then cryptography using that curve might be, well, insecure and breakable by the NSA. For instance, it is known that there exist various classes of elliptic curves where the discrete log problem is easy (or not very hard). If ...

4

There are several ways to answer your question: You cannot "replace" RC4 in SSL. SSL is a standard protocol in which any algorithm may be used only if both client and server support it and agree to use it. Thus, in practice, you do not get to replace algorithms as you wish, unless you control both client and server code; and even then, it would not longer ...

4

The cornerstone of the handshake security is that the Finished messages, sent under the protection of the newly exchanged key (for encryption and MAC), contain hash values computed over all the handshake messages exchanged so far, including the list of cipher suites and all other parameters. As long as client and server don't negotiate the use of a cipher ...

4

If you use public key crypto in the correct way, then every user has it's own private key and corresponding public key (included in the certificate) and the keys of users are not related. Consequently, compromising the private key of one user does not affect any of the other users. So in the case of compromise of the private key of one user the remaining ...

4

To answer this question, we must have a look at how TLS/SSL works. I guess you know that the aim of TLS/SSL is to authenticate communicating parties before setting up an encrypted connection through which application data will flow. And as you may already know, an SSL handshake/session will use asymmetric crypto for authentication and session setup and ...

3

An implementation should generate the IV from any cryptographically secure PRNG. TLS 1.1 further details the possible ways to do that: The IV can be obtained from a PRNG. A random string $r$ can be generated from a PRNG, and added to the plaintext to encrypt where the IV should go; then the whole lot is encrypted with either a fixed IV, or even the last ...

3

One of the design goals of SRP is that it should be a zero-knowledge authentication protocol. This is to say, even the legitimate server should not be able to learn anything about the user's password (other than what it could learn using a generic brute force attack on the verifier). SRP also assumes that the user may not be able to remember anything ...

3

Yes, there are a number of TLS cipher suites that don't include any encryption. These cipher suites are not normally used by OpenSSL, but they can be explicitly requested e.g. using the -cipher option to the OpenSSL tools. Specifically, the suites offering no encryption and/or authetication are found under the NULL and aNULL cipher classes. The openssl ...

3

Here is a good guide for deploying forward secrecy on your SSL server. Here's another good guide that describes how to deploy forward secrecy for Apache, Nginx, and OpenSSL. To answer your specific questions: As far as I know, you should be able to use any CA. The choice of forward secrecy doesn't come from the certificate; it comes from the list of ...

3

I do think that in the fullness of time the choice to forcibly migrate people to RC4 will be considered a folly. We recently had a PCI auditor command that we use RC4 to avoid the BEAST attack. We had no option but to comply or face losing our PCI certification. Across the industry, people are fleeing from AES-CBC in response to this attack. Yet in my ...

3

The answer from owlstead and its comments covers WEP part quite nicely. This answer concentrates on CTR and OFB. Strictly speaking, CBC, CFB, CTR, and OFB modes always use IV or counter. I'm assuming that the question was more like is it possible to use CTR or OFB mode securely without transmitting IV. I.e. for instance, start at all zeroes IV/counter and ...

3

A fault injection attack is based on the fact that you have a healthy black box on which you can do queries, but you can mess with the black box, for example flipping random bits. In real life this could for example be a RFID chip which can be messed with using strong electronic fields. Attacks like these are generally: Very sophisticated in theory and ...

3

There are two papers on conventional differential cryptanalysis of SEED. The last one penetrates only half of the cipher. Even though there are few third-party cryptanalysis papers, there is no indication that the cipher is weak. Fault attacks are quite irrelevant in the SSL setting. I would be more concerned with BEAST-like attacks, as SEED is a ...

3

In a purist cryptographic sense, there are many vulnerabilities in this cipher suite that can be (theoretically and practically) exploited. There are much stronger versions of SSL/TLS, and much stronger cipher suites that could be used. In a practical sense, it's not the end of the world - there are far worse cipher suites (e.g. those using intentionally ...

2

To answer your specific questions: From reading around I understand that ... encrypting a counter and use that as the IV is OK, is that true? For CBC mode, that is absolutely true, as long as the key that you use to encrypt the counter is secret (that is, not known to any possible adversary). Should I start in random number? Actually, that's ...

2

You want "a simple chat program that has encryption that is impossible to crack for anyone". This is not a cryptography problem; it is an information security problem. It cannot be solved by cryptography alone. Cryptography might be one tool, but cryptography alone cannot solve this problem. You cannot solve this problem through mere cryptography. ...

2

Well, that would work, but identification is not enough for SSL. You would need to make the PKE scheme one-way against CCA1 attacks. $\:$ (On the other hand, it wouldn't need any semantic security.) $\:$ Sending back H(S') would change the required security notion to one that's even farther from what's been studied. You could use a tag-based PKE scheme ...

2

Got news: http://en.wikipedia.org/wiki/Transport_Layer_Security#RC4_attack It's not very practical yet (at least 224 ciphertexts), but attacks can only get better, not worse. Remember how it was with WEP cracking.

2

This depends on your intended use. If the hardware environment supports processor instructions for AES, that would be the preferred choice, as it will have higher performance and less side channel leakage. If you do not have these instructions, then from a technical standpoint each should have equivalent levels of security with a given bit size. Ciphersuite ...

2

From a technical side, there are three general scenarios that should be handled differently: Scenario 1: You control the configuration of the server your client software will connect to, and expect to retain that control for the life time of your client software. In such case, you only have to (and probably should) enable a single cipher suite, both client ...

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