On 01/27/2011 07:37 AM, Len Sassaman wrote:
On Wed, 26 Jan 2011, Thierry Moreau wrote:
2) a host plus some H/W for true random source
Speaking of hardware entropy sources, has anyone analyzed the Simtek
Electronics Entropy Key (http://www.entropykey.co.uk/)? It's a USB
dongle, recommended to me by several remailer operators.
Looks cool, but as much as I like the idea of entropy generation, I have
to wonder if it outweighs the risk of adding more moving parts to the
system.
For example, this key requires a daemon to operate. On *nix this will
probably be running as root, or at least as a user with privileges to
talk to USB and lie to /dev/random about how much real entropy it has.
I downloaded the code and spot-checked it quickly. On the whole, it
looks like a really clean and professional implementation.
Nevertheless, it represents 8000 lines of C code using fixed-sized
buffers for string handling. It's almost certain to have bugs, the
exploitability of which being up to lady luck.
For example:
ekeyd-1.1.3/device/frames/pem.c defines a function pem64_decode_bytes().
This function takes an incoming sequence of chars (possibly supplied by
an attacker), promotes them to int values, and uses them to dereference
a fixed-sized array 'inverse_dictionary[128]'.
Thus when built with compiler settings which treat char as signed, an
attacker can supply corrupt PEM64 strings which, rather than decoding
correctly, can be instead read from chosen locations of the 128 bytes of
space prior to the start of inverse_dictionary. If char is unsigned, the
bad guy can read subsequent bytes.
If the daemon was built on a good day, it will just have uninteresting
stuff in those locations. On a bad day, you'll end up with key material
there.
- Marsh
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
