Namaste Philippe, Merci beaucoup for your reply.
> Sent: Saturday, January 04, 2020 at 3:54 PM > From: "Philippe Meunier" <meun...@ccs.neu.edu> > To: "Aham Brahmasmi" <aham.brahma...@gmx.com> > Cc: misc@openbsd.org, Roderick <hru...@gmail.com> > Subject: Re: Request for recommendation - encryption and signature for file > backup > > >Aham Brahmasmi wrote: > >> In my limited understanding, to securely backup and restore a file, the > >> steps are: > >> > >> To backup: > >> Step 1 - encrypt the file using a tool > >> Step 2 - sign the encrypted file using a tool > >> Step 3 - backup the signature and the encrypted file > >> > >> To restore: > >> Step 1 - verify the encrypted backup with its signature > >> If Step 1 exits with success, > >> Step 2 - decrypt backup to file > >> If Step 2 exits with success, > >> Step 3 - use file to restore > > The signature verification step is useless: if someone can change an > encrypted file on your backup system then they can change the corresponding > signature file on the same backup system too. I am not a cryptographer, and neither am I a math expert. Let us assume that someone has access to the backup - both the encrypted file and its signature. This person does not have access to the encryption key and the private signing key - else this discussion is moot. This person changes the encrypted file and the corresponding signature file as well. Now, when this modified file is verified against the modified signature using the public signing key, would the verification fail or succeed? If I am not wrong, the verification should fail. In short, this is by definition of signature itself. For a longer explanation, to generate a valid signature, this person will need to have access to the private signing key. Since this person does not have access to the private signing key, the person can modify the encrypted file, but not generate a valid signature of the modified encrypted file. And modifying the original signature does not mean much - the verification with the public signing key will fail. For example, consider the OpenBSD release signing system. (I think) Theo signs the releases using a private signing key. If I am not wrong, only Theo has access to the private signing key, but we all have access to the public signing key. The bsd.rd is released along with its signature in the SHA256.sig file. We run signify(1) to verify the bsd.rd with its signature in the SHA256.sig file and the base.pub public signing key. Let us assume I get access to the download server and I replace the perl based installer with a rust based installer in the bsd.rd. I also change the SHA256.sig file. I do not think I will fool anybody who uses signify to verify the all-new-improved-rust-based-installer bsd.rd with the base.pub. And if you think I came up with this, no. I have only rehashed tedu@'s paper on signify - https://www.openbsd.org/papers/bsdcan-signify.html > If you use (symmetric) encryption then there is probably no need for a > signature in your simple use case anyway: if the encrypted file correctly > decrypts (which is usually easy to tell for data files like text or images) > with the password that only you know then you can assume that nobody > changed the content of the encrypted file on your backup system. If > someone changed the content of the encrypted file on your backup system > then, when you try to decrypt it, either the decrypt will fail or the > result will look like random garbage (hence the "usually easy" above). For files like compressed database backups, I am not sure I can determine whether a file has been correctly decrypted or not by looking at whether the result looks like random garbage. > If your goal is just to prevent people from looking at the content of your > file if they somehow access your backup system then encryption is really > all you need. If you're worried that people might actively try to attack > you through your backup system then you have bigger problems which are > probably beyond what random people on a mailing list can help you with... In the case of compressed database backups, it may also be possible that the backup may have changed due to bit-rot. So decrypting the backup and restoring it assuming no bit-rot may not be exactly preferable. > Roderick wrote: > >I do use openssl for encrypting files in my laptop. > > So do I. I only encrypt the 0.001% of files that are really important and > then those files are encrypted on my computer too, not just on the backup > system (because if a file is important enough to be encrypted on your > backup system then it's probably important enough to be encrypted on your > computer too). Something like: > > openssl enc -aes256 -e < foo > foo.aes256 > > then I delete foo. (To decrypt use the -d option instead of -e; and read > carefully the openssl(1) man page before you type the command above because > you have no reason to trust me, right?) Then I do backups without worrying > about whether a file is encrypted or not. YMMV. I am not sure about the openssl encryption. If I am not wrong, there was some feedback shared on solene@'s blog post and she modified it based on that feedback. Unfortunately, I do not remember what that feedback was. > Philippe Dhanyavaad, ab ---------|---------|---------|---------|---------|---------|---------|--
