25 Dec, 2008

3 commits

  • The ANSI X9.31 PRNG docs aren't particularly clear on how to increment DT,
    but empirical testing shows we're incrementing from the wrong end. A 10,000
    iteration Monte Carlo RNG test currently winds up not getting the expected
    result.

    From http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf :

    # CAVS 4.3
    # ANSI931 MCT
    [X9.31]
    [AES 128-Key]

    COUNT = 0
    Key = 9f5b51200bf334b5d82be8c37255c848
    DT = 6376bbe52902ba3b67c925fa701f11ac
    V = 572c8e76872647977e74fbddc49501d1
    R = 48e9bd0d06ee18fbe45790d5c3fc9b73

    Currently, we get 0dd08496c4f7178bfa70a2161a79459a after 10000 loops.

    Inverting the DT increment routine results in us obtaining the expected result
    of 48e9bd0d06ee18fbe45790d5c3fc9b73. Verified on both x86_64 and ppc64.

    Signed-off-by: Jarod Wilson
    Acked-by: Neil Horman
    Signed-off-by: Herbert Xu

    Jarod Wilson
     
  • While working with some FIPS RNGVS test vectors yesterday, I discovered a
    little bug in the way the ansi_cprng code works right now.

    For example, the following test vector (complete with expected result)
    from http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf ...

    Key = f3b1666d13607242ed061cabb8d46202
    DT = e6b3be782a23fa62d71d4afbb0e922fc
    V = f0000000000000000000000000000000
    R = 88dda456302423e5f69da57e7b95c73a

    ...when run through ansi_cprng, yields an incorrect R value
    of e2afe0d794120103d6e86a2b503bdfaa.

    If I load up ansi_cprng w/dbg=1 though, it was fairly obvious what was
    going wrong:

    ----8
    Acked-by: Neil Horman
    Signed-off-by: Herbert Xu

    Jarod Wilson
     
  • This is a patch that was sent to me by Jarod Wilson, marking off my
    outstanding todo to allow the ansi cprng to set/reset the DT counter value in a
    cprng instance. Currently crytpo_rng_reset accepts a seed byte array which is
    interpreted by the ansi_cprng as a {V key} tuple. This patch extends that tuple
    to now be {V key DT}, with DT an optional value during reset. This patch also
    fixes a bug we noticed in which the offset of the key area of the seed is
    started at DEFAULT_PRNG_KSZ rather than DEFAULT_BLK_SZ as it should be.

    Signed-off-by: Neil Horman
    Signed-off-by: Jarod Wilson
    Signed-off-by: Herbert Xu

    Neil Horman
     

29 Aug, 2008

1 commit

  • This patch adds a random number generator interface as well as a
    cryptographic pseudo-random number generator based on AES. It is
    meant to be used in cases where a deterministic CPRNG is required.

    One of the first applications will be as an input in the IPsec IV
    generation process.

    Signed-off-by: Neil Horman
    Signed-off-by: Herbert Xu

    Neil Horman