Re: dar encryption - RSA

Hi Denis,

I like dar with its philosophy and I want to create a program using
libdar to implement some kind of intelligence. Of course there will be
some options but it should be enough to just define a "Backup Drive" and
backups will be created automatically every day the user powers on the
computer. And encryption should be at least a strongly recommended
option.

This leads me to the catalogue problem. 
I agree with you that dar does not need that kind of intelligence I'm planing for my backup tool,
but as the catalogue and the process of creating a referential backup is a elementary feature of dar,
I think this problem could be better solved within dar.

In the catalogue there is stored:
* inodeID
* filename (with its path)
* file permissions
* userID
* groupID
* file size
* last modification date (mtime)
* last change date (ctime)
* if the file is a directory (is_dir)
* if the file has children or is an empty dir
* file type
* flag about saved data / saved EA / compression used
(correct me if I'm wrong)
I think the most private information that has to be protected is the
filename. My idea was to create a second "hashed" catalogue which
contains only the necessary information to create a referential backup
out of it. It is structured like a dictionary with a hash representing 
the filename on the one side and with some information about the file 
on the other side. This dictionary can be stored outside the encrypted 
area of the archive because it doesn't contain any private information. 
Yes, it is more data to be stored and in general it contains only redundancy 
information, but with this we can create a referential backup from an 
encrypted archive without entering the encryption password which will 
lead to more usability. 
(And du you know any backup tool providing such a feature?)

The first idea was just to hash the filename:
{ 
    H(filename) : [inodeID, userID, groupID, perm,
		   file_size, ctime, mtime, is_dir, type, flags] , 
    ...
}
This is quite simple to implement, but it's not very resistant against brute-force attacks.
So I thought about to slip some information, that is available on the
point of creating the referential backup and also when creating the new
backup but isn't known by an attacker who has only access to the archive,
in the calculation of the hash value:
{ 
    H(filename + inodeID + mtime) : 
	[userID, groupID, perm, file_size, is_dir, type, flags, ctime] ,
    ...
}
I had a look at your source code (filtre.cpp/filtre_sauvegarde)
and as far as I have understand, you first try to find the file based on it's path in the
ref backup. When there is a match you perform some optional security checks 
and afterwards you decide what information to store in the backup:
* remove_ea
* saving_inode
* saving_ea
* saving_fsa
If there is no match you have to store the whole file. 

When using the hash value the first part leads to a slightly different result as it 
doesn't consists only of the filename but also of the inodeID and mtime.
But this shouldn't be a problem as the inodeID changes only when mtime changes too.
And in this case the whole file would be saved anyway.
As the security check is implemented now it should also be fine with the hash,
because it relies on having the same mtime in both archives.
The evaluation of what action to perform when mtime hasn't changed 
should be applicable with the information stored in the dictionary.

In addition we should add some sort of UUID which is connected to the system
in such a way that it doesn't change on normal system operation.
I thought about the partition UUID but this is not always that simple
when we think about LVM and btrfs, but maybe there is something else we can use. 
To break rainbow-table attacks we should also add a random salt per archive:
{ 
    H(filename + inodeID + mtime + UUID + salt) : 
	[userID, groupID, perm, file_size, is_dir, type, flags, ctime] ,
    ...
}
Originally I also wanted to slip the file_size in the hash value, 
but this conflicts with the security check and the sparse_file_detection.

The dictionary could be saved for example in a
Berkeley DB which could be stored some where in the archive.
As hash function I would suggest Keccak with 512 bit and 100 rounds.

What du you think about the idea of having a second (hashed)catalogue?

Regards,
Tobias

Am Sonntag, den 28.09.2014, 10:36 +0200 schrieb Denis Corbin:
> On 27/09/2014 18:13, Tobias Specht wrote:
> > Hi Denis,
> 
> Hi Tobias,
> 
> > 
> > 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?
> Of course!
> 
> > 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.
> I guess the main reason is not more complexity of encryption than
> ignorance and blindness of marketing/profiling possible abuses. When
> you even don't ask yourself whether you can trust the owners of the
> remote "cloud" storage you send your data to, for they do not read or
> analyze the content you've sent, you don't even thing about encrypting
> your data before sending it out...
> 
> 
> > To make encryption more popular there should be no disadvantages
> > when using it!
> I agree with that point, the less a task requires effort, the more
> people will probably do it. However, sometimes doing something safely
> will always cost more than doing it another way. In that situation
> educating users is at rescue. Example, many people today use seat belt
>  during their travels by car, while it is just easier not to use 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.
> Right, for now as small as possible is issuing a password. Without any
> key (of any sort) to be provided, how can you see a mechanism that
> could differentiate a user that has the right to access the data from
> another one that has not that right? How could it be done
> better/simpler? I guess you have suggestions about the differential
> backup context? :)
> 
> > As you know it isn't even simple to convince a user to make backups
> > at all.
> ... education... unless automatic backup is performed by the system.
> But if user are ignorant about the existence of such automatic backup
> mechanism, how would they think they can rely on it to restore their
> system when a single file got lost by mistake or a whole system has
> been destroyed (crash, stealing, disaster,...): The system has to be
> even more "smart" (by opposition to the user). Usually having systems
> getting "smarter" removes freedom to the users... so we must also pay
> attention not to remove freedom to clever users, those that either are
> educated about a subject (here backup) and/or that don't completely
> (want to) rely on a "smart" system to provide the service they need.
> 
> > But when it means more effort to use the encryption option, it is
> > very unlikely that he will use it. What do you think?
> Nothing more than what I have answered above.
> 
> The new public key encryption is a partial solution to that point,
> with the additional feature of encryption algorithm in archive
> headers/trailer:
> * Encrypting an archive is as simple as listing the email recipients
> we want to encrypt the archive with corresponding public keys.
> * Deciphering an archive is as simple as a clear archive (as soon as
> you have an adequate private key), no -K option to give...
> 
> But, yes, this does not answer the differential backup you underline,
> nor it address the backup/restoration to recover a disaster for
> example: you need the private key to decipher the archive...
> 
> Another point to mention and take into consideration in this
> discussion: dar/libdar is quite low level tool not targeted to people
> that need to relying on a smart system... However,
> it can serve other tool that provide this high level intelligence of
> what user need without user expressing any request...
> 
> The "philosophy" of dar/libdar is a tool with logical default values
> and systematic explicit options, no guessing, no "intelligence" in
> order to preserve user freedom to use or activate the features they want.
> 
> By opposition, maybe you have been using MS Word. What annoying it is
> to have it capitalizing a word automatically because it "thinks" that
> it has to be capitalized... But if it was not the case, it gives you
> additional work to correct what has been changed without you having
> been asked, and lead you to become more vigilant for that it does not
> modify what follows an 'E' to an exponent and so on... My point of
> view with such "intelligent" tool is that I am not that stupid, I know
> how to type an uppercase or an lowercase... let me assume my mistakes
> and keep my freedom of writing the way I want.
> 
> In short, too much or badly designed "intelligence" in software may
> become more painful than helpful.
> 
> As you see, I just want to avoid that with dar/libdar, tools relying
> on libdar are not my concern, every need has to be satisfied but at
> different levels.
> 
> In that context, yes, I am open to consider anything that could
> simplify the use of encryption within dar/libdar, or any mechanism
> that could help overlying applications on dar/libdar to provide that
> smart service to users. :)
> 
> > I would be glad about hearing other comments on this topic.
> > 
> > Regards, Tobias
> > 
> 
> Best 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