Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I was tasked to implement some sort of password-based encoding/decoding in an android app by my non-tech SO. He also showed me this list of android security providers. Naturally, He chose the one with the most acronyms and highest numbers (PBEWITHSHA256AND256BITAES-CBC-BC) to go with.
How do I explain to him (in layman's terms) that the provider is quite overkill for the app, and might result in a performance hit?
Password-based encryption, with both encryption of the data and a signature to prove that the data can't have been modified by anyone without having the password, using longer keys, is a good choice.
PBE = password-based encryption. Isn't this what you need?
WITHSHA256 = SHA-256 is a modern hash algorithm, and is used to prove that the data can't have been modified by anyone with having the password at hand. 256-bit hashes are the modern standard, with 512-bit hashes for those of us who want just a little bit more reassurance. The SHA-2 family of hash functions is the most recent NIST standard digests.
AND256BITAES = AES-256 is a modern encryption algorithm. The 256-bit key size is for those of us who want just a little bit more reassurance, even though a 128-bit key size can be sufficient for many uses. The AES family of functions are the most recent NIST standard block ciphers.
CBC = The CBC mode for encryption is the default choice for turning a block cipher into a stream cipher. Stream ciphers are needed when one has a stream of data of arbitrarily length to be enciphered. AES in CBC mode is a more modern choice than RC4.
BC = The choice of crypto provider library. Choose a reliable, performance crypto library. BouncyCastle is implemented in Java, so the JIT may be able to optimize it. OpenSSL is implemented in C and the crypto provider might have bindings to the C functions, but the JIT is unable to optimize the C functions.
If there is a need to encrypt, then there is an equivalent need to encrypt with modern algorithms and techniques. Use them, unless there is a specific, demonstrable, and proven reason against.
Without further information, it is not possible for us to say whether that algorithm is overkill. It may be just right. You need to look at both the performance and risk requirements to determine the algorithm. And those requirements should be agreed between the business and security- the compromise will determine the IT requirements.
"PBEWITHSHA256AND256BITAES-CBC-BC" is not that bad a choice (see @Justice's answer). It does not tell everything about what will be done at a cryptographic level; namely, "PBE" means "Password-Based Encryption", implying that a password will be transformed into an encryption key (a 256-bit key, since the encryption system is AES-256) using a hash function. Such a transformation is subject to some configurable parameters (iteration count, salt...) and there's ample room for botching things. Yet SHA-256 and AES-256 are sound choices. AES-128 is somewhat preferable since it is already secure enough against non-extra-terrestrial technology, and is about 29% faster than AES-256 -- but that speed enhancement is only in ideal conditions, when the raw symmetric encryption is the bottleneck and everything else in the software application is fast and slick; this rarely happens. In the list of algorithms you link to, this would make a case for PBEWITHSHA256AND128BITAES-CBC-BC.
The real problem is that your non-tech SO appears to be a chimpanzee: he makes security choices based on the prettiness of the acronym. He will still get it right occasionally, if only out of pure luck, as in this specific case. Yet, on a general basis, this is worrisome. As for convincing him to alter his choices, rational scientific arguments are unlikely to be effective: Science only works on people who are already submitting to its greatness, and someone who goes to the meanest-looking acronym is not ready to accept that Science applies. I suggest you try to give him a banana instead. In your case, the tasty fruit would take the following guise: emit the hypothesis that AES-128 would reduce costs by (up to) 29%; that's a blatant lie (financial matters are only extremely loosely linked with raw encryption speed), but at least it is a shiny one.
(To be fair with your SO, it is quite possible that he only tries to appease another ape located higher on the hierarchy. This does not really change the situation.)
You might want to try showing him that it is much slower than basically any other algorithm on that list.
Just run each algorithm a millions times or so, and show him the time difference. Then explain that the faster one is perfectly secure.
