Hi Uma, good points here. I chatted with Alejandro Abdelnur about this, here's how it works right now:
- Each encryption zone has an ezKey of some size. generateEncryptedKey hardcodes usage of AES/CTR/NoPadding, which means a 16B IV.
- When generating a new encrypted key, it has the same keySize as the ezKey and same IV size as the hardcoded AES/CTR/NoPadding
- All AES algorithms uses a 16B IV, so we're find as long as the DEK is always AES too (okay limitation)
- We don't foresee switching the hardcoded AES/CTR/NoPadding, so don't need to pass a CipherSuite into generate/decryptEncryptedKey
- Enforcing that the ezKey and DEK need to have the same keySize is not great, but tucu thinks it's a reasonable limitation. If a user wants to change the keysize, they need to make a new EZ with a bigger ezKey and copy everything there.
- You can still use whatever AES algorithm you want for the actual data encryption, which is what the per-file CipherSuite specifies.
I find this pretty complicated, so is definitely something we need to put in the user documentation. createEncryptionZone also seems like it needs a way of specifying the key size, but we could do that when we actually support AES-256. Do you think we need any other improvements? We could try to improve how things are modeled in CipherSuite (since we depend on the block size being 16B), but maybe it's okay as is.