Aham Brahmasmi wrote: >If I am not wrong, the verification should fail. If you have a system that uses private / public signing keys then, yes, you're correct.
But: 1) In my opinion it's probably overkill for just doing backups. As I said in my previous email, just using symmetric encryption and encrypting in advance the few files you really care about is probably good enough and simpler. 2) You'll have to remember to encrypt your private signing key (using some symmetric encryption like aes256) before you make a backup of it. >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. That's right, because the public keys are already in /etc/signify and the signature verification would fail. The use of public / private keys here is necessary because files are distributed to other people and these other people must not have access to the private key. In your case there is no "other people" so using public / private keys is probably more than you need. A simple symmetric encryption with just a password would be good enough in my opinion (but it's only my opinion, it's up to you to decide what's best for you). You have to ask yourself: what are the problems that I am trying to defend against? Then use the simplest solution that solves those problems. Be practical, and don't waste time trying to defend against threats which are only theoretical. >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. Well, then, you have a good reason to use signatures. Note that it still does not require a public / private key system. You could just compute a hash of your DB (before encryption) and then store the hash on your backup system (no need to encrypt the hash) together with the encrypted DB (encrypted using symmetric encryption and a password). Then later you would: 1) decrypt the DB 2) compute the hash of the decrypted DB and check that it matches the hash from the backup system. Note that in that case the hash must be created *before* you encrypt the DB, not after, otherwise you will not be able to detect a change done to both the file and the hash on the backup system (as I said in my previous email). Anyway, it's up to you to decide what you want to do and whether you need a hash and / or public / private keys, but my advice is to keep your system as simple as possible. Philippe
