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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
