Maybe common disk encryption is so compromised, there's no point to implementing?

David Brown davidb at
Sun May 4 09:09:53 PDT 2014

On Sun, May 04, 2014 at 01:22:25AM -0700, Tony Su wrote:

>First, my use of the term "plain text" is not some option vs some other
>"more secure" method of storage or transport. I'm saying that in this
>special case the secret <must> be easily readable (certainly not encrypted,
>likely not obfuscated) to be able to do the string comparison to do any
>kind of authentication including full disk encryption.

Others seem to also be trying to say this, but there is no string
comparison.  In fact, disk encryption has nothing to do with
authentication at all.

However, the secret indeed does have to be kept in RAM, since it is
needed to encrypt/decrypt every that is written or read.  So yes, it
is quite vulnerable to possession of an "on" machine.

I would also guess that, by default, suspend, both to disk and to ram
would keep that secret.  It'd be pretty obvious if it didn't, since
you'd have to enter the password in upon waking up.  I'd be a little
concerned about hibernate, since, unless it is implemented more
carefully, the secret would then be written to disk.

Now, the "access to on machine" can be partially mitigated with
something like TPM.  In this case, the secret is never kept in the
computers accessible RAM.  The encryption and decryption happen
elsewhere.  But, even then, if the system is running, whatever
mechanism that asks TPM to do the decryption can also be asked to
decrypt other parts of the disc.

>If you believe
>otherwise, I'd like to hear how that can be proposed. Unless someone can
>describe how this isn't so, the "secret" is laid bare in memory because it
>has to be that way, not because "the passphrase was chosen improperly." The
>problem isn't the strength of the passphrase but that the passphrase must
>be exposed to perform authentication. It's not a matter of strength of
>encryption, it's purely a matter of locating the relevant string of
>characters in the gigabytes of characters that comprise a typical memory
>dump. Strength of encryption is totally irrelevant if the hacker is going
>in a side or back door.

Yes, if you have access to memory of the machine while encryption is
mounted, you have a much smaller keysearch space, probably one that
can be done.  As far as I can tell, the claims the company you quote
are making seem about right.

But, please stop using the word "authentication".  Disk encryption has
nothing to do with authentication.

Now, locating the relevant string isn't as easy as you might think.
If you understand how things are stored in the kernel, it's probably
not that hard to find, but even a search of every consecutive sequence
of 32 bytes (whatever the key size is) is much smaller than every
possible 128-bit sequence.

Keep in mind that the password the user types is not the encryption
key used for the data.  Generally, the real keys are generated
randomly, and then encrypted with the user's password.  The user's
password is only kept in RAM long enough to get to the real key.  But,
yes, again, that key does have to be kept in RAM for the OS to be able
to encrypt/decrypt data.

A simple way to greatly improve the security of a laptop with disk
encryption is to not sleep it, but actually shut it down.


More information about the KPLUG-List mailing list