http://sourceforge.net/forum/forum.php?thread_id=2648774&forum_id=587585

2) About encryption : 

Areca uses AES128 & 256 (if supported by your VM). TripleDES is deprecated
(and its support will be completely removed in the next version of Areca). 

The encryption key can be : 
* Either a "raw" list of bytes entered by the user in an hexadecimal form ("RAW" mode),
which will be used without any modification by Areca. In this configuration, the user
is totally free and can use any key derivation algorithm to generate his key.

* Either a passphrase entered by the user ("HASH" mode), which will be processed by a
hash algorithm to derive the encryption key. No salt is added.  

I've read your comments about the possibilities of "rainbow attacks", and i agree :
if the user's passphrase is weak, his archives will be vulnerable to dictionnary attacks
in general (but his archives will be safe if he used a sophisticated enough passphrase).
That's why encryption will be modified in version 6.1 (coming next week) : 
instead of simple hash algorithms, PBKDF2 will be used to derive the encryption key.
The number of iterations (about 100000) will be configurable in Areca's properties file
(so the value can be modified by the system administrator). In addition, a "static" salt
will be added : this "salt" will be configurable in Areca's properties file, but it will
be the same for every target. I'm aware that this salting method is not the best (it would
be better to integrate dynamic salt - for instance by derivating the salt from the target's
properties - or a random salt - stored somewhere on the system) but it adds some complexity
and uncertainty for the attacker. 
 
3) About key management : 
This has been already discussed in the forum, and there is a dedicated paragraph in 
Areca's user manual (see http://areca.sourceforge.net/documentation.php#tocHelp23). 
The default use case for encryption is as follows : 
* The user runs Areca on his own computer, to backup local files 
* The archives are stored at a remote location (using ftp or other protocols) which
can be accessed by untrusted users (for instance the system administrator of the 
remote computer) 
 
That's why the encryption key is stored in the target's configuration (which stays on
the local computer) : i assume that the local computer is protected against unauthorized
accesses (which is the responsability of the user), and that only the remote archives
have to be protected against unauthorized accesses. 
 
Best regards,
Olivier PETRUCCI 2008-12-06