Slashdot Mirror

Unfortunately, Solitaire is known to be weak, although it's certainly a fair amount better than anything else you can do by hand.

Realistically something like doing all of your work on an air-gapped computer and keeping the actual data on a micro-SD card that you normally keep hidden away somewhere is probably the best way to protect against this type of attack.

The only way we could have true randomness is if there are some sort of measurable phenomena that cannot be predicted. Quantum mechanics dances around this question, and even if there is a state change that is genuinely random, it would be difficult bordering on heroic to measure it in a practical way so as to create a random number generator.

Actually, there are many commercial devices that use quantum effects to generate sequences of numbers that are unpredictable even in theory. Or, if you're careful about it, you can even use a simple Geiger counter to generate truly random data.

Do you have any information on the break? I just did some searching and couldn't find anything about it. At the bottom of Bruce Schneier's page on Solitaire there is a link to an article Problems with Bruce Schneier's "Solitaire" by Paul Crowley, but it's dead. Is this what you're referring to?

(The article does exist in the Internet Archive at
http://web.archive.org/web/20050206214237/http://w ww.ciphergoth.org/crypto/solitaire/
It does describe what sound like they might be some problems with the randomness of the keystream, but it doesn't seem like a complete break. Sorry for pasting the address, but Slashdot doesn't seem to like IA links much.)

Anyway, I'd be curious in knowing what the problems with it are.

For more information concerning the solitaire encryption algorithm, see either http://www.schneier.com/solitaire.html or read Cryptonomicon.

To see all of the problems concerning the solitaire algorithm, see http://www.ciphergoth.org/crypto/solitaire/

"Bruce Schneier invented a crypto system based on playing cards for the novel."

Ah, yes, Solitaire. Not that I really believe you're going to use it, but FYI, it's broken.

It's not by chance, either. Paul Crowley, the guy who broke Solitaire, also tried to invent a strong manual encryption algorithm and failed.

Not that I'm in the league of those guys, but I've been working on the problem myself and it's not easy.

Thanks! I think the Halevi and Rogaway paper was the one I was referring to - the other stuff is new to me.

Where the problem is using sector encryption to protect data on a stolen drive, I'm assuming the simple solution is a secure seekable stream cipher. SEAL provides one, but it's patented. A block cipher in CTR mode does a good job, except as you say that if you use a 64-bit block cipher then after about 2^35 bytes you can distinguish it from a random stream by the absence of collisions. But a 128-bit cipher should be good for about 2^68 blocks, which is plenty. Salsa20 might turn out to be a tempting choice - it doesn't have the problems you refer to. This option isn't affected by chosen-plaintext attacks.

I'm assuming that the disk is encrypted with a randomly-generated key, and that this key in turn is encrypted with the passphrase. This was the strategy used by SFS.

My paper on my (broken) large-block cipher Mercy includes a discussion of some of these issues.

I'll follow the other references you give - thanks again!

You might be interested to look at the crypto content on my website.

http://www.ciphergoth.org/crypto/

Your picture of the history of crypto is a little weird. I recommend Steven Levy's "Crypto" for a clearer idea. Sadly he doesn't cover the AES process, but it's a fun read all the same. If you decide you want to understand the topic in more depth, "Handbook of Applied Cryptography" is a good direction to go next. Wikipedia's cover of crypto is sadly quite patchy; I've tried to address it in places, and clear up egregious errors, but it's a big job.

Also, factoring primes is pretty straightforward. It's the composite numbers that give us the trouble.

And here are some strategies that will safely give more bits:
http://www.ciphergoth.org/software/unbiasing/

Correcting for the increase in decay is practically impossible; use a long-lived source.