21 Nov, 2011

1 commit

  • Patch adds x86_64/SSE2 assembler implementation of serpent cipher. Assembler
    functions crypt data in eigth block chunks (two 4 block chunk SSE2 operations
    in parallel to improve performance on out-of-order CPUs). Glue code is based
    on one from AES-NI implementation, so requests from irq context are redirected
    to cryptd.

    v2:
    - add missing include of linux/module.h
    (appearently crypto.h used to include module.h, which changed for 3.2 by
    commit 7c926402a7e8c9b279968fd94efec8700ba3859e)

    Patch has been tested with tcrypt and automated filesystem tests.

    Tcrypt benchmarks results (serpent-sse2/serpent_generic speed ratios):

    AMD Phenom II 1055T (fam:16, model:10):

    size ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec
    16B 1.03x 1.01x 1.03x 1.05x 1.00x 0.99x
    64B 1.00x 1.01x 1.02x 1.04x 1.02x 1.01x
    256B 2.34x 2.41x 0.99x 2.43x 2.39x 2.40x
    1024B 2.51x 2.57x 1.00x 2.59x 2.56x 2.56x
    8192B 2.50x 2.54x 1.00x 2.55x 2.57x 2.57x

    Intel Celeron T1600 (fam:6, model:15, step:13):

    size ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec
    16B 0.97x 0.97x 1.01x 1.01x 1.01x 1.02x
    64B 1.00x 1.00x 1.00x 1.02x 1.01x 1.01x
    256B 3.41x 3.35x 1.00x 3.39x 3.42x 3.44x
    1024B 3.75x 3.72x 0.99x 3.74x 3.75x 3.75x
    8192B 3.70x 3.68x 0.99x 3.68x 3.69x 3.69x

    Full output:
    http://koti.mbnet.fi/axh/kernel/crypto/phenom-ii-1055t/serpent-generic.txt
    http://koti.mbnet.fi/axh/kernel/crypto/phenom-ii-1055t/serpent-sse2.txt
    http://koti.mbnet.fi/axh/kernel/crypto/celeron-t1600/serpent-generic.txt
    http://koti.mbnet.fi/axh/kernel/crypto/celeron-t1600/serpent-sse2.txt

    Signed-off-by: Jussi Kivilinna
    Signed-off-by: Herbert Xu

    Jussi Kivilinna
     

09 Nov, 2011

5 commits


21 Oct, 2011

2 commits


04 May, 2011

1 commit


29 Jan, 2011

2 commits

  • A self-test failure in fips mode means a panic. Well, gcm(aes)
    self-tests currently fail in fips mode, as gcm is dependent on ghash,
    which semi-recently got self-test vectors added, but wasn't marked as a
    fips_allowed algorithm. Because of gcm's dependence on what is now seen
    as a non-fips_allowed algorithm, its self-tests refuse to run.
    Previously, ghash got a pass in fips mode, due to the lack of any test
    vectors at all, and thus gcm self-tests were able to run. After this
    patch, a 'modprobe tcrypt mode=35' no longer panics in fips mode, and
    successful self-test of gcm(aes) is reported.

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

    Jarod Wilson
     
  • We (Red Hat) are intending to include dm-crypt functionality, using
    xts(aes) for disk encryption, as part of an upcoming FIPS-140-2
    certification effort, and xts(aes) *is* on the list of possible
    mode/cipher combinations that can be certified. To make that possible, we
    need to mark xts(aes) as fips_allowed in the crypto subsystem.

    A 'modprobe tcrypt mode=10' in fips mode shows xts(aes) self-tests
    passing successfully after this change.

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

    Jarod Wilson
     

13 Nov, 2010

1 commit


06 Aug, 2010

1 commit

  • This patch fixes a serious bug in the test disabling patch where
    it can cause an spurious load of the cryptomgr module even when
    it's compiled in.

    It also negates the test disabling option so that its absence
    causes tests to be enabled.

    The Kconfig option is also now behind EMBEDDED.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

03 Jun, 2010

1 commit


19 May, 2010

1 commit


23 Dec, 2009

1 commit

  • When load aesni-intel and ghash_clmulni-intel driver,kernel will complain no
    test for some internal used algorithm.
    The strange information as following:

    alg: No test for __aes-aesni (__driver-aes-aesni)
    alg: No test for __ecb-aes-aesni (__driver-ecb-aes-aesni)
    alg: No test for __cbc-aes-aesni (__driver-cbc-aes-aesni)
    alg: No test for __ecb-aes-aesni (cryptd(__driver-ecb-aes-aesni)
    alg: No test for __ghash (__ghash-pclmulqdqni)
    alg: No test for __ghash (cryptd(__ghash-pclmulqdqni))

    This patch add NULL test entries for these algorithm and driver.

    Signed-off-by: Youquan, Song
    Signed-off-by: Ying, Huang
    Signed-off-by: Herbert Xu

    Youquan, Song
     

23 Nov, 2009

1 commit


27 Oct, 2009

1 commit


02 Sep, 2009

1 commit


02 Jul, 2009

1 commit


24 Jun, 2009

1 commit


02 Jun, 2009

14 commits

  • As it stands we will each test hash vector both linearly and as
    a scatter list if applicable. This means that we cannot have
    vectors longer than a page, even with scatter lists.

    This patch fixes this by skipping test vectors with np != 0 when
    testing linearly.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • As we cannot guarantee the availability of contiguous pages at
    run-time, all test vectors must either fit within a page, or use
    scatter lists. In some cases vectors were not checked as to
    whether they fit inside a page. This patch adds all the missing
    checks.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • If crypto_{,de}compress_{update,final}() succeed, return the actual number of
    bytes produced instead of zero, so their users don't have to calculate that
    theirselves.

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Herbert Xu

    Geert Uytterhoeven
     
  • Because all fips-allowed algorithms must be self-tested before they
    can be used, they will all have entries in testmgr.c's alg_test_descs[].
    Skip self-tests for any algs not flagged as fips_approved and return
    -EINVAL when in fips mode.

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

    Jarod Wilson
     
  • Set the fips_allowed flag in testmgr.c's alg_test_descs[] for algs
    that are allowed to be used when in fips mode.

    One caveat: des isn't actually allowed anymore, but des (and thus also
    ecb(des)) has to be permitted, because disallowing them results in
    des3_ede being unable to properly register (see des module init func).

    Also, crc32 isn't technically on the fips approved list, but I think
    it gets used in various places that necessitate it being allowed.

    This list is based on
    http://csrc.nist.gov/groups/STM/cavp/index.html

    Important note: allowed/approved here does NOT mean "validated", just
    that its an alg that *could* be validated.

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

    Jarod Wilson
     
  • Now with multi-block test vectors, all from SP800-38A, Appendix F.5.
    Also added ctr(aes) to case 10 in tcrypt.

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

    Jarod Wilson
     
  • We currently allocate temporary memory that is used for testing
    statically. This renders the testing engine non-reentrant. As
    algorithms may nest, i.e., one may construct another in order to
    carry out a part of its operation, this is unacceptable. For
    example, it has been reported that an AEAD implementation allocates
    a cipher in its setkey function, which causes it to fail during
    testing as the temporary memory is overwritten.

    This patch replaces the static memory with dynamically allocated
    buffers. We need a maximum of 16 pages so this slightly increases
    the chances of an algorithm failing due to memory shortage.
    However, as testing usually occurs at registration, this shouldn't
    be a big problem.

    Reported-by: Shasi Pulijala
    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • According to our FIPS CAVS testing lab guru, when we're in fips mode,
    we must print out notices of successful self-test completion for
    every alg to be compliant.

    New and improved v2, without strncmp crap. Doesn't need to touch a flag
    though, due to not moving the notest label around anymore.

    Applies atop '[PATCH v2] crypto: catch base cipher self-test failures
    in fips mode'.

    Personally, I wouldn't mind seeing this info printed out regardless of
    whether or not we're in fips mode, I think its useful info, but will
    stick with only in fips mode for now.

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

    Jarod Wilson
     
  • Signed-off-by: Jarod Wilson
    Signed-off-by: Herbert Xu

    Jarod Wilson
     
  • Add ANSI X9.31 Continuous Pseudo-Random Number Generator (AES mode),
    aka 'ansi_cprng' test vectors, taken from Appendix B.2.9 and B.2.10
    of the NIST RNGVS document, found here:
    http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf

    Successfully tested against both the cryptodev-2.6 tree and a Red
    Hat Enterprise Linux 5.4 kernel, via 'modprobe tcrypt mode=150'.

    The selection of 150 was semi-arbitrary, didn't seem like it should
    go any place in particular, so I started a new range for rng tests.

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

    Jarod Wilson
     
  • Add some necessary infrastructure to make it possible to run
    self-tests for ansi_cprng. The bits are likely very specific
    to the ANSI X9.31 CPRNG in AES mode, and thus perhaps should
    be named more specifically if/when we grow additional CPRNG
    support...

    Successfully tested against the cryptodev-2.6 tree and a
    Red Hat Enterprise Linux 5.x kernel with the follow-on
    patch that adds the actual test vectors.

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

    Jarod Wilson
     
  • Add an array of encryption and decryption + verification self-tests
    for rfc4309(ccm(aes)).

    Test vectors all come from sample FIPS CAVS files provided to
    Red Hat by a testing lab. Unfortunately, all the published sample
    vectors in RFC 3610 and NIST Special Publication 800-38C contain nonce
    lengths that the kernel's rfc4309 implementation doesn't support, so
    while using some public domain vectors would have been preferred, its
    not possible at this time.

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

    Jarod Wilson
     
  • Add infrastructure to tcrypt/testmgr to support handling ccm decryption
    test vectors that are expected to fail verification.

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

    Jarod Wilson
     
  • make C=1:
    | crypto/testmgr.c:846:45: warning: incorrect type in argument 5 (different signedness)
    | crypto/testmgr.c:846:45: expected unsigned int *dlen
    | crypto/testmgr.c:846:45: got int *
    | crypto/testmgr.c:878:47: warning: incorrect type in argument 5 (different signedness)
    | crypto/testmgr.c:878:47: expected unsigned int *dlen
    | crypto/testmgr.c:878:47: got int *

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Herbert Xu

    Geert Uytterhoeven
     

04 Mar, 2009

2 commits


25 Dec, 2008

3 commits

  • When self-testing (de)compression algorithms, make sure the actual size of
    the (de)compressed output data matches the expected output size.
    Otherwise, in case the actual output size would be smaller than the expected
    output size, the subsequent buffer compare test would still succeed, and no
    error would be reported.

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Herbert Xu

    Geert Uytterhoeven
     
  • This warning:

    crypto/testmgr.c: In function ‘test_comp’:
    crypto/testmgr.c:829: warning: ‘ret’ may be used uninitialized in this function

    triggers because GCC correctly notices that in the ctcount == 0 &&
    dtcount != 0 input condition case this function can return an undefined
    value, if the second loop fails.

    Remove the shadowed 'ret' variable from the second loop that was probably
    unintended.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Herbert Xu

    Ingo Molnar
     
  • This patch adds a test for the requirement that all crc32c algorithms
    shall store the partial result in the first four bytes of the descriptor
    context.

    Signed-off-by: Herbert Xu

    Herbert Xu