Chacha20 does not require messages to be multiples of block size, so it is
valid to use the cipher without the explicit padding AES-CBC would require.
Details
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 24111 Build 22970: arc lint + arc unit
Event Timeline
sbin/decryptcore/decryptcore.c | ||
---|---|---|
212 | This needs a little more sophistication. Openssl uses all of the first 128 provided IV bits to initialize, whereas our kernel implemented uses the first 64 bits as IV and initializes the counter to zero. This can be addressed in decryptcore's usage of openssl, just needs a little change. (One other note is that decryptcore will need to be retrofitted slightly to compile with openssl 1.1.x anyway: EVP_CIPHER_CTX_init/cleanup goes away and only opaque access to EVP_CIPHER_CTX is provided. Instead we should use _new() and _free().) |
sbin/decryptcore/decryptcore.c | ||
---|---|---|
212 | (re: 1.1.x, addressed in r338782.) |
Fix IV and at least initial counter used by OpenSSL decrypt. The 32-bit
counter variant should produce the same result as the 64-bit counter variant,
up to 64B * 2^32 = 256 GB of input.
Refresh Chacha EKCD mode for commit
OpenSSL in tree is now new enough to handle it and seems to tolerate a 64-bit counter.
Remove hacks that disabled AES-256-CBC and allow dumpon to choose a cipher with
-C.