Re: dar encryption - RSA

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

Le 07/10/2014 17:41, Tobias Specht wrote:
> Hi Denis,

Hi Tobias,

> 
> maybe I was not that exactly about what I want to hash and how the 
> dictionary is organized: * I don't want to hash the content of the
> file
This I understood,

> * the dictionary is not organized hierarchical as your catalogue
> is
this is didn't but OK, that does not change much the picture and makes
sens to avoid exposing the directory tree structure.

> * when I'm talking about filename I mean path + file name
OK,

> * the dictionary does not replace the catalogue, it is just an
> extra option
I understood that the dictionary was stored in clear text beside the
catalogue which would stay encrypted.


> It should look like this: { H("/home/tobias/Documents/test.txt" +
> inodeID + mtime + UUID + salt) : [userID, groupID, perm, file_size,
> is_dir, type, flags, ctime] ,
> 
> H("/home/tobias/Pictures/foo.jpg" + inodeID + mtime + UUID + salt)
> : [userID, groupID, perm, file_size, is_dir, type, flags, ctime] , 
> ... } (H() is a cryptographic hash function like sha256)
> 
> respectively: { 
> b2144d23ebc9a7f2af44e215b00dce5025bdc227346c6459b989ef8d203f3402 : 
> [userID, groupID, perm, file_size, is_dir, type, flags, ctime] ,
> 
> 0df9ba289c76d5bb1761a2764593bfe97d64f4c944ecfa08d6f7a16721b5f317 : 
> [userID, groupID, perm, file_size, is_dir, type, flags, ctime] , }
> 
> 
> In this scenario the only possibility for a collision to occur is
> inside the hash function, which is very unlikely to happen: 
> http://stackoverflow.com/questions/4014090/is-it-safe-to-ignore-the-possibility-of-sha-collisions-in-practice/4014407#4014407
>
> 
=> In my opinion the possibility of a hash collision can be ignored.

I admit the probability is very low, but this has to be documented at
least for the user to know the risk, as low at it can be.

> 
>> 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.
> Yes, that's right. But this is not only because of the uuid it's
> also because I want to use the inode number, which will be
> different after the restore also.
Yes, that's correct. I just wonder why adding the inodeID and UUID?
Would just salt not be sufficient to randomize the data to hash? By
the way, I suspect there would be a different salt value per hash?
Would the salt for each entry be stored in clear beside the
corresponding hash? No offense, my cryptographic knowledge is quite
basic! :)

> In this case the user has to enter the encryption password to use
> the encrypted catalogue as reference or a full backup will be
> created. I think this restriction is acceptable.
It is for me too. As you say, there is the catalogue for that situation.

> 
> Of course I can use the same password for all backups of one system
> and requesting the user only once to enter it (this can be done
> without modifying dar, just by using libdar) but that's not the
> point.
> 
> I admit the dictionary is not that easy to implement and it will
> require changes on the archive format as well but I think it can be
> quite handy for a lot of users who want to encrypt there backups.
The archive format is flexible, so that's not a problem to add a new
fields. The point concerns more the algorithme of differential backup
(filtre.cpp: the filtre_sauvegarde() routine) It should be able to
handle hashes in place of filename while also performing file
comparison on filename (for normal differential backup).

Another point to consider is the algorithm complexity (I mean the time
to execute the requested task). Actually when doing a differential
backup, each file from the filesystem under backup first search in the
reference catalogue, but only in the directory it is located in. Here,
due to the hash on the whole path+filename, each new file to consider
for backup has to be hashed and this hash has to be compared more
widely to the whole archive hash base. Of course having a sorted list
of hashes (like it is for filename in each directory) leads to a
faster search (binary search) but it remains that the execution time
will increase with number of files in the archive. I guess, this hash
lookup is not the biggest CPU consuming task in libdar (comparing with
data compression or encryption), but that's however a scalability issue.

I think I now get the picture of your request/idea. This is a
reasonable compromise, while it is not a simple feature to
implement... :-/

I add it to the Feature Request list on sourceforge.
https://sourceforge.net/p/dar/feature-requests/173/

I can't promise I will have time to implement it for release 2.5.0,
the next major release I would like to finish developping this year
for a release first semester 2015. I'm taking more time than expected
testing the current feature (multi-threaded libdar), while performance
benefit is not much visible for now... well I have not yet tuned it
all, first have to make it work as expected. So I can't promise but I
will try to.


> 
> Regards, Tobias
> 
> 

Regards,
Denis.


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

iQIVAwUBVDQ+bggxsL0D2LGCAQJCdw/9FTzQQ/Z4sTqXThPo7Uy6V4GH8xnK/fi+
wcE3hCCU66HDFXjFmPoYYTNyxyIfPXmWHu8/yuLJJ63yI0S30KQcmu650uhJyx66
ql1DLTYLvbnfrF/U430fqCWuQvbYTOr5eyC6wr//VoG/SrwM6LoV3afGgV8NXOwZ
0xpfpEAU0F41s43srxbPTFxH+sSL0AicGUWeLzbw3qTB7o7URho8cjPDXjf1EAZ3
r3vP3s5//nmAsggXSkf1YczepZ65fY8oZsWSRNUb8q78fpR19hQuFAUa1+8b1W/I
hFVUSJdQ/c5BF3pJfi/OBFLfA/NmlDL3XnzQ/2XSK52xGEFMSNZ/ix5gSDZHHKW4
4XqYI9fKAZWDwG6XLOKoGb3POhyrluaBEgHCrzFTgczm0cFvFhmhrI6i7PG94055
fGm9fGRBBFW1LV6ogtt5wkLZ2HP34MoQ3g1ErumTGkmC4gnR5JDZZPA5gcOke4c8
UxewRvkdLaZoAih78hHkERf5SEsD64HZ974FYGijnqss0qB4aiqffovueFLZ33vy
EowQ88zlYMmDBXnDMB+6p92e2N60zhwF4mSbIFxDq33CfOb3H/ELNILX1gooruEd
mMUtjLejzLb8jV39CpcSdZ+Op5b6lZcAB4ADAcJImi5vWjmARN1LJwDMjB/mU24p
o2vsGfRt8Rc=
=9o5O
-----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