The RDRAND class is opening additional questions, so we may as well address
them now.
If we provide RDRAND, RDSEED, and other hardware based generators, then
that may beg for a Hardware_RNG class to set up the interface/contract for
callers.
If we step back and look at hardware in general, then we might benefit from
a generic interface to provide status. For example, consider a TPM or a
YubiKey. In this case, we may want a Hardware interface rather than a
specific Hardware_RNG interface.
For hardware interfaces, I think there are roughly three states of interest
to us:
(1) Online or ready
(2) Oflline and not ready
(3) Not available
(1) Online or Ready means the device is ready to service requests. (2)
Offline means the devices is available, but its not online or ready. For
example, it may be present but not initialized. Or it may be present but
locked. (3) Not Available means its missing, not plugged in, etc.
If we look at a few use cases:
* RDRAND/RDSEED
- ex, Intel PII or AMD Athlon
- Not available
- never offline, never ready
* RDRAND/RDSEED
- ex, Intel Ivy Bridge
- Always available
- Always online and ready
- Never offline
* YubiKey
- Available when plugged in
- when is it online and ready to service requests?
- who cares about SOP....
* Smartcard
- Not Available when not plugged in to a reader
- Available when plugged in to a reader
- Offline when its locked (PIN/Passcode)
- Online when its unlocked (PIN/Passcode)
Any thoughts?
Jeff
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
