On (10/10/06 23:55), Max Vozeler wrote:
> 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. :-)
Damn, I thought I was being original :-)
>
> 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.
As you think it is a good idea I will spend some time pondering it then.
I think we need the following requirements
1) Simple to code
2) Fit in with the installer (i.e. no 3D graphics)
3) High-intensity (plenty of action, e.g. not hangman)
4) Doesn't require entropy (anything we can precompute a long game of
is fine, Tetris fits well here)
5) Simple to understand, but not boring.
>
> > 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.
>
Yes, I am wary of some of these issues, but perhaps an option for use on a
trusted LAN would be OK.
As for the technical issues, I don't think the kernel random stuff
handles known input very well (but I could well be wrong).
> > 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.
I think this is the best idea. I noticed you had already filed a bug to
implement this after I had sent it. This requires the least effort I
guess, as long as it is clear that the same key file shouldn't be used
on two machines etc.
Thanks,
James
--
James Westby -- GPG Key ID: B577FE13 -- http://jameswestby.net/
seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
