Tag Info

Hot answers tagged

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


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


11

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


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

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

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


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

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

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


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

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


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

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

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



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