Re: dar encryption - RSA
Denis Corbin <[email protected]> Thu, 25 Sep 2014 21:14:02 +0200
| Newsgroups | gmane.comp.sysutils.backup.dar.libdar |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/09/2014 17:08, Tobias Specht wrote: > Hi Denis, Hi Tobias, > > sorry that I haven't checked your current master branch, you have > done great work! No problem, the dev branch is not much visible... > > Regarding your problem with the signature. Maybe we talk past each > other but in general signing goes like this: A check-sum of a > document is encrypting with the private key of the sender (not with > the public key of the sender neither of the receiver) so that > everyone else can verify the signature by calculating the check-sum > at his own and compare it with the value from the signature as > every one can decrypt it with the public key of the sender. yep, > In your case the document is the symmetric key and as check-sum > you could calculate a hash value. When you encrypt the hash value > with the private key of the sender (eg. the person who creates the > backup) it is in my opinion ensured that no one else has created or > modified this backup. In other word the "document" which is the symmetric key could be copied as is in a new archive. Any recipient could also decrypt the "document" and obtain the symmetric key, thus could use it to create an new encrypted archive with that same key. This would lead any other recipient see this faked archive as signed by the same person as the original one, unless you apply signature on some other part of the archive, like the internal catalogue. > > The thing with the asymmetric encryption was just an idea I had a > few days ago. And I think we have designed it for two different use > cases. The general idea to use asymmetric encryption was in my case > to create backups automatic without prompting the user to enter the > encryption password. Not to encrypt them for different recipients. well you could also drop the password in a file that only the user could read and feed that file to dar using -B option. No need of symmetrical encryption to have encrypted archive without manual interaction nor exposing the password to the command-line. > And this was also the background of the catalogue question. Of > course I can create a differential backup based on an encrypted > archive by providing the key for the archive of reference. But in > this case user interaction is needed which I wanted to avoid. You > understand? I better understand what you want to do, but why not using Dar Command-line File (DCF file) you could use with -B option as just exposed? (I do it myself for my own backups that get stored remotely. moreover, as it is a password, which password I know, in case of disaster, I do not need any private key to decrypt the archives. > Yes, your right, an unencrypted catalogue does not ensure privacy. > And for sure there is no easy solution for this problem. In my > opinion the most sensitiv data in the catalogue are the names of > files and folders. One quick approach to restore privacy in an > unencrypted catalogue would be to store only hash values of this > information. How ever you solve this problem, it would led to big > changes in dar and maybe the field of application would me quite > small. That's right, > So never mind. > > About the private key, I don't wanted to store it inside the > archive. I just wanted to store the information which privat key to > use for decryption. In your case this is done via the email address > of the recipients and in my case it would be the finger print of > the public key with which the symmetric key has been encrypted. OK I see, sorry for my misunderstanding! > > One last thing I want to add regarding private keys in general. > Because the whole security relies on this file it has to be kept > secret and this is not done by storing it unencrypted on a hard > drive (I'm sure you don't write your passwords in to a text file > either). Well, yes I do :) but with adequate file permission and if I trust the system engineer (Which I am at home). For work backup, of course I type the password at each new backup... > When you don't want to have a password but want to ensure privacy > you can move the "security factor" inside some kind of hardware > token. But also in this case it is recommended to protect the > access to the private key by a PIN. Yes, that's right > > Regards, Tobias > Cheers, Denis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIVAwUBVCRpeQgxsL0D2LGCAQJ74Q//eNICXjvH+a37WIt1sO1GTI/k5/OpFBB5 Kx8c709XZY0PLfy5fMhyW6eqmjDBwH+vdjEMlE7B67noEdWXDjmvJgH+4SbSj9CW 15psFyoCytxC4PuIaJ745V5FSx9Jy+F6MU5Zo9OPfpqnqo+e7ggvJxTgw4urdobT xguBDzvZBCdcLg4c66qgymf3mw1ju9CJZyDn5JGy77nteBGCyRRqGBkhwMVXgk6f x8nFywW46SjjLU6K9Wd7aUrZvQ6fme1hjjaa0euxlhdHpORdHJ0pld7BgpPNFe+o VTMbaUxrA1lfdqt+povHu/oznepDAmtZyCfdEdNskB6QvLahX+gC/ji8SzsXUUJs SC5Ez1EoKrwEdfZ069pSPPDS9B05l4ZUpMsFd6Q828XCgeFLZno4E3245cZRTaZO y/Isd+QUw/zw9kJ0UAzauOy/NPhT9yMt5jDSEcDRC3q90zdsMhgcO112XvNxgXcG wwqRXaYS1qDP2ZU2X971vTF8TWCPxJfkUAULeo4K2DqjjEGDZbwVkikAuU9EGBdr RQGN8mG3+OpIwuQTt0VkYI5Apu9vqFMVsKrjXdiJPqdjVnNXdjMwjcmYbU07gg4k 4+Z6Vwed1Cr6+1rNzkrjKN50AudDQQSYNiMLaQ8o8KFvYPVNmPeg7cL9IVIy3Ek0 3uTIyPNPgRk= =sPsZ -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk