New answers tagged

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


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


0

How to unwrap an AES(-128) key as DES2 key? Any good PKCS#11 device should make that impossible, and instead produce an error like CKR_WRAPPED_KEY_INVALID. There should be no possible resolution. If such change of key algorithm was possible, it would be a blow to security: it would allow obtaining some plaintext/ciphertext pairs under both the DES2 (3DES ...


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

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


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


0

The system is either insecure or horribly insecure. When using Xor, an attacker with two ciphertexts can xor them, eliminating the key and getting the Xor of two plaintexts. You said plaintexts are all distinct and 256 bits, if they are chosen uniformly at random, getting the XOR of two of them is obviously not desireable but doesn't immidiately reveal the ...


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


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


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


0

The AES algorithm is not broken. With a single or a few fault injections during encryption, it is easy to recover the key in a matter of seconds/minutes/hours depending of the position of the faults and your computation material. So in that sense it is broken, but the AES algorithm is not broken in its practical use.


16

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


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


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

Actually i solved this in a completely different way incase anyone is wondering. Instead of trying to split the bytes into a splittable list there was a more strict way to solve this by following a pattern. When encypting, each chunk would be a multiple of 16, and minus 1. So if you wanted each chunk to be 16 bytes then we would make each chunk 16-1=15bytes, ...


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


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


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


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


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


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


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


Top 50 recent answers are included