Snapshot - Encryption Details

Back to Backup

Setting a default password

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.

Remember your Password

        If you forget your password, there's no way to recover it; you might as well delete your backup in such a case.

Setting the password from the command line

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.
If you have a default, but nevertheless want your image unencrypted, you have to indicate an empty password:

        C:>Snapshot C: X:\Backup\c-drive.sna -PW=

En/Decryption Speed:

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.

Implementation details

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.

Big problem - and how we think we solved it

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.

What the hell is 'AES'

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


Back to Backup

Copyright 2001-2021     Tom Ehlert Software