On 03/21/2011 11:28 AM, Thierry Moreau wrote:
I don't see how a security library author can ascertain that the
end-user production environment will indeed provide a good secret random
number source.
Or anything secret at all for that matter.
A general-purpose library with wide usability normally has to be written
in a portable language such as C, C++, or Java. None of these languages
can offer even the most basic guarantees of OS security like process
memory isolation, secure file and memory overwriting, etc. It's just not
part of those language specifications for obvious reasons.
So per-platform code will always be required to keep secret material
from being left floating around in unallocated memory or being paged out
to disk. Random number generation isn't really all that different than
other types of platform-specific code.
Even then, the underlying platform changes as new layers of abstraction
accrete over time. Systems get transparently migrated to virtualized
cloud environments which specifically attempt to hide this fact from the
operating system images they host.
When the code is portable, but the security is not, it's an inherently
dangerous situation that invites silent failure modes. For example,
Debian's change which silently broke OpenSSL's RNG was in response to a
run-time purity checking tool complaining that the entropy-harvesting
routine was accessing uninitialized memory.
The only antidote is having comprehensive documentation of exactly the
assumptions and requirements the code places on the underlying runtime
environment. Even then, it takes a truly professional ongoing end-to-end
engineering process to make sure those requirements stay met as the
deployment changes over time.
- Marsh
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
