NFD » ndn-cxx

Davide Pesavento wrote:

What mode(s) of AES? BlockCipher already supports AES-CBC

NAC supports two algos: AES-CBC and AES-ECB. Given that CBC is more secure than ECB. It's fine for NAC to cut the option of ECB. I think we'd better have some helper functions to initialize IV and AES key.

Zhiyi Zhang wrote:

NAC supports two algos: AES-CBC and AES-ECB. Given that CBC is more secure than ECB. It's fine for NAC to cut the option of ECB.

ECB is insecure and should definitely NOT be used.

We should consider adding the CTR mode of AES, which allows to decrypt each block independently, unlike CBC which requires knowing the ciphertext of the previous block (can be inefficient for blocks that are at a packet boundary). Moreover, in CTR mode, plaintext blocks can be encrypted in parallel.

I suppose we also need the KW (RFC 3394) and/or KWP (RFC 5649) modes for key wrapping..? Or is NAC using something else for that?

I think we'd better have some helper functions to initialize IV and AES key.

Makes sense. We can add a SymmetricKey wrapper similar to the existing PublicKey and PrivateKey classes.

ECB is insecure and should definitely NOT be used.

ECB is simple. It’s insecure for uncompressed bitmaps, but fine for small inputs shorter than a cipher block. Most sensor readings belong to this category.

We should consider adding the CTR mode of AES, which allows to decrypt each block independently, unlike CBC which requires knowing the ciphertext of the previous block (can be inefficient for blocks that are at a packet boundary). Moreover, in CTR mode, plaintext blocks can be encrypted in parallel.

CTR mode can be useful for encrypting sensor readings, if the counter can somehow be tied to the application layer sequence number.
CBC for small inputs is basically ECB.

ECB is simple. It’s insecure for uncompressed bitmaps, but fine for small inputs shorter than a cipher block

NAC should not make any assumptions on the size of the plaintext. Even for short inputs, CBC is never worse than ECB, so I don't see many reasons to offer AES-ECB as an option, the potential for misuse is just too high.

CBC for small inputs is basically ECB.

Only if you use a different key for each block. ECB doesn't have an IV.

Davide Pesavento wrote in #note-5:

CBC for small inputs is basically ECB.

Only if you use a different key for each block. ECB doesn't have an IV.

Ergh, I'm unaware of that.

4 years later, I can only endorse AES-CBC and AES-GCM.
Other modes are crappy.

Nowadays, AEADs like AES-GCM and AES-GCM-SIV (*) should be strongly preferred. In some cases (e.g., separate authenticity/integrity checking) and if you know what you're doing, CBC and CTR can be acceptable.

(*) CCM is fine too but less popular than the GCM modes.