Re: dar encryption - RSA

Hi Denis,

now I see the problem with signing the symmetric key
and your solution to sign also the catalogue sounds reasonable.

Are you interested in discussing the catalogue topic a little bit more?
I don't feel comfortable with storing passwords in clear text even on my
own system and to store the catalogue unencrypted is also not very
consistent in terms of privacy. In my opinion both options prevent users
actually from encryption there backups.
To make encryption more popular there should be no disadvantages when
using it! (I mean the problem with doing referential backups when using
encryption at the same time.) The effort for the user should be as small
as possible. As you know it isn't even simple to convince a user to make
backups at all. But when it means more effort to use the encryption
option, it is very unlikely that he will use it.
What do you think? 
I would be glad about hearing other comments on this topic.

Regards,
Tobias

Am Donnerstag, den 25.09.2014, 21:14 +0200 schrieb Denis Corbin:
> 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.
> 
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Dar-libdar_api mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api



------------------------------------------------------------------------------
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