[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Freedombox-discuss] Crypto questions



Spectral Emanation <spectralemanation at gmail.com> wrote:

>>No problem on a typical Linux desktop; it does not do much crypto and /dev/random gets input from keyboard & mouse movement, disk delays, etc. However, it might be a major problem for a plug server that does more crypto, runs headless, and use solid state storage.
>
> I have found this to be a problem on my plug computer. It takes
> minutes to generate a key in OpenSSL or GPG. To get around this I am
> using a two-dollar USB sound adapter from China and the service
> "RandomSound" (http://www.digital-scurf.org/software/randomsound) Now
> there is plenty of entropy. I have done some simple tests to the best
> of my limited ability, and the data seems to be random.

Consider Turbid as an alternate way to get randomness from a sound device.
It has some solid analysis behind it, link in first post above.

> There is a project called Pandora where a group of people got together
> and designed and built a custom portable gaming machine based on the
> ARM OMAP3 platform. I would love to see something similar done to get
> a custom plugcomputer designed and built ...

> We could figure out all the issues we want to address and then get
> custom hardware that is branded by the Freedombox project. The
> Sheevaplug was created to be extended by vendors, why not us if we can
> get enough people to commit to buying one?

I would think we want something that runs on cheap commodity
hardware, rather than a custom solution.

However, most of the commodity hardware is built by companies
in the OEM market (Company A builds it but puts Company B's
name on it) and most of those guys would happily build for us
if we had a big enough order, so your suggestion is certainly
not impossible.

Peter Gutmann (a very credible guy) did a Usenix paper titled
"An Open-source Cryptographic Coprocessor".
http://www.cypherpunks.to/~peter/usenix00.pdf

That would be a fine starting point for some of what you
suggest, but it would involve getting chips fabbed, which
I'd say is a long way outside our brief.



Reply to: