4 ms·
I feel like "if an AEAD mode isn't available, use CTR with HMAC with the following caveats..." is a bit like saying "if you drive without a seatbelt, make sure
by KMag 11y ago
I feel like "if an AEAD mode isn't available, use CTR with HMAC with the following caveats..." is a bit like saying "if you drive without a seatbelt, make sure to drive extra carefully".
Really, if your car doesn't have seatbelts, find an aftermket kit or buy a new car. Likewise, there are BSD-licensed libraries that provide GCM and ChaCha20-Poly1305. These are your aftermarket seatbelt kits for your deathtrap-car of a crypto library.
That being said....
If I were to drive without a seatbelt... CTS instead of CBC mode prevents padding oracle attacks. If you have a flaw that causes IV reuse, CTS and CBC leak less information than CTR mode.
For those driving without seatbelts... CBC and CTR modes do most definitely allow random-access decryption. Seek to block N and decrypt it, then seek to block N-1, read and XOR with the plaintext from your previous decryption. (It's a bit more complicated for the last two blocks of CTS mode, but only a bit.) CBC and CTS do not, however, allow random-access modification, since a single changed bit will on average flip half of the bits in every following block, to the end of the message.
- teacup50 11y ago> Really, if your car doesn't have seatbelts, find an aftermket kit or buy a new car. Likewise, there are BSD-licensed libraries that provide GCM and ChaCha20-Poly1305. These are your aftermarket seatbelt kits for your deathtrap-car of a crypto library. On mobile devices, this can mean not being able to leverage significantly optimized vendor-provided crypto libraries. I'd be interested in benchmarking the difference between a decent BSD-license GCM implementation and our use of AES-CBC+HMAC ETM on iOS hardware. Is there a particular AES-GCM implementation you'd recommend starting with?