Thanks Sandy, Peter and Jack for the feedback.
Just one clarification on a question I ask myself, see below.
Sandy Harris wrote:
Thierry Moreau <[email protected]> wrote:
Bursts of cryptographic operations consuming random data will
force either a PRNG expander of randomness or true random data buffering,
both of which implies system state data that requires secrecy protection.
Yes, that is a real problem. Using something like the Linux or BSD
/dev/random may eliminate the need for buffering, but then its state
needs protecting.
In any event, a cryptographic system invariably needs a secure storage
arrangement ("chmod 600 filename" as a very least) for secret or private key
material. I would like to see a publication about the pros and cons of
relying on such secure storage in a secure system design instead of a higher
speed true random source. I suspect overall protections are enhanced if
design/implementation efforts are devoted to secure storage (where a PRNG
state may be kept) and correspondingly lesser emphasis is put on high speed
true random source.
If an enemy gets root on your system, then your secure storage is no
longer secure. By all means, if you have something like /dev/random
or another buffering scheme, store some state and throw it in after
a reboot. It certainly cannot hurt and, if the file is secure, it helps
a lot.
The question I have is how good a system is if the private signature key
(or other long term secret) is breached and the every system function is
compromised.
As a derived engineering strategy, wouldn't it be better to design a
system where the long-term secrets are kept in a "secure" co-processor,
leading to this other challenge of an API that delivers services only to
"legitimate functions" in its host system. Once I have a
better-than-nothing solution for this ([1]), the secure co-processor may
implement a secret random source as well.
Irrespective of the details, I feel that spending too much efforts on
the true random source ignores long term secret storage (the other
fundamental source of vulnerability).
Regards,
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
[1] The design I have on my drawing board is a secure logical link
between the co-processor and the host with a session setup based on a
public key of the co-processor and a *limitation*to*a*single*session*.
When the server starts, the legitimate host application grabs this
session, the operator verifies that the legitimate application behaves
as expected, and thereafter no other application can use the API. In
reviewing prior art along this line, I saw this concept present in a
neat and comprehensive solution for laptop encryption.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
