Areca Backup [LSARC/2008/681 Self Review]

[David Zhang]

Hi Darren,

Thank you for your kind comments.

On 11/04/08 22:14, Darren J Moffat wrote:
> 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 ?
>
It is using CBC.
> 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 ?
>
By searching the code... look like ... I need to check the source code
deeply to answer this specific question. The document of Areca has not
give us a clear answer.

public static final String KEYCONV_RAW = "RAW";
public static final String KEYCONV_HASH = "HASH";
public static final String KEYCONV_OLD = "OLD";

// Triple DES 192
registerTripleDesConfiguration(24, "DESede", KEYCONV_OLD);
registerTripleDesConfiguration(24, "DESede_HASH", KEYCONV_HASH);
registerTripleDesConfiguration(24, "DESede_RAW", KEYCONV_RAW);

// AES 128
registerAESConfiguration(16, "AES", KEYCONV_OLD);
registerAESConfiguration(16, "AES_HASH", KEYCONV_HASH);
registerAESConfiguration(16, "AES_RAW", KEYCONV_RAW);

// AES 256
registerAESConfiguration(32, "AES256_HASH", KEYCONV_HASH);
registerAESConfiguration(32, "AES256_RAW", KEYCONV_RAW);

The author is using 'final String' as the key.

> 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.
I think so. It is not so secure.
>
>
> 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.
>
By looking at the source code of areca. It is using javax.crypto.*
which means JCE (Java Cryptographic Extension) framework.

In com.application.areca.impl.EncryptionConfiguration.java
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;

And the code follows standard coding standard of javadoc
http://java.sun.com/javase/6/docs/api/javax/crypto/Cipher.html

>
> >        * Files permissions and symbolic links backup. (Linux only)
>
> Why is this Linux only ?
I think the author means (unix only), since Solaris is not as popular
as Linux today. He is just willing to support Windows and Linux, but as he
mentioned in "http://sourceforge.net/projects/areca/" project page, it is
developed with OS independent language (Java).

I have also searched code of this project, the author is using Java
common API to get file permission, user  and group message for Unix system.

> To me this is not acceptable, this makes it totally useless for 
> Solaris backup if it can't do a simple thing like this.
It is not a system wide backup tool, it could be suitable for a file or
a folder from which user want to backup his movie/file/data.
It is widely used and quite active, I usually get over 20 emails per
week from it's discussion group.
Linux people can use it to backup and restore their files and people
keep asking questions for this project.
>
> What about ACLs on UFS and ZFS ?
> What about extended attribute files (ZFS and UFS) ?
> What about system attribute files (ZFS only) ?
It's not supported, except file permission, user and group on Unix.
I think the reason is Linux platform does not have ZFS. It works well on
personal backup but may not suitable for system backup.
>
> 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 ?
It does not support NDMP.

Regards,
David


-------------- next part --------------
A non-text attachment was scrubbed...
Name: David_Zhang.vcf
Type: text/x-vcard
Size: 114 bytes
Desc: not available
URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081105/b1bf42be/attachment.vcf>