Hi James, On Tue, Oct 10, 2006 at 08:39:07PM +0100, James Westby wrote: > 1) Make a game that involves typing, > > I was reminded of a game called Daley Thompson's Decathlon, which > involved bashng two keys in turn as quickly as possible, while this > wouldn't be good I thought some sort of game might be. Bear with mw > while I outline an idea, > > Implement tetris (hmm, I'm not really volunteering for this bit.) > then the user is making key presses, and is more happy to spend the > time. The progress bar could be inverted to count down, then it is > score as many points as possible before it runs out. > > Yeah it's probably not workable, but I thought it was quite fun anyway.
I like the idea a lot. In fact, this was my first approach before cdebconf-entropy. :-) I actually started to implement "EntroPong" (classic pong) in newt; I should still have the sources somewhere. I got a bit discouraged because it turned out that the amount of entropy contributed to the kernel pool was very low. IIRC (should check) what contributes entropy are the inter-keypress timings, not the actual keys pressed, so the concept of Decathlon you describe could in fact be very suitable. > 2) Use a source of entropy on another machine. > > There are sites (I forget the name, you probably know them), that > provide entropy across the Internet. While I'm not that sure of the > idea, it would solve the problem some what. I think there are two implications to this: First, we would need to trust the provider of the random data to never look at it and/or clear all records of it after transmission. If you had a particular "randomn- ness provider" you trust, this could be feasible. Except that we'd transfer the random bits over the network, where anyone could look at them. My understanding is that mixing in such a source cannot hurt the resulting random output, but overall I think such input would not actually help us for encryption key generation. > 3) Allow randomness/key to be retrieved from elsewhere. > > Similar to preseeding, either grab a file of a disk or server that has > entropy or the keys. Obviously it needs to be done right, but I think > this should perhaps be done anyway to help with multiple installs. You > can have the file in any format you like (cat /dev/random > file or > actually create GPG encrypted keys), and provide a script to create one > on a running machine. This seems like the most practical solution. I suppose it would be easiest to just generate complete GPG keys on another machine; That would save us from having to worry about secure transport of the random data. There is a small script loop-aes-keygen(1) in package loop-aes-utils which can be used to create GPG-wrapped encryption keys on another system. They could be stored on some removable medium and get loaded by partman-crypto. > 4) Make d-i harder to use. > > If entropy is gathered during the install, it should be made harder, so > that more key presses are required before partman-crypto is reached, and > so increasing the entropy in the pool without the user realising it is > for encryption. :-) cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
