# Tag Info

247

I dug out my copy of Applied Cryptography to answer this concerning symmetric crypto, 256 is plenty and probably will be for a long long time. Schneier explains; Longer key lengths are better, but only up to a point. AES will have 128-bit, 192-bit, and 256-bit key lengths. This is far longer than needed for the foreseeable future. In fact, we cannot even ...

60

For one AES is built for three key sizes 128, 192 or 256 bits. Currently, brute-forcing 128 bits is not even close to feasible. Hypothetically, if an AES Key had 129 bits, it would take twice as long to brute-force a 129 bit key than a 128 bit key. This means larger keys of 192 bits and 256 bits would take much much much longer to attack. It would take so ...

49

The reason why RSA keys are so small is that: With every doubling of the RSA key length, decryption is 6-7 times times slower. So this is just another of the security-convenience tradeoffs. Here's a graph: Source: http://www.javamex.com/tutorials/cryptography/rsa_key_length.shtml

18

First things first: don't panic. Don't do anything rash, and take time to think. The slides which have appeared today describe new results on bias in RC4. RC4 generates a key-dependent stream of pseudo-random bytes, which is then XORed with the data to encrypt (decryption is identical). It was known that the output of RC4 was slightly biased, i.e. some byte ...

12

This could be encrypted with any key length that is equal or longer than 28 characters (sum of lengths of ciphertext you provided) and as such unsolvable. The character variation between the plaintext CANDY VERY CRANBERRYhttphttp and its ciphertext TXOtWjYhVk 8&O\$4AmSAcZf.r5Hz is: ...

11

The "arcfour" cipher is defined in RFC 4253; it is plain RC4 with a 128-bit key. "arcfour128" and "arcfour256" are defined in RFC 4345. They use a key of 128-bit or 256-bit, respectively. Moreover, and contrary to plain "arcfour", they also include a "discard" step: the very first 1536 bytes produced by the cipher are dropped. This is done because the first ...

8

GCM is recommended; it is even approved by NIST. However, AEAD ciphers are supported in TLS only since TLS 1.2; see section 6.2.3.3, which is new, when compared to TLS 1.1. The actual GCM-able cipher suites are defined in RFC 5288. Note that TLS 1.2 (and, for that matter, TLS 1.1 too) is immune to BEAST-like attacks when using CBC. Therefore you will have a ...

8

Processing time, pure and simple. Everything in security is a balancing act between the need for security (keeping the bad people out), and useability (letting the good people in). Encryption is a processing expensive operation even with dedicated hardware for doing the calculations. It simply isn't worth going beyond a certain level of security for ...

7

Differential cryptanalysis is a kind of attack which exploits some fine details in the structure of the attacked cipher; you look at pairs of plaintexts, encrypted with the same key, and the corresponding ciphertexts. The pairs must be carefully chosen so that the difference between the two plaintexts (usually, bitwise difference, i.e. a XOR) exercises with ...

6

In a way, algorithms using such "insanely large" keys already exist. It's called one-time pads. Nobody really uses them in practice, though, since they require a key the length of the message you wish to encrypt and key material can never be reused (unless you want the ciphertext to become trivially breakable). Given that the purpose of encryption is to ...

6

If the two encrypted messages are using the same stream cipher and the same key, C1 xor C2 results in M1 xor M2 where C1 and C2 are the respective ciphertext and M1 and M2 are the corresponding plaintext. You can then recover the plaintext using a technique known as crib dragging. You take a common word or phrase that may appear in the plaintext (such as " ...

6

The list of cipher suites for SSL/TLS is, by definition, open-ended, so you can never be sure that you got "all of them", especially since there are ranges of values "for private usage". However, there is a registry for standard cipher suites, maintained by the IANA, there. It references all cipher suites which are defined in one RFC or another.

5

Though the details are not published yet, the currently known information points at the following: some sensitive operations are protected with some encryption and a MAC, both relying on carrier-specific choices of algorithms and key lengths. However, some carriers apparently rely on DES whose key size is relatively small (56 bits), making key recovery in ...

5

There is one mcrypt which is a command-line utility and library for file encryption; and another mcrypt which is completely unrelated, and appears to be a direct rip-off of TrueCrypt, which is an implementation of an encrypted filesystem (and that rip-off might be illegal and/or malicious as well). GnuPG is an implementation of the OpenPGP standard, which ...

5

The client suggests but the server chooses. The client sends a list of the cipher suites that it supports (and is willing to use). This list is supposed to be ordered by preference. The server responds by choosing one cipher suite in this list. Well-behaved servers try to follow the preferences of clients, but that's not really mandatory. Ultimately, the ...

5

Strictly speaking, the server can send an arbitrary number of certificates to the client, as part of its Certificate message. However, as the standard says: The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Therefore, a really compliant server cannot send a ...

4

Processing time was already mentioned. Even in that respect the time required to generate an RSA key should be mentioned separately, since it is MUCH more costly for longer keys, since you need to find prime numbers of roughly half the size of the desired RSA key. Another topic is space, i. e. the amount of data generated. Asymmetric and symmetric ciphers ...

4

Adding more evidence to the "because it slows things down unnecessarily" answers, it seems like AES execution time doesn't grow as fast as RSA when key length goes up (and RC6 grows even more slowly), but it's still a 16% execution time increase to double key length, according to http://www.ibimapublishing.com/journals/CIBIMA/volume8/v8n8.html .

4

Use any authenticated encryption mode. That could be a stream cipher with built-in support for authentication (not what I would recommend; all of the candidates are still bleeding-edge), any standard authenticated encryption mode (e.g., GCM, EAX, etc.); or use encrypt-then-MAC with AES-CTR and a suitable MAC (e.g., AES-CMAC or SHA256-HMAC). Any of those ...

4

Most of the problems outlined by Mr Snowden are essentially side-channel attacks. The algorithms aren't suddenly less robust but rather the software and infrastructure that uses these algorithms. Root CAs for example have always been open to the nation they reside in, the protection they provide is against other normal civilians, not government agencies. ...

4

Security: if you don't do stupid things like using a 512-bit RSA key, these cipher suites are all equally secure: they are all very far in the "cannot break it" zone. So that's a meh. You cannot say that one is more secure than any other. With an exception though: the "ECDHE" suites use an ephemeral key pair for actual encryption; since the corresponding ...

4

In a cipher suite like "TLS_DHE_RSA_WITH_AES_256_CBC_MD5" RSA is used for authentication, while AES (256 bit) in CBC mode is used for encryption. Authentication is needed since Diffie-Hellman is vulnerable to Man-in-the-Middle attacks. An attacker could easily exchange the Diffie-Hellmann paramater and would therefore be able to intercept the communication ...

3

It depends on the version of your SIM card, but normally if it's not older than 10 years (this is about the time when all SIM cards were starting to use 3DES instead) you should be alright. This depends unfortunately entirely on your carrier and there is no easy way to found out. You can check this yourself according to the very extended article on ...

3

Short answer: yes, things will be fine. RC4, MD5 and, in some minor measure, SHA-1 all have some known shortcomings, but none of them will make your Web site weak. To be accurate: if using a RC4-MD5 cipher suite makes your Web site significantly weaker, then it is otherwise extremely solid -- more solid than seems to be practically reachable, indeed. ...

3

This is known as OTP key reuse attack; you can find the answer ("cribtext drag") in here. The more messages you have (the more the key has been reused), the better. With a large enough corpus you may not even need cribtext dragging at all. That is, you take a guess of a common phrase that may appear in one of the plaintexts (the classical example ...

3

If I understood your question correctly, you're trying to generate an AES key using AES and the user password as a key, then use that key to encrypt an RSA key. Granted, AES will give you a very indistinguishable ciphertext that you can use as an encryption key if you wanted. But AES isn't really a password-based key derivation function, mainly because it's ...

3

A PRNG which lacks reseeding, prediction resistance, or whatever these people mean by "continuous testing", is not a PRNG. Not in cryptographic terms. Conversely, a good PRNG, like HMAC_DRBG, will be as good as Dual_EC_DRBG, actually better since Dual_EC_DRBG exhibits measurable biases, and is awfully slow. The only good point of Dual_EC_DRBG is the ...

3

For the ciphers, use DHE-RSA-AES256-SHA. If you use openssl ciphers -v you can get more information about each cipher: \$ openssl ciphers -v DHE-RSA-AES256-SHA DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 \$ openssl ciphers -v AES256-SHA AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 From this you can ...

2

A possible fix is to totally disable all non-RC4 cipher suites. This will break connections from clients who have elected not to use RC4 (possibly, these would be quite rare), but at least it will guarantee that if a connection is made at all, then it will use RC4, which is immune to BEAST. In true SSL/TLS, the server is supposed to follow the client's ...

2

For the keys, they should be as random as you can get them, so either use a true random number generator (unlikely) or a cryptographically secure pseudo-random number generator. The plain text can be just random from any generator, however don't you want the plain text to more accurately mirror real data where certain bit strings may be more common?

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