0
$\begingroup$

It's that time of the year - I'm trying to learn how AES-128-CBC encryption works. My key is (since it's AES-128) is 16 bytes, my IV is 16 bytes as well. My implementation of key wrapping does apparently does not help me much to comprehend the concepts behind and neither does reading the RFC. Hence I turn for answers to this great community.

I found out the following:

  • If I encrypt (using the methods and ciphers stated above) a 2 block file (32 bytes) I get a 48 bytes encrypted (3 block???) file. Is this correct?
  • Key wrapping is just encryption of a key you use for encrypting a program, so half of it needs to be unwrapped in order to decrypt the full 32 bytes. (not sure about this though) The wiki page does not explain it well either.
  • SIV seems to be a more modern approach to solve this problem, but I can't fathom how it works either.

What confuses the heck out of me:

  • In layman terms, how does key wrapping work? It takes the 16 bytes key and wraps into 24 bytes or how? I wrote a program which wraps and unwraps the key but it always seems to have the same length so I'm confused. 4.1 in the RFC seems to show the same length for everything so I'm super confused now. Also, if I try to use the same length for all 3 inputs (input, IV and key) I get the error that the input is not 3n or more, where n= 8 bytes.

  • Why is a6a6a6a6a6a6a6a6 the default IV for AES-128 key wrapping? How does it equate to the extremely low chance or a IV mismatch (which I don't get)?

  • What is a IV mismatch? I got it in CyberChef while trying to unwrap my AES key.

  • Is SIV (Synthetic Initiation Vector) just a modern implementation of this key wrapping or this something completely different?

  • If I want to unwrap a AES-128-CBC key wrapping I need at least 3n of bytes, where n= 8 bytes, why?

  • Why when I try to decrypt a lightly modified version of my program literally half (the second half, so 16/32 bytes) of the plaintext gets revealed? What's going on here?

I would appreciate it if you could shed a light into the darkness and do please let me know if this rather belongs in Cryptography SE.

$\endgroup$
3
  • $\begingroup$ It will be better suited to Crypto, but you don't need to post there, we can move it there for you. $\endgroup$
    – ThoriumBR
    Aug 17, 2023 at 19:16
  • $\begingroup$ Would appreciate a migration of the question :-) $\endgroup$ Aug 17, 2023 at 19:17
  • $\begingroup$ WRT 'If I encrypt.. a 2 block file (32 bytes) I get a 48 bytes encrypted (3 block???) file. Is this correct?' - This may be because of padding (not key wrapping). With AES encryption - if the input is a multiple of 16 bytes in length, then PKCS 5/7 will add an entire block of 10 bytes as padding. $\endgroup$
    – mti2935
    Aug 17, 2023 at 21:04

1 Answer 1

3
$\begingroup$

I'm trying to learn how AES-128-CBC encryption works. ... My implementation of key wrapping

Key wrapping is a specific form of encryption. You don't necessarily need key wrapping to encrypt something. Using this RFC to learn about encryption is not the most straightforward way.

Also, the key wrap algorithm from the RFC does not use CBC, so it seems you are confusing or combining two things?

If I encrypt (using the methods and ciphers stated above) a 2 block file (32 bytes) I get a 48 bytes encrypted (3 block???) file. Is this correct?

AES-128 encrypts 16 bytes plaintext into 16 bytes ciphertext, so the length remains the same. However, AES-128 is typically used in a specific mode of operation (such as CBC) or as the building block of another algorithm, such as key wrapping. Typically the encrypted message contains a nonce or initialization vector (IV) to randomize the encryption, and authentication tag to verify the message was not tampered with.

RFC3394 describes the expected length in section 2.2.1:

Inputs:      Plaintext, n 64-bit values {P1, P2, ..., Pn}, and
             Key, K (the KEK).
Outputs:     Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}.

The plaintext is n blocks in length, the ciphertext is n+1 blocks in length.

Key wrapping is just encryption of a key

Right, it encrypts one key with another key. It's an algorithm specifically designed to encrypt keys, and not meant for general purpose encrypting.

so half of it needs to be unwrapped in order to decrypt the full 32 bytes (not sure about this though)

This sentence doesn't make sense to me. "Unwrapping the key" means decrypting the ciphertext using the key wrap algorithm. Half-unwrapping is not really a thing.

In layman terms, how does key wrapping work?

Just like any other authenticated encryption, but now the thing that is encrypted is the key. So you would encrypt the data key using the secret key encryption key (KEK). Then later, you would decrypt the ciphertext with the KEK and that returns the data key.

it always seems to have the same length so I'm confused.

I would expect that if you use a longer key, you also get a longer ciphertext. I am not sure what you tried that confuses you.

Why is a6a6a6a6a6a6a6a6 the default IV for AES-128 key wrapping?

This seems to just be a convention without much reason behind it. Normally when encrypting things, you would use a random IV. But because this key wrap algorithm is specific to high-entropic keys, they came up with a different algorithm that uses a fixed IV.

What is a IV mismatch?

You wrap a key using the IV a6a6a6a6a6a6a6a6. Then when unwrapping, it again calculates the used IV. If unwrapping went fine, the IV will be a6a6a6a6a6a6a6a6. If the message was tampered with in the meantime, the IV will be different. So an IV mismatch means that the message was not authentic.

Is SIV (Synthetic Initiation Vector) just a modern implementation of this key wrapping or this something completely different?

SIV is a block cipher mode of operation. A key wrap algorithm has been designed using SIV, and that's described in RFC5297.

If I want to unwrap a AES-128-CBC key wrapping I need at least 3n of bytes, where n= 8 bytes, why?

I'm not sure about this.

Why when I try to decrypt a lightly modified version of my program literally half (the second half, so 16/32 bytes) of the plaintext gets revealed?

Is this using CBC mode? You probably edited one block in the ciphertext, with scrambled one block in the output. Since each block is encrypted seperately, it's possible that other blocks still decrypt correctly. I've written more about that in bitflip effect on encryption operation modes.

$\endgroup$
1
  • $\begingroup$ > Also, the key wrap algorithm from the RFC does not use CBC . it doesn't, but the initial encryption does $\endgroup$ Aug 18, 2023 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.