Re: How to protect an encrypted file system for off-line attack?
On Fri, Feb 27, 2009 at 08:34:25AM EST, Jochen Schulz wrote:
> Chris Jones:
> > I have a naive question.
> >
> > While your brute force decryption is running, how do you determine
> > you have found the "one key" and decide it's time to stop?
> This is a valid question! Depending on the encryption system in use,
> it cannot be answered satisfactorily.
I'm not sure it's related to the encryption/decryption process.
What I had in mind when I wrote the above was that with the immense
volumes of output generated, having a crowd of quick-eyed folks look at
it one individual dose at a time to determine the likelihood of its
being the correct "solution" in a timely fashion is not practical.
Or, in other words, you need not only the decryption but also the
analysis of its results be performed by some computer cloud, with at
least comparable processing power to that of your decrypting machine.
And as I undestand it, this would mean that you need another piece of
software in your setup, one that can mimic our form of intelligence well
enough to distinguish favorites from also-rans.
The bottom-line, as I imagine it, would be that the source data contains
some regularities that are trivial to identify.
When entire file systems are encrypted, this would appear to be a fairly
simple task. My guess is that on OSS systems such as linux, you would
just about need to look for the first 8 butes of the FSF manifesto and
be done.
When dealing with individual files, I have a feeling you would need to
distinguish between those where the actual data is encapsulated in some
kind of file "format" .. while the data is totally variable there are I
would imagine regularities in the "capsule", and consenquently, cracking
that type of encrypted input and deciding you have found what you are
looking for should not be too difficult. And then there are simple text
files and these are different in essence, because they only contain the
data and nothing else and for all we know this data might be written in
some rare forgotten language the craker team have not knowledge of.. or
(worst case scenario) might even be perfect garbage to look at - such as
a truly random sequence of bits .. in the event what is being decrypted
happens to be a computer-generated key that was used to encrypt other
data elsewhere for instance.
To clarify, and hoping this is a valid example .. should my PIN be
"12345" .. even should the cracker know it is a PIN he is decrypting..
and therefore that it should only comprise digits.. because the bank's
keypad will accept nothing else.. will the decryption process come up
with millions of five-byte combinations that can easily be discarded
because they contain at least one byte that is not the in the 0-9
range.. and only one "valid" solution.. or will there be hundreds of
false positives such as "54321" that will have made all the time and
effort of the decryption less useful than taking a shot at guessing my
favorite 5-digit combinations and entering them tentatively on the ATM's
keypad?
> If a one-time pad is in use where the key is as long as the encrypted
> document, it cannot be answered at all.
Don't take my word for it, but I believe it one-time pads .. as their
name implies need to be unique to the document to make it impossible to
decrypt. Otherwise you start introducing regularities.
> Even if one key reveals a "good looking" plaintext, the attacker has
> no way to know whether this plaintext is the right one because other
> keys lead to other valid looking plaintext.
Keeping in mind that what you (the cracker, I mean..) are looking for
might not be plain text in the first place.
> So in this regard, one-time pads are the "perfect" encryption system.
> But unfortunately, it is not feasible to use it for hard disk
> encryption, since nobody is able to remember a passphrase of several
> gigabytes. :)
I guess you could devise some complementary hardware support to your HD
that would hold all the one-time pads and Mission Impossible style
destroy itself within seconds in case of an emergency.. but I have a
feeling that the encryption of an entire file system is more something
that's meant to protect you from unsophisticated prying without making
your existence miserable but that it was never meant to address the
security of strategic files and truly sensitive data.
Thanks for your comments.
CJ
Reply to: