# Tag Info

## Hot answers tagged aes

15

The most efficient related-key attacks on AES-256 and resulting weaknesses AES-256-based hash functions are summarized in my PhD thesis. Though collision and preimage attacks on hash functions are out of reach yet, the components of these functions still expose some properties that are not expected of good hash functions or random oracles. Getting to the ...

13

First, I'll assume we're talking about encrypting/decrypting exactly 128 bits of data, i.e. the block size of AES. Otherwise, you'll need to specify a mode of operation — and if your data's length isn't a multiple of the block size, well, that'll be more difficult to deal with. So, I'll assume we're working with a single block. (If you are using a mode ...

12

If you are using an AES library that has not undergone the FIPS validation process, then you are not FIPS compliant (or, at least, your use of AES is not). FIPS compliant means more than "we use algorithms that FIPS likes", it means "having passed the FIPS certification process"; that is how NIST defines it. Sorry, but NIST is quite strict about this; if ...

12

AES has fewer rounds than Serpent so AES should be faster. The number of rounds by itself is meaningless. Some ciphers have a few complex rounds and others have many simple rounds. See my answer to Why does SHA-1 have 80 rounds? for a related explanation. There is no speed decrease with bigger key size in Serpent while there is in AES. The ...

10

AES-256 has sustained 15 years of cryptanalysis, and it can be stated that no knowledge of some plaintext bytes would help to reveal the other bytes no matter what mode of operation (CBC, CTR, etc.) is used. AES-GCM is an authenticated encryption scheme that allows a key holder to detect any modification that has been done to the ciphertext. If you do not ...

10

As the name suggests, CTR mode works by encrypting a counter (that gets incremented with each 16-byte block) to generate a stream of random bits. That bit stream is then XOR'ed with the plaintext to create the ciphertext. The IV provides the initial value for the counter. CTR mode is secure as long as the probability of a counter value repeating is ...

9

When using CTR Mode the AES is used to generate a kind of key stream which itself is the XORed to your plaintext. So AES is actually encrypting an incrementing counter. At the moment there is no known attack, that would yield E(N) if you do know E(N-1), where N is the aforementioned counter. So this should be safe. But be aware, as the plaintext is XORed ...

9

Yes, they can be described as a multivariate polynomial over $GF(2)$ (or over $GF(2^8)$). See algebraic cryptanalysis. This expression does not seem to help cryptanalyze AES, so far as we know, but it can be done. For an example of how to write AES in this way, see the following paper: A simple algebraic representation of Rijndael. Niels Ferguson, ...

9

AES is deemed secure because: Its building blocks and design principles are fully specified. It was selected as part of an open competition. It has sustained 15 years of attempted cryptanalysis from many smart people, in a high-exposure situation, and it came out relatively unscathed. Another reason, which is not as good but felt important by many ...

9

DES actually demonstrated that a Feistel structure was not a guarantee against attacks. In "academic" terms, DES is broken by both differential and linear cryptanalysis, because they require, respectively, $2^{47}$ chosen plaintexts and $2^{43}$ known plaintexts, whereas the DES key is (effectively) 56 bits. Of course, for practical attacks, we would brute ...

9

At the time of the competition (I can talk about it, I was there), there was a lot of discussion and various people showed arguments. However, there was never an official, publicly known "board of scores" with totals and definite rules, as the pictures you show seem to purport. It is possible that the NIST people did make something similar internally, but ...

9

First, your use of 'echo' gets you: ~ % echo 'Attack at dawn!!' | hexdump -C 00000000 41 74 74 61 63 6b 20 61 74 20 64 61 77 6e 21 21 |Attack at dawn!!| 00000010 0a |.| 00000011 Note that there are 17 bytes there, not 16. echo adds a newline character. To stop that, use the -n flag: ~ % echo -n 'Attack ...

8

Security issues related to block size boil down to the following: a pseudorandom permutation is not a pseudorandom function, and the difference becomes visible when you query the function too many times. Imagine a function which accepts as inputs, and offers as outputs, elements from a set of size $N$. For instance, the inputs and outputs are blocks of $n$ ...

8

If an attacker find some round key of AES256. Is it possible to find the master key ? If the attacker is given a single round key from an 256 bit AES key, it is infeasible to reconstruct the full key (even if you have access to chosen plaintext/ciphertext against the full key). This single round key reduces the number of possible AES keys from ...

7

The GCM authentication tag doesn't need to be encrypted. Just attach it to the ciphertext in the clear. A very quick intuitive justification: It's an authentication tag derived from the ciphertext, it doesn't contain any sensitive information itself. The security of the GCM model assumes the tag is left in the open. (The GCM spec, SP 800-38D, shows the ...

7

Is the calculated MAC encrypted using AES? What is the purpose? How about signing and verifying? How does AEs Play a role here? Is the case here that the encrypted AES is HMACed for signing and the HMAC is verified No, the MAC is not encrypted per se, however, it is calculated in conjunction with a key (independent of the encryption key). Simply ...

7

Let's clear some bullshit first: Now as the NSA GCHQ et al know very well the more efficient you make the implementaiton of crypto code the more side channels it has unless extream caution is observed. One thing we do know is that optomised for speed and minimized number of gates is an almost certain guarentee of side channels no matter how clever you ...

7

Rather risk vulnerabilities of third party library than implement your own. If you feel novice on this field, only implement cryptography yourself as an learning exercise. Why: Mistakes, lack of know-how and maintenance. It is very easy to make novice mistakes in custom implementation of cryptography. Even battle scarred veterans of the field do mistakes ...

7

It is possible to turn a hash function into a stream cipher; there are several methods for that, and the simplest is to compute $h(K||IV||x)$ for hash function $h$, initialization vector $IV$, and successive values of a counter $x$. This yields an arbitrarily long sequence of pseudo-random blocks (32 bytes per invocation if $h$ is SHA-256). Then XOR that ...

7

All of your encryption rounds are incorrect, either due to incorrect round function or key schedule (or state alignment). Showing round 0 (round key addition before first round) will help show if the keys are being added correctly to the state. The key expansion is also very important, if that is not done correctly it will not work at all. I will assume ...

6

Well, it turns out that depends on what you mean by "the AES cipher". If you are talking about the block cipher primitive, that is, if you define an alternate block cipher by taking AES, and swapping the 'encrypt' and 'decrypt' directions, well, that alternative block cipher is precisely as strong as AES. It can be used in any mode of operation we would ...

6

Could the attacker figure out the AES key if the IV used to encrypt all the strings is the same? No; the AES key is secure against such an attack. Could the attacker figure out the AES key if the IV used to encrypt all the strings is NOT the same (one IV per string), but known? No, the AES key is secure against such an attack. You say that you ...

6

There is nothing related to passwords in AES. AES uses 128-bit keys, i.e. sequences of 128 bits. How you come up with such a key is out of scope of AES. In some contexts, you want to generate these 128 bits in a deterministic way from a password (and possibly some publicly known contextual data, like a "salt"); this is a job for password hashing. In other ...

6

In a scenario such as yours, where there is only one password/passphrase, but it is used as key material for the encryption of multiple CBC encrypted files, you will (as you noted yourself) obviously not make it any harder for an attacker to compute your password, should you use a salt. However, using a salt would mean that the encryption of each file is ...

6

Well, AES is not a Feistel cipher because it's a substitution-permutation network instead. If I were taking a test that asked me why AES was not a Feistel cipher, this would be my argument: namely, that the structure of substitution-permutation networks is fundamentally different from that of Feistel networks. (Here one could elaborate on invertibility and ...

6

The question has several aspects: it asked (initially) about any security issue in breaking a piece of data into separately RSA-encrypted chunks; it asks what's the weak link in the security chain when doing hybrid encryption with a 256-bit AES key transfered enciphered using 2048-bit RSA; it asks how much slower 2048-bit RSA would be for bulk encryption, ...

6

The affine transformation works similar to MixColumns, but operates on an array of 8 bits instead of 4 bytes. Confusion in various descriptions of the affine transform in AES comes from where the LSB of the input byte is located. Some show it at the top of the column, others show it at the bottom. I will be using the version shown in the Rijndael paper, with ...

6

The attack which you link to, on ECDSA, is related to the following: the signer computes several values $kG$, for random $k$ values chosen uniformly modulo $n$ ($n$ is the size of the subgroup generated by $G$). One such value is generated for each signature. It is important that the selection is uniform: even small biases can be exploited in order to make a ...

6

You should think of Rijndael's S-box as a function that maps bytes to bytes, where a byte (octet) is considered to be a member of a finite field of size $2^8$ (with xor as addition). It's not seen as a 16x16 octet array, really. The substitution is then just done byte-wise: every octet in the 4x4 block is replaced by its function value under the S-box ...

6

AES does not operate on or produce characters — it has no knowledge or care of any particular character encoding. AES and other modern block ciphers accept and output arrays of bytes. The same concept applies to the key, and (in block modes that require one), the initialization vector. How (and if) you choose to encode the output is up to you. For storing ...

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