Drive Snapshot lets you store a default password for encryption and decryption in the registry. The passwords will always be used when creating (encrypting) or using (decrypting) disk images; they are stored at HKCU\software\snapshot\DefaultEncPassword and HKCU\software\snapshot\DefaultDecPassword.
The encryption password is converted to a public key which is used for encryption. Storing the encrytion password is safe and no security risk.
The default encryption password can be set with the option --DefaultEncPWD=SuperSecret
The decrytion password will be stored encrypted in the registry. Although this presents some security risk, it's very convenient compared to always re-entering the password when using disk images.
Although it's stored in encrypted form , there's always the risk to disassemble Snapshot.exe
and retrieve the decryption password.
The default decryption password can be set with the option --DefaultDecPWD=SuperSecret
Even if you don't store your password permanently, it is remembered until you
close Drive Snapshot; e.g.
for creating multiple partition Backups.
If you
forget your password, there's no way to recover it; you might as well delete your
backup in such a case.
From the command line, you can set the encryption password with -PW=
C:>Snapshot C: X:\Backup\c-drive.sna -PW=SuperSecret
This overrides a default password.
If you don't want to use a plain text password from the command line you can use the command
snapshot -pwgen=key_file.txt -PW=SuperSecret
to create a public key file. The file can be used if you want to encrypt an image with
snapshot C: X:\Backup\c-drive.sna -pwuse=key_file.txt
If you have a default password, and don't set one from the command line, the default is used.C:>Snapshot C: X:\Backup\c-drive.sna -PW=
A 1GHz machine is able to en- and decrypt data at a rate of ~30 MB/sec; the DOS restore is ~10MB/sec
This will slow down the overall backup and Restore speed by 10-20%
On CPU's supporting Intels AES instructions the slow down will be even smaller.
The used encryption (and implementation) should be 'state of the art'.
The algorithm used is AES (Rijndael) with a block and key length of 128 bits; which will be the industry standard for the next few years.
AES is used in CBC (Cipher Block Chaining) mode, to avoid some easy attacks on images, that are possible if you have a lot of cyphertext, with large portions of it known to the attacker; which is certainly the case for GB images, with all the WindowsNT OS installed.
a) Any program has to tell the user 'Wrong Password', if he mistypes it accidentally
b) If the information needed to verify the password is included in the image there must be some password verification (hash), and a potential attacker has all information in its hands to run a brute force (or dictionary) attack against a password hash
c) Even if the potential key has 256 bits, users tend to use passwords with less then 15 characters, and they look much more like 'Christmastree' or (at best) '13Christmastrees' and very seldom like '[ChRiStMaS]->[TrEeS]'; so dictionary attacks are relatively easy - and that's how Password Regain utilities work.
To prevent against brute force attacks, we make the hash generation slow: not artificially by a bad implementation, but by iterating a good implementation (the AES implementation itself) for ~0.1 seconds to generate the hash; so even if an attacker has a much faster machine than yours, he can't test millions of possible keys, but only a few hundred.
To prevent against dictionary attacks, the password is salted, using the current environment as a random number generator.
However, the salt value is stored in the image, too, readily
available to the attacker to use in his dictionary attack.
So lastly, we store only 20 bits of the password hash.
This gives you (the legitimate user) a chance of 1000000:1 that
wrong passwords are detected, and the attacker hopefully a lot of
wrong passwords (with the right hash) to try.
If you happen to enter a wrong password with the right hash, nothing bad will happen - other then you have a disk filled with garbage ;)
Comments on this (and other implementation issues) welcome.
AES is the designated new encryption standard, replacing DES.
DES (the former
standard), with a key length of 56 bits, is no longer safe against brute force
attacks.
So the NIST (National Institute of Standards and Technology) founded a 1998 competition to find AES (Advanced Encryption standard) as a Crypto standard for next the decade , which was decided in 2000, and Rijndael was selected as the standard.
For us there was no reason to select anything different as the implementation is sufficiently fast for Drive Snapshot's needs.
Without claiming to have read (and understood) everything below (some of it is really advanced math), here are some interesting links regarding AES, Rijndael, and encryption in general.
Why Rijndael
was choosen as AES
The Rijndael
Homepage and The
Theory behind of Rijndael (Hardcore Mathematics !!)
TWOFISH: another
candidate for AES, by Bruce Schneier