Areca Backup [LSARC/2008/681 Self Review]

[Darren J Moffat]

Mark Carlson wrote:

> I am sponsoring this case for David Zhang. I have marked it closed approved automatic based on the checklist in the case directory.

I don't believe this qualifies as closed approved automatic please set a 
timer.

> 	It is released under the General Public License Version2 (GPLv2).
> 
> 	Backup Engine Features :
> 	* Archives compression (Zip & Zip64 format)
> 	* Archives encryption (Triple DES & AES encryption algorithm)

What modes of the encryption algorithms are used ?

The mode of a crypto algorithm is important, some include an integrity 
check but most require the use of a separate keyed message digest (such 
as HMAC-SHA256) to protect against cipher text modification. For example 
AES_CBC mode is not sufficient to protect against cipher text 
modification for large amounts of data.  A mode like AES_CCM or AES_GCM 
is better since they include a MAC but they expand the size of each 
output ciphertext block (between 4 and 16 bytes).  The are other modes 
like XTS that are non expanding.



This quote from the FAQ concerns me deeply: "As this encryption key is 
stored in the backup target, you will never be prompted for it again : 
Areca will transparently use it to encrypt / decrypt these archives"

So how is key management done ?
Where are they keys stored and generated ?

There is information in the answer to "[Q] What is the difference in the 
XML configuration file between AES and AES_HASH (or DESEde and 
DESEde_HASH) ?" that makes me very concerned.

The method described there for generating a key from a passphrase is NOT 
secure and is subject to rainbow table attacks since the hash (MD5) of 
the password does not appear to be salted - this hasn't actually fixed 
the problem they appear to think it has.


What crypto library is used ?  I assume since Areca is written in Java 
it is just using the JCE but I'd like this confirmed.


 >    	* Files permissions and symbolic links backup. (Linux only)

Why is this Linux only ?
To me this is not acceptable, this makes it totally useless for Solaris 
backup if it can't do a simple thing like this.

What about ACLs on UFS and ZFS ?
What about extended attribute files (ZFS and UFS) ?
What about system attribute files (ZFS only) ?

For this to be included in Solaris it needs to be actually useful as a 
Backup program that means it needs to be able to actually backup the 
content we can create on Solaris without loss.  Without support for file 
permissions, links, ACLs and extended attributes I can not approve of 
this case being integrated into Solaris - particularly since the bundled 
tar & cpio archivers already support that.

Does this work with NDMP ?

-- 
Darren J Moffat