Hot answers tagged

19

AES is a block cipher and is supposed to be a pseudorandom permutation. It can achieve IND-CPA or IND-CCA or authenticated encryption using AES, by using the appropriate mode of operation together with AES. Let see what can be achieved or not. Has AES been fully (10-rounds) broken? by what means? (commercial? supercomputer?) Direct brute-forcing The ...


16

No, AES-128 has not been broken by any means in any practical sense.


10

HMAC-based Key Derivation Function (HKDF) rfc5869 is what you are looking for. HMAC security proof uses the fact that the compression function of the underlying hash is itself a PRF. HKDF follows the "extract-then-expand" paradigm, where the KDF logically consists of two modules. The first stage takes the input keying material and "extracts" ...


5

This scheme suffers from a classic problem of textbook RSA which is mitigated e.g. by RSA-KEM (as outlined by kelalaka) or RSA-OAEP. When you compute $k^3\bmod N$, you'll experience that $$c=k^3\stackrel{k< 2^{256}}{\leq}\left(2^{256}\right)^3=2^{768}\ll 2^{2000}<N$$ Now remember how $x\bmod N$ works: If $x\geq N$, then you recursively compute and ...


4

What you describe is a little away from the RSA-KEM (KEM : Key Encapsulation Mechanism). As pointed out by SEjPM, in the comments, an AES-128 key when encrypted with the public modulus has almost 768 bits and this can be recovered by the cube-root attack. Here is the RSA-KEM; RSA-KEM mitigates the attack that you have. RSA-KEM for a single recipient with ...


4

First of all, CTR mode is an archaic mode of operation that only provides you confidentiality. In modern standards, we use Authenticated Encryption (AE) modes like AES-GCM or ChaCha20-Poly1305. AE provides you confidentiality, Integrity, and authentication in a bundle. There is no need to encrypt the IV. They are never designed to be encrypted. They provide ...


4

Under a fixed key, $E_K$ is a permutation in the symmetric group of permutations on $2^{128}$ elements. Thus its order divides $(2^{128})!$. If AES is modelled as a random permutation, for a randomly chosen fixed key, the order $N$ of $E_K$ is likely to be near $2^{127}$ as explained in the comment under the question, and indeed $E_K^{N-1}(x)=E_K^{-1}(x)$ ...


4

Modern block ciphers encrypt a fixed-size chunk of plaintext as a same-sized chunk of ciphertext. Since the blocks are the same size and any byte sequence is a valid input, it's clear that every possible output sequence will be hit. Since encrypting and decrypting are inverse operations, it's easy to find an input that encrypts to any particular output - ...


3

You can indeed avoid having an explicit IV for each chunk in favor of an implicit one, and using the previous encryption's last ciphertext block is indeed one way. But: You almost certainly need authenticated encryption that provides not just confidentiality but also message authenticity. Read up on the EFail attack, one of whose causes is CBC-based ...


3

meet-in-the-middle attacks rely on storing the results in a map Only the naive version of MitM does. The impractical memory requirement (size and accesses) of naive MitM can be greatly lowered with a relatively modest increase in other computation costs, and the calculation distributed to independent devices. The reference paper is Paul C. van Oorschot and ...


3

With AES CTR mode, using the same key and nonce to encrypt multiple blocks of data is a huge security breach: Ciphertext1 = Plaintext1 XOR Key Ciphertext2 = Plaintext2 XOR Key XORing the ciphertexts: Ciphertext1 XOR Ciphertext2 = Plaintext1 XOR Key XOR Plaintext2 XOR Key This simplifies to Plaintext1 XOR Plaintext2 This means that if you knew that the ...


3

The aspects regarding IV has already addressed @Maarten - reinstate Monica. There are some more issues. 1) If you store encrypted data in cookies once for all future requests, then it will not work, because many users clean cookies and local storage regularly. Some do that manually, some use add-ons that clean up cookies and local storage on browser exit or ...


3

I think Lenstra's short document Rijndael for Algebraists is fantastic to get started on the maths behind AES: https://math.berkeley.edu/~hwl/papers/rijndael0.pdf You can find some information on finite fields on Wikipedia have a look at the example of $GF(4)$. For a detailed overview of the cipher see the book The Design of Rijndael:The AES Standard by ...


3

if any key has NULL bytes (or zeros) at the end, how the unwrap knows how many padded bytes are added? PKCS#11 doesn't unpad unless you indicate PKCS#7 padding using _PAD. Decryption will just leave all the zero bytes. This is not a problem if you either know the size in advance, or if you've padded it yourself using a scheme that is compatible with the ...


3

When it's possible, a solution is to ensure that table lookups at data-dependent addresses are constant-time and without action on the cache, by Disabling cache (use and loading/invalidation) during such table lookups. That's heavily system dependent, though. Some CPU architecture have special instructions, addressing modes, or mode bits allowing this, or ...


2

AES-CTR uses a nonce - a number used once - rather than an IV for creating the initial counter value. This nonce is actually just an octet stream / byte array rather than a number; you could think of it as an encoded unsigned number. So in principle, CTR mode doesn't require an IV. However, as there are many ways of creating the initial counter value, most ...


2

No, likely this won't work. Almost all HSM's will only accept wrapping keys of a type that is compatible with the encryption / wrapping algorithm. Commonly it is impossible to get to the value of the key as well, so that won't save you. Sometimes you can wrap a key to export it and then re-import it again. Then you might be able to create a new AES key from ...


2

Such quantom attacks are entirely theoretical, we are nowhere near having quantom computers brute force passwords. It is thus difficult to compare. Argon2 might be harder to implement on quantom computers but also the others are so far from being practical it seems pointless to try and compare how these would fair against a mythical adversary. In general ...


2

For this kind of problem, the cryptographic algorithm/protocol designers, usually, presents test vectors for their designs. You can find some of them in books, too. In your case, AES is standardized by NIST on May 26, 2002, and they provide test vectors in Appendix F of NIST 800-38A for various mode of encryption. Before the standardization on November 26, ...


1

This appears to be a one time pad cipher, turned into a multi time pad cipher, as the key remains the same for every different plaintext that is entered. This is a broken construction then - look at the "Use and Security" tab of your wiki link. If AES for example is used, say CTR mode, using a counter, then it is secure, as long as the counter never repeats ...


1

On AES per packet: Generally it depends, but if you write there so few details, then I would bet you would implement it insecurely (no offense). There are several reasons: You need to use a specific mode of operation, but you don't mention any. The mode of operation can have substantial impact on security. You don't mention initialization vectors / nonces. ...


1

First of all AES!=Rijndael. I'm assuming that 256 is the key size. Yes, the IV in CBC mode must not be reused, actually, it is more than that, the IV must be unpredictable. Let remember how the encryption in CBC mode is performed; \begin{align} C_1 &= Enc_k(P_1 \oplus IV)\\ C_i &= Enc_k(P_i \oplus C_{i-1}),\;\; 1 < i \leq nb, \end{align} where $...


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