I do not know about TRNG. We use haveged which feeds its entropy into the Linux kernel (necessary on virtual servers to get entropy)
regards Klaus On 14.05.2014 14:05, Alex Omgovitskij wrote: > Hi, > > The reason I'm looking into SoftHSM - it's free :). and SoftHSM in > connection with TRNG is cheaper, then real HSM. > Also according to > http://www.opendnssec.org/wp-content/uploads/2011/01/A-Review-of-Hardware-Security-Modules-Fall-2010.pdf > HSM key storage capacity is not large: > AEP Keyper: 8000 1024-bit RSA keys > Safenet Luna: 1200 2048-bit RSA keys > Thales nShield: Very limited on board NVRAM storage, only recommended if > legally required. Unlimited software key storage in the Security > World/Remote File System. > Utimaco CryptoServer: 5000 1024-bit key pairs per HSM, 1500 key pairs per > PKCS#11 token. > > I'm not sure how many zones we will sign by the same keys (let's say we > have 100.000 zones to sign) - there are a lot of questions to answer still. > by the way - any recommendations? > > Thus SoftHSM or SoftHSM + TRNG is a good choice for now, we can add TRNG > later or even add HSM later if required. > So the question still actual (to foresee future changes in hardware): is it > possible to use SoftHSM + TRNG? > > > > Regards, > Alex > > > On 13 May 2014 19:09, Rick van Rein <[email protected]> wrote: > >> Hello, >> >>> This source: >> http://www.enisa.europa.eu/activities/Resilience-and-CIIP/networks-and-services-resilience/dnssec/gpgdnssec/at_download/fullReportsays: >>> >The random number generator for the system should pass the NIST >> SP 800-22rev15 test >> >> Adding a bit more context that is: >> >> "A means for creating a secure backup of the keys used by the system must >> be provided, together with the option for key generation in a separate >> environment. Depending on the security requirements of the domain holder, a >> hardware security module (HSM) could be required for the signing system. In >> addition, requirements might be set to conform to the specified Security >> Requirements for Cryptographic Modules, Federal Information Processing >> Standards 140 (FIPS) level4. The random number generator for the system >> should pass the NIST SP 800-22rev15 test." >> >> Although ambiguously formulated, I read the last sentence as par of the >> “In addition" to the “depending on” constraint of a Hardware Security >> Module, just as I said ;-) and it is considered optional. I would first >> consider replacing SoftHSM with an HSM before worrying about random number >> generations. >> >> Come to think of it, SoftHSM is a bit of a misnomer — it might have been >> better to call it SoftSM :) but nobody would have understood it then. >> >> -Rick > > > > _______________________________________________ > Opendnssec-user mailing list > [email protected] > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user > _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
