> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Nicholas Papadonis > Sent: Saturday, November 03, 2018 13:03
> https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup Thanks. Yes, that's talking about the CBC mode malleability issue, which Hanno Boeck described. I didn't want to assume you were referring to CBC malleability, because your original email implied you were talking about an issue specific to OpenSSL and referred to a pipeline at one point. Making assumptions that discard conflicting information can be dangerous when discussing security-related matters. (CBC malleability applies to all use of CBC mode, regardless of implementation or underlying block cipher. A cryptosystem using CBC has to provide some kind of message integrity to prevent it.) > No regulatory requirements. I'm a personal user making sure to take best > practices into account for > securing data. I also have the assumption that there are numerous attack > vectors in involved in storing > computer data, all the way back to the design and manufacturing process. > I.e. you need to design, > manufacture and test your own computer to be truly secure. As with standards, the great thing about "best practices" is there are so many sets to choose from. Here's the thing: There is no such thing as "truly secure". Security is not an absolute state. There are various ways to model it, but it's always in some sense economic. You can look at the relative costs of attack and defense, and the value of the protected system to the attacker and the defender; you want to maximize the cost of attack, preferably so that it makes access unprofitable, while keeping the cost of defense within an appropriate budget. (Note that "cost of defense" includes things like usability for authorized users and risk of data loss if a key or ciphertext is corrupted; it's not just material and effort.) You can also model security in terms of the probability of various types of adverse events (unauthorized data exposure, alteration, or loss, in this case) and the costs to you of those events - you want to minimize the sum of the probability-cost products. Understanding security as relative rather than absolute also means that "best practices" will depend on your threat model and security budget. Now, all that said: In this particular case, if you're weighing using the openssl command-line utility or gpg, use gpg (in symmetric-encryption mode). For the reasons Hanno and I mentioned here on openssl-users, and the reasons given in that StackExchange thread. The openssl utility isn't intended for this; gpg is. Some people have suggested some other alternatives, such as encrypted filesystems. There are also inexpensive encrypting USB drives and the like, which are good for some use cases. > I want to keep at least two copies of data in different locations for > disaster recovery. Each copy itself should > have a backup stored with it in case of a bit error. OK. It's good to consider and mitigate various failure modes. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
