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>
