# Tag Info

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

14

CBC does not perform authentication This property makes it less suitable for places where authentication is required, basically any transport protocol. TLS uses CBC, but by default performs authentication over the plain text instead of the ciphertext, which opened up a host of attacks. CBC can be used here, but it is error prone and may require an ...

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

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

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

In complete honesty: if you have to ask this question, it's overwhelmingly unlikely that you have actually succeeded in breaking the security of AES. At best, you may have discovered a well-known attack against misuse of particular block cipher modes; for instance, plaintext recovery with a chosen-ciphertext attack against ECB, or blind manipulation of the ...

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

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

8

It looks like, given your adversary model, things should be secure. HMAC as a randomness extractor has been shown to be good, especially when we can assume the hash function is collision resistant. That paper also has some results which tell how you could guard against the collision resistance being broken (basically use a hash function with larger output ...

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

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

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

7

First, the fact that the data is "easy" to guess (in the sense that an attacker has a one-in-2^32 or a one-in-2^64 chance of guessing correctly) doesn't mean much if the attacker has no way of checking if his guess is correct. Or at least, it's not a problem with the cryptography. Second, even if he does have that ability, the problem of protecting your ...

7

There are several scenarios where you wouldn’t want to use AES in CBC mode. In CBC mode, each block is dependent on a previous one. As @fgrieu nicely hinted at in his comment, using CBC means that if you have a large, encrypted file and you only want to update/change/modify a tiny fraction of it, you would have to follow the decrypt-modify-encrypt path each ...

7

I would like to ask if that is true for every AES CTR mode implementation?, Doesn't have to be. You can store the nonce anywhere. You could even send it to the recipient via a different channel (e.g., email the ciphertext and use SMS to transmit the nonce). Storing it at the beginning has its advantages. For example, if streaming the data, you can ...

6

There is no uniform permutation; there is a permutation uniformly chosen from the set of all possible permutations over $Z_2^{128}$. It is evident that AES is not a uniformly chosen permutation, since its permutation is fixed for any key. One can consider a family $\{AES_K\}$ of AES permutations under all possible keys $K$. Even if the key is chosen ...

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

What is Rijndael's finite field? Rijndaels finite field is $F=\mathrm{GF}(2^8)$ with minimal polynomial $f(x)=x^8 + x^4 + x^3 + x + 1$. Formally, we have $F=\mathbb F_2[x] / (f)$ but don't worry about that. So what does this mean? Well, elements of $F$ should be thought of as polynomials over $\mathbb{F}_2$, with the added fact that the minimal polynomial ...

6

As stated in the comments, dev/random already produces cryptographically secure random bytes which are perfectly adequate for use in encryption keys. Running these bytes through another CSPRNG is completely redundant. As far as I've understood, one of the options to create cryptographically secure keys would be to gather entropy from /dev/urandom/ and ...

6

I don't know of any practical attacks on these schemes that would break collision-resistance or pre-image resistance, but the existence of related-key attacks on AES is still worrisome. The Miyaguchi-Preneel hash construction is better in this sense, because the attacker doesn't directly control anything that goes into the key input. Miyaguchi-Preneel is ...

6

AEAD modes like GCM are authenticated encryption with associated data; this setting only affects the associated data half of that. The ciphertext itself is still authenticated. The associated data portion is there to provide contextual information for the authentication of the ciphertext. Usually this data is something that's outside of direct control of the ...

6

Short answer: There would be nothing (that isn't already wrong with TLS) necessarily wrong with a CTR + HMAC cipher suite, but the technical merits are only one factor in a technical feature getting to RFC status in the TLS working group. Without being discourteous to the TLS Working Group (WG) participants or process, other reasons can be: political ...

6

CBC mode encrypts as follows: $$C_0 = E_K(IV\oplus P_0);\\ C_i = E_K(C_{i-1}\oplus P_i),$$ where $P_i$ are plaintext blocks and $C_i$ are ciphertext blocks. Traditionally, IV must be random and is published alongside the ciphertext to enable decryption. If it is also published in your case, then this reveals the key and is trivially insecure. If the ...

6

From the diagram on CTR mode you can notice that there are no dependencies between any of the phases of the pipeline. If you have more than one block-size worth of data, you can process each block-size chunk completely independently of the others by calculating $\mathrm{ciphertext}_i = E(\mathrm{key}, \mathrm{nonce} \, || \, \mathrm{counter}_i) \oplus ... 6 First, the obvious advice is not to use this in practice. Rolling your own is fine for learning, but you should use standard primitives when you need actual security. E.g. one from SP 800-90A which poncho linked in comments. Now, some observations. I haven't read all your code, so I may misunderstand things. Is this a good way to whiten the data? Is ... 5 Since there are only$16^6 \approx 16.8$million keys, you can try them all and decrypt the message with each. In general you would have to know something about the plaintext to identify which of those decrypted candidates is the correct one. In this case it is known that the message is English ASCII, so the top bit of each plaintext byte will be 0. The ... 5 Absolutely. The key point is that, whilst in CBC mode, the encryption can be thought of as using the previous ciphertext as the IV - have a look at this diagram from wikipedia: I assume from what you've said that you have a function that will "do" AES-CBC decryption on large amounts of data, and you wish to use this. So, you simply run:$\$ D_k^{IV}(c_1\ ...

5

Actually, for CFB mode, the IV is the same size as the block size, 16 bytes. As for your question "does keeping the IV secret help security", the answer is "not really". CFB mode processes the message in blocks, and for each block of plaintext, combines that with the previous block of ciphertext to generate the next block of ciphertext. What the IV is ...

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