public abstract class FIPS140_2Compliant
extends java.security.SecureRandomSpi
FIPS 140-2 requires that a continuous random number generator test. If a cryptographic module employs Approved or non-Approved RNGs in an Approved mode of operation, the module shall perform the following continuous random number generator test on each RNG that tests for failure to a constant value.
This class only can only be used with RSGs that produce blocks of n bits where n must be greater than 15.
An FIPS 140-2 compliant PRNG algorithm instance of a algorithm can be
obtained using the Java Cryptography Architecture (JCA), by requesting the
'<algorithm>' PRNG from the
Entrust cryptographic
service provider. This can be done using the following call:
SecureRandom.getInstance("<algorithm>", "Entrust");
| Modifier and Type | Method and Description |
|---|---|
protected byte[] |
engineGenerateSeed(int numBytes)
Returns the given number of seed bytes.
|
protected void |
engineNextBytes(byte[] bytes)
Generates a user-specified number of random bytes.
|
protected abstract void |
engineSetSeed(byte[] seed)
Reseeds this random object.
|
protected final void engineNextBytes(byte[] bytes)
throws java.lang.SecurityException
For every block of data that is generated, the FIPS 140-2 Continuous random number generator test is run.
engineNextBytes in class java.security.SecureRandomSpibytes - [FIPS 140-2 data output] the array to be filled in with random
bytesFips140ErrorStateException - [FIPS 140-2 status output] thrown if the Toolkit is not
allowed to perform cryptographic operationsjava.lang.SecurityExceptionprotected final byte[] engineGenerateSeed(int numBytes)
Generates a cryptographically strong seed of the specified length.This call may be used to seed other random number generators.
engineGenerateSeed in class java.security.SecureRandomSpinumBytes - [FIPS 140-2 data input] the number of seed bytes to generateFips140ErrorStateException - [FIPS 140-2 status output] thrown if the Toolkit is not
allowed to perform cryptographic operationsprotected abstract void engineSetSeed(byte[] seed)
The given seed supplements, rather than replaces, the existing seed. Thus, repeated calls are guaranteed never to reduce randomness.
This implementation DOES NOT allow the caller to set the initial seed,
even when the caller follows the call to
SecureRandom.getInstance() method with a call to the
setSeed() method. This ensures that it is impossible to have
an initial seed that is not cryptographically strong.
The seed that is passed in is not used directly; instead the seed is hashed before prior to use. The hashing is done because the entropy of the provided seed may not be spread evenly through all of the seed bits (no way to guarantee a cryptographically strong seed will be passed in the API). By passing the seed through a hash (message digest) algorithm, the entropy is spread (more or less) evenly through all of the bits.
Once the provided seed has been hashed, the result is used to supplement (not replace) the existing internal seed data. Following this call, the seed passed is NOT automatically wiped from memory; this SHOULD be done manually. All internal temporary data used is in this call is also automatically wiped following usage.
engineSetSeed in class java.security.SecureRandomSpiseed - [FIPS 140-2 data input] [FIPS 140-2 CSP] the seed.Fips140ErrorStateException - [FIPS 140-2 status output] thrown if the Toolkit is not
allowed to perform cryptographic operations