There’s a fascinating debate going on at present. Two ‘researchers’, called Abed and Adonis, are trumpeting their mad sk177z at cryptography.
They have a few basic claims:
It’s an interesting read, and full of the sort of lack of comprehension, poor language, loose terminology, etc, that is typical of some of the worst kind of vulnerability reporting. I’ve read a couple of dozen vulnerability reports, and while a couple of them were clear, concise and well-researched, the majority were barely understandable, and showed a staggering lack of comprehension of the software and algorithms being discussed.
When you want to decrypt a file, here’s what happens:
What Adonis and Abed have managed to do with their fancy debugging on the SDA (self-decrypting archive) is to break into the point where the code checks that the random key has been successfully decrypted, and change the stored checksum to match the checksum of the key they’ve decrypted using the wrong pass-phrase. So, they’ve got a key that doesn’t decrypt the file to the correct data, and they’ve managed to persuade the program to tell them that this is acceptable.
<sarcasm>Clever attackers – they’ve managed to get the system to tell them that they’ve successfully decrypted the file, while at the same time getting back a key that ‘decrypts’ the file to random garbage.</sarcasm> They even acknowledge it in one of their Flash animations. [Oh yeah, and I want to view a Flash animation less than a month after a remote code execution vulnerability in Flash.]
Their binary patching of the PGP encrypted disk is slightly more interesting.
What they have demonstrated is that a change of pass-phrase does not change the random key, it just decrypts it using the old pass-phrase, and then re-encrypts it with the new pass-phrase, obliterating the stored copy with the new one. [This is actually a good and necessary thing, because if you’re on the road, and you change your pass-phrase to something that you then forget, you want the recovery token that the help-desk provides you to still work!]
This can be used to gain some measure of an attack – encrypt the drive with a pass-phrase you know, save a copy of the encrypted key blob, and you can later come in and replace the encrypted key-blob on the machine with yours – this effectively resets the pass-phrase to what it was when you saved your copy of the encrypted key-blob.
But that’s not something that the encryption is designed to protect against – and really, it’s not something that the encryption should try to protect against. If you receive an encrypted device from someone you don’t trust (or later decide not to trust someone who has encrypted a device you use), you should decrypt it and re-encrypt it with a new random key. This makes good sense anyway, because you want a new recovery token on the device, and you want that token to be under your name, not the previous user’s name.
As with so many presumed attacks on cryptographic solutions, this one’s a real yawner if you understand the cryptography at hand, because it’s really an attack on the policy behind the system. In this case, the policy says that if you receive a device (disk, encrypted file, whatever) from someone who possessed the means to decrypt it, that device can continue to be decrypted until such time as you encrypt it with a new encryption key – not just a new pass-phrase.