Comments on: Jungle Disk Encryption http://blog.jungledisk.com/2006/06/06/encryption/ Reliable online storage powered by Amazon S3 Sun, 07 Sep 2008 18:43:48 +0000 http://wordpress.org/?v=2.3.1 By: Jungle Dave http://blog.jungledisk.com/2006/06/06/encryption/#comment-27 Jungle Dave Sat, 26 Aug 2006 15:05:44 +0000 http://blog.jungledisk.com/2006/06/06/encryption/#comment-27 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. 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.

]]> By: James Manger http://blog.jungledisk.com/2006/06/06/encryption/#comment-26 James Manger Sat, 26 Aug 2006 11:31:41 +0000 http://blog.jungledisk.com/2006/06/06/encryption/#comment-26 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? 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?

]]> By: James Manger http://blog.jungledisk.com/2006/06/06/encryption/#comment-25 James Manger Tue, 22 Aug 2006 10:31:45 +0000 http://blog.jungledisk.com/2006/06/06/encryption/#comment-25 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. 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.

]]> By: Jungle Dave http://blog.jungledisk.com/2006/06/06/encryption/#comment-24 Jungle Dave Sun, 13 Aug 2006 00:35:58 +0000 http://blog.jungledisk.com/2006/06/06/encryption/#comment-24 Amazon provides automatic MD5 hashing over the encrypted message bodies, which Jungle Disk can compare to ensure the file was transmitted correctly. Amazon provides automatic MD5 hashing over the encrypted message bodies, which Jungle Disk can compare to ensure the file was transmitted correctly.

]]> By: James Manger http://blog.jungledisk.com/2006/06/06/encryption/#comment-23 James Manger Tue, 08 Aug 2006 03:34:59 +0000 http://blog.jungledisk.com/2006/06/06/encryption/#comment-23 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. 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.

]]>