[EMAIL PROTECTED] wrote:
This to answer Mr Jon Callas (PGP CTO) and to show him the last
proof-of-concept. If he did not get it we consider we have done our
part to report a BIG problem in PGP unless this is some kinda of
HIDDEN features.
We do not know why they just see one side of the coin.
I don't quite see the other side. They, and several others here have
explained what is happening.
At most I can see a user interface issue here, as I will detail below:
What if you had created a virtual disk and give that to someone.
That someone use it as his/her own disk
This is unsafe, unless the disk is reencrypted.
and decided to change the password because they own the disk now
The assumption that changing the password will disallow access from
a former owner of _that_ very same disk is wrong.
You have to reencrypt the disk, if you want to take full ownership of
the data.
So they did change the passowrd, but the originator can still access
that disk if he/she replace the passphrase bytes in the binary file.
That is not even necessary. You can just save the actual encryption key
and decrypt the disk with a modified software.
So I consider this an attack on data INTEGRITY and data AVAILABILITY
Containers of this kind cannot assure this anyway.
Integrity of the file might be checkable, but what is the point in
checking the integrity of data you want to protect from an adversary
that can decrypt the data anyway?
Are you suggesting that the software should check for a modified header?
How should the software do that? Said header is perfectly valid. It is
just for another time in the disks lifecycle.
So you could only check it together with the whole disk. That would mean
hashing a few GB of data ... everytime you unmount the disk. Or at least
everytime you want to check integrity - so at least at mount time ...
And: What would that give? An attacker can easily disable such checks.
Regarding availability:
since the legitimate user will be denied access to the disk after
replacing the passphrase bytes.
How do you want to avoid that? If an attacker has write access to a
container file, he can just as well overwrite it with gibberish, thus
really denying access.
A cryptocontainer is designed to thwart illegitimate access to data.
It is not designed to protect its content against manipulation.
why you do not want to see that your password verification can be
simply bypassed,
It cannot. You can only restore a previous version of the disk key,
which was encrypted by a known password.
You could just as well simply store the disk key.
besides a reputable co. like PGP should at least put anti-debugging
tweaks,
What for? Security by obscurity?
If you use it properly, it is absolutely irrelevant, if the encryption
software is being traced.
If you cannot recover the disk key, you can't read a single thing making
sense.
You are _not_ bypassing any authentication with your trick. You are
only using you previous knowledge about the disk key in an obscure way.
You can just as well jump ahead in the code to the point where the disk
key is there in decrypted form, replace it by the known value and run on.
No need to even enter a password actually.
or even encrypt/hide the passphrase location
It is encrypted. Let's sketch the way such programs work again:
When a container is created, a random disk key (DK) is generated. This is
what is used to actually encrypt the sectors on the disk.
When reading/writing, something along the lines of
D_S(DK,[sector ciphertext]) or E_S(DK,[sector plaintext] is used to
en/decrypt the sector, where D_S and E_S are the sector de-/encryption
functions, which often take additional state parameters (like the sector
number) to avoid some watermarking attacks etc.
As humans are very bad at remembering 256 Bit binary (or hex or base64
or ...) values, this key needs to be stored somewhere.
Unless hardware crypto tokens are in use, where can you store it?
First idea: On disk.
But: This would be ridiculously insecure.
The solution is, to store it, but encrypted. So what disk encryption
programs usually do, is to store the actual disk key somewhere in the
volume header of the container - encrypted with the passphrase the user
has to give when mounting.
Of course one could as well derive the disk key directly from the
passphrase. However that has the disadvantage of not being able to
change the passphrase easily.
Let's reiterate the workings once more:
When doing operations on the disk like reading/writing sectors, the Disk
Key DK is used like this: D/E_S(DK,[sector cipher/plaintext]).
The key DK has been randomly generated at volume creation time.
When a user mounts a crypto volume, the Disk Key needs to be determined.
This is done by entering a password/phrase. This passphrase is then used
to decrypt an encrypted version of DK.
So what is in the volume header is E_DK(K_DK(passphrase),DK) where
E_DK is an encryption function
