Re: dar encryption - RSA

Hi Denis,

sorry that I haven't checked your current master branch, you have done
great work!

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

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

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

Regards,
Tobias

Am Mittwoch, den 24.09.2014, 14:32 +0200 schrieb Denis Corbin:
> Le 24/09/2014 02:00, Tobias Specht wrote:
> > Hi Denis,
> 
> Hi Tobias,
> 
> > 
> > As I'm working on a user friendly automated backup solution based
> > on dar I have also done some considerations about encryption. For
> > me encryption is a major topic to ensure privacy and to do so it 
> > must be easy to use for everyone, not only for IT-experts.
> You are right... and libdar needs such user friendly interfaces. :)
> > 
> > The first question: is it possible to get to know whether the
> > archive is encrypted or not before I open it?
> 
> Yes, but not at API level. The archive header and trailer contain a flag
> that tells whether the archive has been encrypted. Starting with future
> release 2.5.0 the encryption algorithm is also present in the
> header/trailer, so user will only have to specify the password even if
> the algo is not blowfish.
> 
> > When I try to open it without a password I get the error message
> > anyway.
> 
> This is due to that flag in the archive header (used when
> sequential-read is used) and archive trailer (used with direct access
> (default) mode).
> 
> > 
> > Now to some deeper considerations about encryption. When creating
> > backups automated on a regular basis (eg. every day the computer is
> > running) it is annoying to enter the password every time to encrypt
> > the backup. When thinking about this problem I came up with the 
> > following idea: We could use in addition to the symmetric
> > encryption system of the dar archive a asymmetric encryption schema
> > like RSA. In asymmetric encryption a different key is used for
> > decryption then for encryption.
> 
> This is implemented in the current development code (what will be
> release the 2.5.0)!!! Also archive signing is available!!! You can at
> the same time encrypt for several recipients and sign with you own
> public key.
> 
> Note that the asymmetrical encryption is used only to cipher a randomly
> chosen key used of symmetrical encryption. This is always a symmetrical
> encryption algorithm that is used to encrypt the whole archive. Archive
> signature is done on that randomly chosen key. There is thus a weakness
> if the archive is signed and at the same time encrypted for *several*
> recipients.
> Each recipients can known the random key used to encrypt the archive,
> and can thus reuse that key to create a completely different archive,
> faking the signature of the original sender.
> 
> To overcome that weakness in signature (not encryption), I have
> planned to add a hash of the archive catalogue (which contains CRC of
> each file's data and EA), and sign this hash too in addition to the
> randomly chosen key for symmetrical encryption. If you seen other
> point of find better idea, feel free to expose them here! :)
> 
> > Once for every user/computer a pair of public and private key is 
> > generated. The public key can be stored in plain text because it is
> > only used for encryption. But the private key must be encrypted so
> > that the user has to enter a password to open the key and to
> > decrypt data that has been encrypted with his public key.
> 
> The asymmetrical encryption is implemented based on libgpgme, thus it
> uses the same keyring as gpg. In particular, the public key
> verification, expiration and management is done there. For private
> key, dar does not have to store them just invoke their use specifying
> the associated email address: this is the most simple option I found
> to target a particular public or private key, instead of specifying,
> full name, or Key ID which are either difficult to write down and
> associate to a peer or may lead to ambiguity between different mailbox
> of a given person (home/work, etc.).
> 
> > When a backup is created a random password for the encryption of
> > the archive can be generated. This password is only used for this
> > one archive. And now comes the magic thing, the password can be
> > encrypted with the public key which can be done without user
> > interaction.
> 
> yes, this is that way it is implemented in current development code.
> 
> > To decrypt the password for the backup the private key is needed
> > which itself is encrypted.
> 
> To my point of view, there is a risk to transmit the private key, even
> encrypted. It should not be necessary thanks precisely to the
> public/private key separation. To encrypt I only need the public key
> of my recipent(s). The archive can be sent without additional
> information to the expected recipients that will be able to uncipher
> the archive.
> 
> > In this case the user has to enter his password.
> 
> so we are back with passwords, not much different than symmetrical
> encryption, no?
> 
> > So a user only needs to remember the password of his private key.
> > With this he can decrypt all the passwords for his backups.
> 
> rather use dar with symmetrical encryption of your ~/.gnupg
> configuration directory that contains all the private and public keys
> you have! no? :)
> 
> Having the private key not transmitted and kept in secured storage (at
> the discretion of the user) let the user choose to have a passphrase or
> not to have a passphrase on his private key, without compromising
> security by requiring the private key to be exposed.
> 
> > In a backup solution the user should of course not care about all
> > the keys, he only needs to enter his password for the private key
> > and every thing else is done by the program.
> 
> Yes, you underline the problem for disaster recovery when using
> public/private keys. An alternative to encrypting the private key
> alongside the archive would be for the advised user to keep a copy of
> his key a a secure location (trusted friend) or to store it remotely
> (cloud) after having encrypted (using dar for example) it with a strong
> but symmetrical algorithm using a password he would have to remind.
> 
> To my point of view, symmetrical encryption is suitable for backup to
> the cloud, where you can recover the whole data by the sole
> requirement of a password.  Asymmetrical encryption instead seems more
> to exchange data between different persons either directly (email) or
> throught repositories (cloud, ftp, ...).
> 
> > I have implemented a proof of concept to create backups like this
> > and it is working really well. What du you think about this idea?
> > 
> > If you like it, I have a feature request for you. To do all the RSA
> > stuff I need to store some extra data: 1) the encrypted password of
> > the dar archive
> this is done in current dev code,
> 
> > 2) the ID of the public key with which the password has been
> > encrypted. (this is useful because the public key is also part of
> > the private key so it is easier to match the corresponding private
> > key to the key-file of the backup)
> that's not necessary, if you have the private key in your keyring the
> fact to asymmetrically encrypt that password allows libgpgme able to
> decrypt the password automatically (check current dev implementation,
> man page is up to date on that point) [the current feature I'm working
> on is multi-threading inside libdar which you cannot activate for now,
> so current dev code is quite functional for the asymmetrical
> encryption, ok not for production use, if you have any problem
> compiling dar dev code and want to play with that asymmetrical
> feature, tell me.]
> 
> > This information can be saved in separate files but this lets to 
> > confusion and if any of this files get lost, it is impossible to 
> > recovery the password of the backup.
> 
> as you say, same to me, I don't like external file, and as said above
> this is not necessary.
> 
> > To make things easier it would be nice to store them in the header
> > of the dar archive. To be exact this would be 256 Byte for the
> > encrypted password and a SHA256 value for the ID of the public key
> 
> The random key has a variable length (+0 to +256 bytes) and at minimum
> 512 bytes (user parametrable using the --key-length option), for API
> check the src/libdar/archive_option.hpp file, all that is 'key' related.
> 
> > As I have just noticed dar supports a user defined message to be
> > written inside the archive header (--user-comment).
> that's correct,
> 
> > You have documented that this message is unencrypted
> yes, see --user-comment option in man page.
> 
> > even if the archive is encrypted. But I have found no way to read
> > the message without providing the password of the archive.
> Right, it is stored in clear but the API call that opens an archive
> aborts if the archive contents --- which is encrypted ---- is not
> readable (due to wrong key or data corruption).
> 
> > Is it possible the read the user message without knowing the 
> > password of the archive?
> yes, just open the archive in a text editor! :) You will find it near
> the beginning of the archive (unless -at option has been used).
> 
> > (On a long run it would be nice to have a separate option in the
> > archive header for the RSA stuff.)
> There is, check the --sign and --key options in man page. Note, that
> you can read the man page getting the source code (branch master in
> GIT), 'cd man' there 'man ./dar.1' the easiest way to get it without
> installing the whole software.
> 
> Same thing once compiled you can run dar without installing it by 'cd
> src/dar_suite' and there running "./dar ..."
> 
> > 
> > Finally there is another thing which I had to consider. When
> > creating a backup with a reference to an encrypted archive, I need
> > the password. To bypass this problem I have isolated the catalogue.
> >  I know it would increase the complexity of the archive header to
> > store the catalogue either encrypted or unencrypted, but it would
> > eliminate the need of the isolated catalogue file. I could imagine
> > that is a quite common issue.
> 
> Maybe I don't follow you. If I'm wrong don't hesitate to tell me:
> You can do a differential/incremental backup with a encrypted archive as
> reference using the -ref-key option to provide the necessary credential
> to read that archive. The archive you create that way is either
> unencrypted or encrypted if you use the -K option with same or other
> credentials. (for merging operation that involve two source archive
> there is also the -aux-key option).
> 
> An isolated catalogue may be encrypted too (-ref-key option to read
> the source archive and --key to encrypt the resulting archive).
> 
> But, yes, dar_manager cannot still read encrypted archives, to manage an
> encrypted archive with dar_manager you need an unciphered isolated
> catalogue... this feature is still in the todo list, but I guess I will
> not have time to implement it for the release 2.5.0 which I have
> targetted for the end of year (end of new feature implementations,
> then comes a testing/optimzation phase, for I hope a major relase in
> 2015).
> 
> The src/build/Changelog file gives you an overview of new features that
> will be available with release 2.5.0.
> 
> > Are you planing to add a possibility to store the catalogue
> > unencrypted even if the archive data is encrypted?
> no, this does not makes sens to me. If the archive has to be encrypted
> this is to prevent anyone except the authorized person(s) to read its
> content including its table of contents.
> 
> > 
> > Regards, Tobias
> > 
> 
> 
> Kind Regards,
> 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