Posted on | October 19, 2008 | No Comments
I have a random problem, in particular random numbers. I am working on a re-write of SRCE to fortify things a bit .. and get rid of a lot of ugly code that was introduced when I wasn’t actively managing patches.
Humans are the best source of entropy to get random numbers.. the amount of time that lapses between each of your key strokes when you write a paragraph is a very valuable source to obtain random numbers. If you correct spelling mistakes, even better .. the number of mistakes that you make (judged by how many times you backspace) is gold. Other stuff works too, such as a sampling of ambient noise from your microphone.
When SRCE authenticates, it does not send any part of the key. Rather, the client issues an AUTH request with a number corresponding to a random line in a key file. The server then returns its own random number .. both parties can then agree on which two lines of the same key can be used (with salt) to determine the Blowfish secret. The client can optionally send a ‘hint’ that it actually has the key with an AUTH request via a SHA hash of the entire key, or the server can do this (both is a bad idea). The idea of SRCE is to provide reasonably good security without a public key.
The problem is, generating (strong) random numbers takes time, connections need to be instant.
The easiest solution is to gather a ton of entropy at compile time by asking the user to type randomly, build a table and include it in the rest of the build. Client and server then have this to generate the random numbers needed for authentication quickly once put to work. Sure, if someone ‘gets root’ on your machine they could read this table … but that would be the least of your problems
The major issue is that method completely alienates any future binary release and re-generating key files would also mean rebuilding (at least) the client.
I do not envy the job of people who deal with these kinds of problems every day.
Maybe generating Manderbolts (fractals) at compile time would be a better solution, of course after gathering entropy and using it to define the plane. This would at least eliminate bugging the user a second time. You’d have a random quadratic plane, random colors, random size, etc. A hash of a sampling of pixel properties might be useful.