# Tag Info

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\ ... 1 AES-128 uses the full set \{0, 1\}^{128} as keyspace, and for each key the blockcipher is defined for each input block in \{0, 1\}^{128}. The same goes for AES-256, but it uses a 256-bit keyspace (but still a 128-bit block). So the answer to 1 is yes. For 2, we have this equation:$$AES_K(AES_K^{-1}(x)) = x We can decrypt both sides: ...

0

If anyone needs it, C# code to calculate the KCV (you need only the first three bytes of the GetKcv return value): class Aes { private readonly byte[] _iv; private readonly int _secretLength; private readonly byte[] _secret; private readonly RijndaelManaged _cryptoEngine; public Aes() { _iv = new byte[] { 0, 0, 0, 0, 0, 0, ...

1

$V_{1}$ and $V_{2}$ should never be equal when using correct implementation of cbc by using the same input $(a,b,c)$. See following construction scheme: Even though you have two distinct encryption processes, namely one for $V_{1}$and another for $V_{2}$, the correct implementation of CBC uses an initialization Vector IV which has to be random. By xoring ...

1

For AES-128, the block cipher works on 128 bits at a time. Whichever block cipher mode you use (ECB, CBC, CTR, etc.), the encrypting will always be done on 128-bit blocks. The assumption is also made that padding is being used. Let's assume that $m = (a||b||c)$ and that $m' = (c||a||b)$. That gives us two separate messages, each 900 bits. Using ...

1

I'm going to assume that the comma $,$ operator used in your question means 'concatenate' (normally written $a||b||c$). Moreover, I'm assuming that $a,b,c$ are distinct. In that case, With incredibly high probability, No: $V_1$ and $V_2$ will not be equal. Think of it this way: if they were equal, then what would $D_k(V_1)$ be? Supposing $V_1=V_2$, we ...

1

To calculate the KCV for AES, you take the first three bytes of the encryption of zero under your key. Indeed, the case you've given is precisely this - the zero vector encrypted under the key 48C3B4286FF421A4A328E68AD9E542A4 is 77dc841daeb43315fed9acdf2f965f45, which restricts to 77dc84. In your question you say you already have AES-128 encryption, at ...

1

You do not mention any authentication of the ciphertexts. $\:$ If you could change the IV (which sounds highly unlikely) then you could make rather precise changes to the plaintext (as if it was a stream cipher). Ideally from your point of view, there may be a padding oracle attack (which I don't understand and so won't describe here). If you can change ...

2

If the last 16 bytes of the ciphertext are the padding, then you actually have the simple ECB (Electronic CodeBook) mode. ECB is secure as long as all your plaintexts are 1 block long and never repeat.

4

Well, there is no really good way; the encryption of the plaintext is $E_k( Plaintext \oplus IV)$ (followed by 16 bytes which are a deterministic function of the first ciphertext block). The AES function $E_k$ is designed to be totally unpredictable if you don't know the key, there's nothing to leverage there. The only thing that allows you to gain any ...

0

Conversion and Proxy Functions for Symmetric Key Ciphers By Cook and Keromytis has conversion techniques that seems to be practical for achieving PRE .

2

Decoding AES256-CTS-HMAC-SHA1-96 AES256 = AES using 256-bit key CTS = ciphertext stealing HMAC-SHA1-96 = HMAC using SHA-1 hash function with mac truncated to 96 bits. The benefits of HMAC truncation are discussed in FIPS PUB 198-1, chapter 5. For HMAC-SHA1 96 bits is very common truncation, used for instance by IPsec/ESP. For figuring out what key ...

Top 50 recent answers are included