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