Bug#381875: loop-AES key generation requires tiresome typing
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
Reply to: