If you are a business, then definitely yes. But the average self-taught developer will not have the resources available to hire a security consultant.
Instead of throwing money at the problem, you can instead choose to teach yourself more about the subject. We maintain a curated list on Github for people interested in learning about application security for this very reason.
> If you are a business, then definitely yes. But the average self-taught developer will not have the resources available to hire a security consultant.
True. You don't need to hire consultants to perform a security audit. Ask HN and Security Stack Exchange are good free alternatives to get critiques on your approach.
If you build something open source and it gets incredibly popular, security researchers will also probably come to you. This creates its own problems, of course. (Can't have problems without PR.)
CTR saves you the trouble of padding your plaintext before encrypting, thus eliminating an entire class of cryptography attacks (i.e. padding oracles). The security margins of CBC and CTR are otherwise similar.
GCM is far more preferred to either CBC or CTR because it's less for the implementer to screw up.
NaCl's ChaCha20-Poly1305 is even better, because it's fast and constant-time.
Properly authenticated encryption that uses CBC+HMAC-SHA2 with PKCS7 padding is probably okay, but new developments should prefer AEAD modes above all else, and CTR+HMAC-SHA2 if no AEAD modes are available.
(The kind folks in ##crypto on freenode have pointed out to me that CTR also allows random-access decryption, where CBC mode does not. We haven't ever implemented this feature and cannot comment on it.)
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.
> 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?
Could you please point to an explanation why random access CTR decryption is dangerous? Or why it's more or less secure than random access CBC decryption?
Or is random access CTR encryption dangerous? I don't see how, unless you reuse the keystream / make it a two-time pad.
Thomas's answer probably has to do with the risks of decrypting a stream and being unable to authenticate it first. (See also: the Cryptographic Doom Principle.)
But it is still safe to do random access AES-CTR if you've already checked the MAC. Random access is not a problem, decrypting before authenticating is a problem.
