Tag Info

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

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

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

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

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

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

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

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

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

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

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

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

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 .

The OP asked: "So in other words what is the consequences of choosing a cipher key that is too large...?" A 256-bit key is plenty strong, as proven by the comments here; however, a very secure key (which is a good thing) will simply cause a malicious person(s) to find a weakness elsewhere in the system.

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

CBC is just one of the modes of operation that can be applied to a general block cipher, i.e. it is not tied specifically to AES. For die diverse modes of operation for block encryption see: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

You do not "decrypt the private key", you "use the private key for decryption". ECDH is not an asymmetric encryption algorithm but a key exchange algorithm. Key exchange algorithms are like asymmetric encryption algorithms in which you do not get to choose the message which is encrypted -- but that's just as fine when you just want to establish a shared ...

If your original construction gives you the security properties you want, then simply replacing Alice_PU[KS] with Bob_PU[KS] should do the job. Think of the database as a communication channel to your future self. Future Bob should still have his keypair, so can both decrypt the session key and verify the signature.

The default algorithms (that is, the algorithms which the client and server prefer to use when given the choice) depend on the client and server implementations, how they were compiled and configured. So it may depend on the software vendor, software version, operating system distribution, and sysadmin choices. On an Ubuntu 12.10, man ssh_config indicates ...

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?