Tag Info

Hot answers tagged

32

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


18

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


10

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

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


6

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

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

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


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

You can make OpenSSL print out the handshake messages with the -msg parameter: openssl s_client -msg -connect myserver.net:443 Then look for the ServerKeyExchange message. Here is an example: <<< TLS 1.2 Handshake [length 014d], ServerKeyExchange 0c 00 01 49 03 00 17 41 04 6b d8 6e 14 1c 9b 12 4d 58 29 20 e8 e2 1a 24 0d da 8f 38 1a 5d 85 ...


5

I don't think NSA can break the underlying encryption primitives. What they may do is record the whole SSL traffic and decrypt the whole traffic using server private key. So you can use introduce perfect forward security as the blog article “SSL/TLS & Perfect Forward Secrecy” suggests. In addition man in the middle can be performed with fake ...


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


4

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


4

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


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

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

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


4

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


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


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


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

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

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

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

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


3

Good brief topic on security of this protocol for each version can surprisingly easy be found in Wikipedia. Also, please take a look on blog posts about SSL-stripping attack, also BEAST and SSL Recognition Attacks.



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