In Algorithm: dh-ietf1024-sha256-aes128-cbc-pkcs7 where to get the IV?
emmalee last edited by
golangand according to documentation I've managed to create the 128-bit key appropriate for
AES(from my 1024-bit shared-key computed from my private key and clients public key).
API function input is just algorithm name and client public key. And for using
AESI need to use the same
IVthat my client uses (am I correct?).
The question is where this
- DH key agreement [rfc2631] is used to create a secret key using 1024 bit parameters of the standard IETF 'Second Oakley Group' [rfc2409].
- The secret key is then digested into a 128-bit key appropriate for AES.
- This is done using HKDF [rfc5869] with NULL salt and empty info, using the SHA-2 256 hash algorithm [fips-180-3.2008]. -The secrets are encrypted using AES [fips-197.2001] in cipher block chaining mode with pkcs7 style padding [rfc2315].
- Start Diffie-Hellman key exchange (DJKE) to agree on a key
- Both sides uses HKDF to derive the symmetric key
kof the required side.
- Generate random IV by using
/dev/urandomor better methods.
- Encrypt message
c = AES256-CBC( k, PKCS#7padding(m) )
|cto the other side.
- The other gets the
m = AES256(k,c)and checks the PKCS#7 padding.
The usual practice is prepending the IV to ciphertext like a bundle
|IV|ciphertext|and send it to the receiver. Encoding base64 of the bundle is advised.
While using the CBC mode with AES you must consider this;
You must choose a 256-bit secret key
kuniformly at random. You must keep it secret all the time.
In your case DH generates this.
Make sure that your messages are always an integer multiple of 128 bits long. To satisfy this you can use PKCS#7 padding and be aware of padding oracle attacks.
If a key
kis reused for multiple messages, you must choose a 128-bit initialization vector that is (a) unique and (b) unpredictable in advance. 4 The total data length must not be past 260 bytes of data using the same key k.
You must not send more than 248 messages using the same key
In return, AES-CBC guarantees against an adversary who can adaptively influence plaintexts sent by Alice and Bob.
CBC mode has Ind-CPA security means the adversary cannot distinguish the ciphertexts of two equal-length messages even they choose the messages. Therefore they cannot read messages chosen by Alice or Bob.
If you violate the unique in your obligations, then the adversary can detect that a message is sent again. The random IV provides probabilistic encryption to mitigate this.
If you violate any other, the security properties provided by AES-CBC will be lost.
The 1024 bit DHKE is not considered today's standards. For the equivalent of 128-bit symmetric security, you should use at least 2048-bit by ANSSI's approximation. See on keylength.com
DHKE exchange provides forward secrecy, in order to achieve that both sides must delete the keys upon decryption. If the keys are kept keys at least one side and that side is attacked then the attacker can read the previously recorded sessions. This validates the forward secrecy.
HKDF has these parameters
`k = HKDF( salt, IKM, info, L)
- where IKM is the input key material that comes from the output of the DHKE in your case.
- info can be used for a generation multiple keys from a single IKM.
In your case salt is NULL and info set to empty string.