I’ve posted several times on the Jungle Disk Forums regarding the encryption done by Jungle Disk. A FAQ will be forthcoming for the website in the future, but in the mean time I thought it was worth going into more detail about how Jungle Disk encrypts your data here.
By default Jungle Disk encrypts files that are stored on S3 prior to uploading them using 256-bit AES. AES is one of the most studied and most secure ciphers available today, and 256-bit keys are the largest and most secure it supports. Jungle Disk uses a unique key for each file, and constructs the key using a HMAC that helps protect against certain attacks. Code that demonstrates how data is encrypted/decrypted is available for download on the Jungle Disk Download page under the GPL license.
You have several options for controlling your encryption key. The first option is to use your AWS Secret Key to derive the file encryption keys. This helps make the encryption as seamless as possible and protect users from losing their data due to forgetting a key, since the key can be recovered from Amazon. If you prefer, you can also specify a custom encryption key if desired. Note that if you forget your key there is no way to retrieve it or your data.
You can also change your encryption key at any time. When changing your key, only newly uploaded files are encrypted with the new key. Existing files are not re-encrypted, as that would require downloading and reuploading all of them. To enable you to access files encrypted with other keys, Jungle Disk allows you to specify a list of previous decryption keys to use. Jungle Disk adds a special metadata header to each file when it is uploaded. The header contains a salt value and a one-way hash of the salted key. This allows Jungle Disk to determine the correct key to use to decrypt the file. Note that without the decryption keys the header is of no use, and you cannot even tell which files are encrypted with which keys unless you possess the keys.
Finally, a few words on things that are not encrypted. Files cached locally on your machine by Jungle Disk are not encrypted. Since they are accessible to any local user already via WebDAV, encrypting them on disk doesn’t make sense and adds unnecessary overhead. A menu option is available that allows you to clear your cache contents at any time. File names and paths are encoded, but not encrypted. However, if you enable SSL, they will be encrypted while “over the wire” between your machine and the Amazon data center.
8 Comments
RSS feed for comments on this post · TrackBack URI
Subscribe to our feed
James Manger said,
August 7, 2006 @ 8:34 pm
RC4 can provide confidentiality, but what about integrity?
Do you include any integrity checks in the data that is stored in S3? Perhaps an HMAC over the ciphertext.
Jungle Dave said,
August 12, 2006 @ 5:35 pm
Amazon provides automatic MD5 hashing over the encrypted message bodies, which Jungle Disk can compare to ensure the file was transmitted correctly.
James Manger said,
August 22, 2006 @ 3:31 am
An MD5 HTTP header protects the integrity when you upload a file to S3 as the MD5 hash is included in the S3 signature. I don’t think it helps when you retrieve a file, however. An MD5 header does not prevent Amazon (or anyone else seeing the returning ciphertext) from changing the ciphertext AND changing the MD5 hash to match. JungleDisk would accept the changed file with who knows what consequences for the user.
James Manger said,
August 26, 2006 @ 4:31 am
If you completely trust Amazon, why bother encrypting the files at all (particularly as I think you can communicate securely with S3 via HTTPS).
If, on the other hand, you trust S3 to provide reliable storage, but recognise that Amazon may at some point have a disgruntled sys admin, or might be hacked, or a bad guy might be sitting in the communications path between you and S3… then you protect the data you put on S3.
The “worse case” is not a corrupted file. Much worse would be getting malware (eg a virus) when you recover a file from S3. If you don’t put a keyed integrity check on the data you cannot be sure what you are getting back. Encryption might seem to help but, in fact, it doesn’t.
Anyone seeing Jungle Disk data can look for, say, a known exe (eg notepad.exe) as file names and sizes are not encrypted. Knowing the ciphertext, the plaintext (its a known exe) and having some malware would allow a baddy to replace the ciphertext with (ciphertext XOR plaintext XOR malware). While replacing the ciphertext (in S3 or in transit) the baddy can replace its MD5 hash as well. Jungle Disk will happily download and decrypt the altered ciphertext — putting malware on the user’s computer.
Encryption without a (keyed) integrity check is almost always worthless.
P.S. As separate question, does Jungle Disk use HTTPS?
Jungle Dave said,
August 26, 2006 @ 8:05 am
The encryption in Jungle Disk is primarily a privacy measure, not an integrity check. It is meant to protect the data both in transit and when stored on Amazon’s servers.
Adding an additional integrity check would be useful for the scenario you describe, and we’ll consider it for a future version.
Peter said,
June 5, 2009 @ 2:08 am
You can’t just XOR an AES encrypted file to handily get a new encrypted file of your choice.
Ron said,
June 22, 2009 @ 7:21 pm
Does anyone out there know of an independent third-party confirmation that JungleDisk backups are encrypted as advertised?
Thanks!
Ron
Jungle Dave said,
June 22, 2009 @ 9:19 pm
We’ve released code (available on the download page) that demonstrates the encryption, which quite a few folks have looked at.