Re: [PATCH 0/1] enhance RNG api with flags to allow for different operational modes (v2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 Hey all-
 	Ok, so I've got a story behind this one.  It was recently called to my
 attention that the ansi cprng is missing an aspect of its compliance requrements
 for FIPS-140.  Specifically, its missing a behavior in its continuous test.
 When the CPRNG produces random blocks, the firrst block that it produces must
 never be returned to the user.  Instead it must be saved and a second block must
 be generated so that it can be compared to the first block before being returned
 to the user.
 
 	I recently posted a patch to do this for the hardware RNG.  Its fine to
 do this there, since there are no expectations of a predictable result in that
 RNG.  The CPRNG however, provides a predictable random sequence for a given
 input seed key and iteration.  The above requirement messes with that
 predictability however because it changes which block is returned on the zeroth
 iteration to the user.  Some test vectors expect this, some do not.
 
 	So the question is, how do I make this RNG fips compliant without
 breaking some subset of users out there that rely on the predictability of the
 CPRNG? The solution we've discussed here is the use of a wrapper algorithm.  We
implement fips(ansi_cprng), which is exactly like the ansi_cprng, except that it
implements the continuous test on top of it.
 
 Signed-off-by: Neil Horman <nhorman@xxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux