Hot answers tagged aes
29
There are a variety of reasons why AES is more widely used:
AES is a standard.
AES has been vetted by cryptanalysts more extensively than Camellia. As a result, we can have greater confidence in the security of AES than in Camellia. Therefore, on the merits, there may be good reasons to choose AES over Camellia.
AES is a government standard (FIPS). ...
26
For practical purposes, 128-bit keys are sufficient to ensure security. The larger key sizes exist mostly to satisfy some US military regulations which call for the existence of several distinct "security levels", regardless of whether breaking the lowest level is already far beyond existing technology.
The larger key sizes imply some CPU overhead (+20% for ...
21
AES is an algorithm which is split into several internal rounds, and each round needs a specific 128-bit subkey (and an extra subkey is needed at the end). In an ideal world, the 11/13/15 subkeys would be generated from a strong, cryptographically secure PRNG, itself seeded with "the" key.
However, this world is not ideal, and the subkeys are generated ...
16
Blum-Blum-Shub is a stream cipher: given a short key, it produces an effectively unlimited-length stream of pseudorandom bits. Other well-known examples of stream ciphers include AES-CTR and RC4.
Blum-Blum-Shub gets mentioned a lot by non-expert cryptographers. I suspect this is because it comes with a "proof" of security, which sounds like a wonderful ...
14
As a bonus feature, AES has hardware support in Intel processors which implement the AES instruction set, with AMD support coming soon in their Bulldozer based processors.
The AES instructions set consists of six instructions.
Four instructions, namely AESENC, AESENCLAST, AESDEC, AESDECLAST, are
provided for data encryption and decryption (the ...
14
Assume that 1 evaluation of {DES, AES} takes 10 operations, and we can perform $10^{15}$ operations per second. Trivially, that means we can evaluate $10^{14}$, or about $2^{46.5}$ {DES, AES} encryptions per second. This is a simplistic view: we are ignoring here the cost of testing whether we found the correct key, and the key schedule cost.
So on our ...
13
A known-plaintext attack (i.e. knowing a pair of corresponding plaintext and ciphertext) always allows a brute-force attack on a cipher:
Simply try all keys, decrypt the ciphertext and see if it matches the plaintext.
This always works for every cipher, and will give you the matching key. (For very short plaintext-ciphertext pairs, you might get multiple ...
11
The actual encryption algorithm is almost the same between all variants of AES. They all take a 128-bit block and apply a sequence of identical "rounds", each of which consists of some linear and non-linear shuffling steps. Between the rounds, a round key is applied (by XOR), also before the first and after the last round.
The differences are:
The longer ...
11
Short version: It is quite likely that a large proportion of the keys have fixed points, but I don't have any idea on how to find them.
Long version: A stochastic argument
There are $2^{128}!$ permuations of 128-bit blocks, and of these, $!2^{128}$ (this is the subfactorial) are fixpoint-free. It is known that
$\lim_{N\to\infty}\frac{!N}{N!} = \frac 1e ...
10
Generally speaking, a lookup-table can be implemented in constant time by doing it as if it was a hardware circuit.
Consider a multiplexer: this is a circuit which accepts three inputs a, b and c, and yields one output d which is equal to a if c = 0, to b otherwise (I am talking about single-bit values here). A multiplexer can be used to implement a 1→1 ...
10
Well, to start off with, IVs have different security properties than keys. With keys (as you are well aware), you need to hide them from anyone in the middle; if someone did learn your keys, then he could read all your traffic.
IVs are not like this; instead, we don't mind if someone in the middle learns what the IV is; as long as he doesn't know the key, ...
10
Blowfish has strong points regarding speed because bulk encryption (and decryption) reduce to an alternation of: a 8->32-bit table lookup, and one or two 32-bit operations (addition or XOR). That structure is very well suited to 32-bit CPUs with a short pipeline and a fast cache of at least 4 kByte; and is well suited for a straight C implementation, which ...
9
If you are doing things right, then you will get the level of randomness you are after. Translation: you are not doing things right. You use AES with CFB8 mode, which requires a random initial value. The initial value is a 16-byte string which should be generated randomly and uniformly, and a new IV shall be generated for every single encrypted message. ...
9
Splitting a key does not reduce the key strength at all. Simply generate two random 128-bit strings and give one to each party. Encrypt the data with the exclusive OR of the two random strings.
Each string alone gives no information whatsoever about the final key, assuming your random number generator is sound. No party has any advantage.
9
Having taken The Design of Rijndael from the library just yesterday, I had a look on this problem, too. Fixee wrote in a comment:
However, my question is not so much about security implications, but rather
"how does omissions of MixColumns make the inverse cipher similar to the cipher?"
and "how does this help in implementing the cipher?"
The ...
9
No. The AES permutation is not distributive over the XOR operation.
If it were true, this would violate the basic security construction of AES in the Chosen Plaintext Attack model (which is a good model we like to use when evaluating the security of a PRP): An adversary $A$ queries a black box with his own plaintext, trying to decide if the black box is ...
9
Not at all secure; generating preimages would be trivial. Here's a demonstration with a three-block message:
Here is your suggested method (limited to three block messages):
$E_0 = Encrypt( IV \oplus P_0 )$
$E_1 = Encrypt( E_0 \oplus P_1 )$
$E_2 = Encrypt( E_1 \oplus P_2 )$
$E_3 = Encrypt( E_2 \oplus 0 )$
$Hash = E_0 \oplus E_1 \oplus E_2 \oplus E_3$
...
9
I'm just curious to know why the 128-bit version become the standard[.]
That question is easy to respond. In the section Minimum Acceptability Requirements of Request for Candidate Algorithm Nominations for the AES, it says:
The candidate algorithm shall be capable of supporting key-block combinations with sizes of 128-128, 192-128, and 256-128 ...
8
The AES standard is reasonably clear, and (theoretically) sufficient to implement the AES itself. For block cipher modes of operation (including counter mode), see NIST Special Publication 800-38A.
8
AES in general does not specify that it should return a bad padding message. In fact, AES in general says nothing about padding. Padding schemes are external to AES. Therefore, the message you are getting is .Net specific.
That said, be careful with these messages, as they can lead to a padding oracle attack.
8
Well, it sounds like you're close.
The multiplications implicit within the MixColumns operation are $GF(2^8)$ multiplication operations, using the same field representation as they use in the inverse within the sbox.
However, because they're multiplying by the fixed constants $\mathtt{1}$, $\mathtt{2}$ and $\mathtt{3}$, it's easier to implement than a ...
8
I can immediately think of four reasons:
They're both not using AES256. I see in the Obj-C document a direct statement that they are using AES256 (unless you deliberately change it), I don't see any statement in the Visual Basic document that says what key size they're using (unless that's what they mean by "Block Bits").
Different keys. AES256 takes a ...
8
For symmetric algorithms (like AES or DES or RC4 -- but not for RSA or ECDSA), a key is a sequence of bits, such that any sequence of bits of the same size is a potential key. So longer keys means more possible keys.
Exhaustive search is about trying all possible keys until a match is found. It is an absolute limit to the strength of an algorithm: ...
8
Because OCB is patented.
And there are other good solutions for authenticated encryption that aren't patented. This makes them more suitable, in most situations. I can recommend, e.g., EAX, GCM, or CWC. EAX and GCM have been used in some standards, and AES-GCM has been standardized.
For pointers where you can learn more, read Wikipedia. And try using ...
7
No, an attack on AES-128 requiring $2^{126.1}$ computations and $2^{88}$ bytes of known plaintext is not a concern. Brute-force guessing of keys (e.g., using the AES-NI instructions you mentioned) will succeed in $2^{127}$ computations on average and requires negligible known plaintext. Part of why key lengths are selected conservatively is precisely to ...
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
Cryptographically speaking, AesManaged uses AES in CBC mode. To ensure this operates securely, you need to choose the IV randomly, i.e. it should not be possible to predict the IV between iterations. This question has a discussion of non-random IVs: Using a Non-Random IV with modes other than CBC and this SO question: Why is using a Non-Random IV with CBC ...
7
Yes, AES could be implemented on a 4-bit micro-controller such as this EM6626, and that would not be rocket science or stupidly slow. This application note illustrates that all kind of 8-bit operations are simple, and table lookups are possible.
In fact, tables are not even indispensable if performance is non-critical; see this minimalist AES source code in ...
7
The final report is here http://csrc.nist.gov/archive/aes/index.html. All five finalists had at least adequate security on all accounts studied during the process, but Rijndael had better performance characteristics in both software and firmware on other hardware than 32 bit processors, compared to the other finalists.
Only top voted, non community-wiki answers of a minimum length are eligible
