# Tag Info

12

It actually leaks information. You are sending: Encrypted IV: $AES(k,IV)$ First ciphertext block of CBC: $AES(k, M_1 \oplus IV)$ Eavesdropper can observe whether the two blocks are equal, which happens iff $M_1$ is all zeroes.

8

What makes crypto code vulnerable to timing attacks is data dependent timing variations. Branching according to a round counter, or to the key size, does not create a vulnerability. Most implementations of AES make no branch according to key or data value, and supressing other branches won't help. The main source of data-dependent timing variations in AES ...

3

To randomly guess a single key from a 128-bit key space has a chance of 1 divided by the number of elements or $\frac{1} {2^{128}}$ where $2^{128}$ is the number of keys possible. To get ballpark figures to convert between base 2 exponents and base 10 exponents you can use the following trick: Because $2^{10} = 1024 \approx 10^3$ you can easily count the ...

3

It seems you want to make the IV secret for security purposes, in direct opposition to common knowledge and NIST recommendation that non secret keying material (such as a non-secret initialization vector) be... non secret. So that goes against some of the wisdom espoused a few years ago by Bart Preneel in this video, which says that IVs should be kept ...

3

In asymmetric crypto including RSA, we ALWAYS encrypt with the public key, and decrypt with the private key (NEVER the other way around). In the question, what's wanted is to sign with the private key, not encrypt. And that's enough to solve the whole problem, since RSA signature schemes exposed in BouncyCastle or the Java crypto API allow to sign data of ...

2

This is considered in §6 of Bogdanov et al., who go on to devise an alternative 2-round AES-based Even-Mansour cipher—$\text{AES}^2$. The problem is, essentially, that 1-round Even-Mansour is only secure up to $2^{n/2}$ blockcipher queries, for an $n$-bit block. Specifically, a collision between $\text{SEM}_K(P) \oplus P$ and $E(P) \oplus P$ immediately ...

2

So my question is: it says 10 cycles, but does that mean that the initial round is performed once, the normal rounds 9 times, and the final round also once? Because the expanded key is 176-bytes, so the addroundkey function can be used 176/16 = 11 times. For the 128-bit AES, that is correct. InitialRound, which consists of AddRoundKey is performed ...

2

The original is completely broken and would be regardless of the insecurity of DES. The ECB encryption of a single block message (with a secure cipher) would be a secure MAC, but XORing the message blocks means that an attacker can modify any block of the message simply by making the same change to another block so that they cancel out. The modified ...

2

Theoretically, there is no issue adding some kind of MAC on top of authenticated encryption's builtin. However, in practice there might be subtle flaws with composing the particular primitives you're using, or you may make an implementation flaw that renders them both vulnerable to a side-channel attack that didn't exist previously. Ultimately, it's best to ...

2

As CodesInChaos notes in the comments, having more ciphertext–plaintext pairs doesn't help with brute force guessing attacks. Well, that is, except for the minor issue of unicity. Basically, to narrow the results of your brute force attack down to a single key, you do need to have enough ciphertext–plaintext pairs that the length of the known plaintext ...

2

Your key derivation function is not particularly memory hard. The second loop walks the array in order, so an optimized implementation which an attacker would use can avoid the whole array, keeping only some elements in memory at a time. For example, you can halve the memory use by only storing the second half of M initially. Then for the first N/2 ...

2

AES has a block-size of 128 bits in all its variants. The number in AES-128/192/256 is the key-size. Rijndael, the block-cipher that became AES, also supports 256 bit blocks, but that part was not standardized as AES. Since the block-size is 128 bits, GCM works exactly the same way for AES-256 as it does for AES-128.

1

Unless a fast AES is available on the combination of CPU and PHP instance being used (that is, something built with AES-NI), I strongly advise against using AES as the basis of entropy stretching. Number-1 rule in designing an entropy-stretching function is that it should put to the best possible use the computational resources available to the legitimate ...

1

If the IV is all zeroes, then you basically have ECB for the first block. Basically you're proposing to use this first block's encryption as the IV for the second block. You're implying that the first block will always be unique, but low entropy, which sounds like a counter or time stamp. There are attacks when the IV is predictable, and while this is a ...

1

No. ​ An adversary who knows a ciphertext and one of its plaintext blocks p can trivially find the corresponding xored-plaintext x. ​ Since block ciphers with fixed keys are bijections, if there is a previous plaintext block then x has at least as much entropy as that previous plaintext block. (In particular, x can very easily be different from your other ...

1

Yes, you are in the ballpark with your assumptions. I will store the encryptedKey with the encrypted data, but can I use the same key for all rows or do I need to generate a new one for each one? No you can use the same key. How does the AAD factor into this? Do I need to store it? Does it need to be unique per row? If you don't need ...

1

This sounds like Kerberos. ( https://en.wikipedia.org/wiki/Kerberos_%28protocol%29 ) In any case, you didn't mention, but it would seem quite important, how long are the generated auth tokens valid for, or how would you expire one. There is no such thing (IMHO) as permanent/indefinite authorization--if you believe otherwise, you should not be doing ...

1

No, not as described in the question. Putting aside the block size confusion that Richie Frame mentions in a comment (AES block size is always 128), there is no advantage to encrypting a second half of an IV in GCM mode in particular, and rarely in other modes. In GCM mode the actual IV is used to derive a nonce for CTR mode encryption. By adding a block ...

1

If $f_k$ is AES the block cipher, then there are $2^{128}$ possible output values for a given plaintext and $2^{|k|}$ possible AES keys, where $|k|$ is either 128, 192 or 256, depending on which AES key size you use. Assuming AES chooses a random permutation, $g_{PT}(k) = f_k(PT)$ behaves like a pseudorandom function*, so you expect something like $2^{127}$ ...

1

So if you consider ASCII encoding you have two plain text blocks: "SEND ME THE DATA" and " ENCRYPTED" + padding (which we will ignore). Note the space before "ENCRYPTED". Now if you change the IV you will indeed only change the first block. What you should however do is to change the first block of the ciphertext. That is used as vector (not the ...

1

I assume the recommended approach is to use a KDF function like HKDF, but what is the security implication of taking an SHA-256 hash and using it directly for AES-256 or truncating it for AES-128 (Alice and Bob are using Java which doesn't have a native implementation of HKDF and I don't think it is a good idea to try and write your own). HKDF(-Expand) ...

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