> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Paul Chubb > Sent: Wednesday, October 10, 2018 19:16
> I am in the process of using the openssl suite for many things including > encrypting private information. There is a heap of information on the internet > suggesting using the openssl client for these sort of purposes. However in a > very few > places there are also statements that the client is only for testing the > library and > shouldn't be used in anger, that it isn't secure or that only certain > protocols are > correctly implemented. ... > I am using aes-256-cbc to encrypt streamed data (a backup). You haven't explained your threat model. If you're encrypting your diary so your kid sister can't read about your crush at school, then sure, use the openssl utility with aes-256-cbc. If the data you're encrypting falls under a regulatory regime with potential stiff legal consequences, like HIPPA or GDPR, then this is a Bad Idea. Here's the thing: Forget, for a moment, the question of whether you should script crypto using the openssl utility. The real issue, to my mind, is that cryptographic systems assembled by non-cryptographers are very often - probably almost often - fatally flawed. And AES is not a cryptosystem; it's a primitive. All the openssl utility is giving you there is a cipher, key length, and combining mode. Some potential problems that are obvious right off the bat: - No integrity protection over the data. You've run into the Moxie Marlinspike Cryptographic Doom Principle right off the bat. - CBC has problems. *All* the block cipher combining modes have problems. Stream ciphers have problems. How are you avoiding those problems? (Note that experienced people make implementation mistakes in this area.) - What are you doing about padding? Do you have predictable plaintext near the beginning? When do you re-key? - How do you generate and manage your keys? Are you practicing good key hygiene? - Data recovery from an encrypted backup is tough. With CBC, one bit goes astray and you've lost everything after that. (Well, you can brute-force a single-bit error, but it's going to be a tiresome exercise unless you automate it. Multi-bit errors will obviously be worse, and combinatorial explosion will bite you quickly.) ECC after encryption would be a good idea here, perhaps with an erasure code. Maybe you're storing to a suitable RAID mode or something; you haven't told us. I can't really suggest alternatives, partly because this isn't an area I pay a lot of attention to, but mostly because you haven't explained your use case. "Data backup" doesn't mean much unless we have some idea of how much data, how often, what sort of data, what it's being backed up to, how sensitive it is, and so forth. Sorry if this sounds overly negative, but in my opinion your question is severely underdetermined, and it sounds like you're potentially open to some rather serious failures. That may not be a concern - again, I don't know what your use case or threat model is. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
