Re: dar encryption - RSA

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/10/2014 18:04, Tobias Specht wrote:
> Hi Denis,

Hi Tobias,

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

more or less yes, but that's a matter of details,

> I think the most private information that has to be protected is
> the filename.

A agree with that.

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

For this first idea, there is already a point to consider put aside
the brute-force attack. If two different files in the same directory
with different filenames provide the same hash, there is a conflict.
While this should not occur very often but it is not impossible.

Same problem during the differential backup process, dar checks
whether each file found on the filesystem does not already exist in
the reference catalogue. Here, in order to compare, dar  has to create
a hash for each filename read from the filesystem and compare that
with the list of hash available in reference catalogue. But a false
match may occur, if a new files have the same hash as an old one. Most
of the time, dar will save that new file as expected if mtime or other
attribute changed comparing with wrong reference, but in some rare
cases it may fail to be saved that new file assuming it has not
changed comparing it to a wrong reference.

So, even if chance are little that this situation occur, they is not
impossible. How to cope with that? Have we to inform the user that
there is a risk that the backup is not perfect, but not to worry this
is occurs in very rare situation? Would you find that acceptable as
user? :)

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

right, that's better, only comparing the hash will let dar know
whether a file has to be saved again or not (put aside the hash
conflict mentioned above).

> And in this case the whole file would be saved anyway.

Right.

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

OK, this let dar see if only EA/FSA have changed and resave this part
only if necessary.

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

In fact, adding system/hardware ID in the hash forbids the possibility
to restore the whole data (most probably on a new filesystem, due to a
crash for example), and keep using the latest backup of reference as
reference for the next incremental backup.

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

That's an interesting approach. however it is not that simple to
implement. However there is the point about hash collision to address.

I thought about another way, to do encrypted differential backups that
has the same footprint as doing a full backup for the user point of
view: using the same key (symmetrical or asymmetrical) for the archive
of reference and the new differential backup, without having dar
asking twice for the password as it does for full backup.

Given the encryption key, dar tries to open the encrypted isolated
catalogue, if it succeeds, it assumes the user gave the key without
typo error and use that key to encrypt the new differential backup.

I guess that when you use symmetrical key, very few use different keys
for each new differential archive, right? I also guess, when using
asymmetrical encryption, this is always the same public/private key
pair that is used, thus the same passphrase is requested to open
private key (enciphering and signature).

Whould this address your need? This is much more easy to implement to
my point of view.

> 
> Regards, Tobias
> 

Regards,
Denis.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIVAwUBVDEfkAgxsL0D2LGCAQJQIhAAp5cRrn5LZ+usAarnAuxtJNjuAunGFLGD
stbQIWXvlTOFfwR0Y6Ef5P6YHNNdLYamXv7UVZFaDugBgY0X6ckIVKxVepySWJcZ
JOx0un3/xCy0LysPjZ5g4WR9Tyfs72sjTHehGOgEZwfnFX0bxWY2GYrsb8AIpzjk
+AcullD99R41NOTMA1ByBmr1RY7/5ScFMubg+pu/kT1RnGdE8w/Fd0XW+fgnZnEl
NtqiQ7CRYH78EfR1RZFrTw/PDCxajYNUgeDNHR93/egE8jiPNxEoxBjSvfgq6eLt
PTINJzkHUgFJMOBDDXehaII59V+L6rXziPm0cx3511Lo3ZvoemF4b9Pj+p1R8zjg
3RS6jbcWPNiA+c5wFfB8Hm5KNHwplXWAOB8E+kNoJ2SFOZEbxm3obSRmA/hUrgBx
PSuViCOjnmxBJKb00d2bCf791AqUfmg7zAtFfNe7Wea3Sk6QoaAvliRtrepr6aSg
2VU1oG5kenNL2QVQ2QVVRV8g5Kb+3t4Lap734Q80R/fr5CtKPTIHBCkngYz+Qp9d
W3ukegYd28fAWwqxS21ygLO6Z/YoQJ1CZIn2HwecxfTbAdzUCsIl5aFmmK5L+cPN
a38uUhk6A9UtOJa7A3bX260/Ebkj+2hCv7WV1QAbBcXocneg7T03RDVMLoSZFNJv
zTLEfVP7KY4=
=c67x
-----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