[ AI Lists: ]

* ACL
* Extended attributes
* Good-enough encryption
* Password and key management

We filled a bug to the community, we would like to find out if they need a
contribution agreement to accept our changes.
http://sourceforge.net/tracker/index.php?func=detail&aid=2232982&group_id=171505&atid=858191


[ LSARC review Comments: ]

Alan.Coopersmith@Sun.COM
=====================
> 	/usr/share/areca/lib/swt.jar

Q0) Why isn't this using the shared swt delivered by LSARC/2008/462
instead of its own private copy?
A0] That's great, if we could share this library. Contact with the owner of
swt LSARC, we should add dependency to SUNWswt packages.

Darren.Moffat@Sun.COM
=====================
Q1) What modes of the encryption algorithms are used ?

A1] By looking at the source code of areca. It is using javax.crypto.*
which means JCE.

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


Darren.Moffat@Sun.COM
=====================
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"
=====================

Q2) So how is key management done ?
Q3) Where are they keys stored and generated ?
A2|3] By searching the code... look like ...
    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.

Darren.Moffat@Sun.COM
=====================
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.
=====================
Q4) 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.
A4] JCE (Java Cryptographic Extension) framework.
    http://java.sun.com/javase/6/docs/api/javax/crypto/Cipher.html


Darren.Moffat@Sun.COM
=====================
>        * Files permissions and symbolic links backup. (Linux only)
=====================
Q5) Why is this Linux only ?
A6] 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).
    And, looking through his code in FileSystemManager.java
        if (! file.exists()) {
            return false;
        } else {
            return ! getAbsolutePath(file).equals(getCanonicalPath(file));
        }
    If the java code is compatible with Solaris/Linux/Windows/OS2 or
    any other systems. It should support Soarlis as well. 

    I have tested the Areca, it works.

Darren.Moffat@Sun.COM
=====================
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.
=====================
Q6) Does this work with NDMP ?
A6] By searching the following wiki and looking through his code. There is
no NDMP staff. NDMP was co-invented by NetAPP and EMC. Maybe, we could ask
the author to support that in the future? However, the Q10 in ndmp.org tell
us there is a NDMPcopy tool.
    http://en.wikipedia.org/wiki/NDMP
    http://www.ndmp.org/info/faq.shtml