1. 11 10月, 2012 1 次提交
  2. 10 10月, 2012 3 次提交
  3. 08 10月, 2012 7 次提交
    • D
      X.509: Add a crypto key parser for binary (DER) X.509 certificates · c26fd69f
      David Howells 提交于
      Add a crypto key parser for binary (DER) encoded X.509 certificates.  The
      certificate is parsed and, if possible, the signature is verified.
      
      An X.509 key can be added like this:
      
      	# keyctl padd crypto bar @s </tmp/x509.cert
      	15768135
      
      and displayed like this:
      
      	# cat /proc/keys
      	00f09a47 I--Q---     1 perm 39390000     0     0 asymmetri bar: X509.RSA e9fd6d08 []
      
      Note that this only works with binary certificates.  PEM encoded certificates
      are ignored by the parser.
      
      Note also that the X.509 key ID is not congruent with the PGP key ID, but for
      the moment, they will match.
      
      If a NULL or "" name is given to add_key(), then the parser will generate a key
      description from the CertificateSerialNumber and Name fields of the
      TBSCertificate:
      
      	00aefc4e I--Q---     1 perm 39390000     0     0 asymmetri bfbc0cd76d050ea4:/C=GB/L=Cambridge/O=Red Hat/CN=kernel key: X509.RSA 0c688c7b []
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      c26fd69f
    • D
      RSA: Fix signature verification for shorter signatures · 0b1568a4
      David Howells 提交于
      gpg can produce a signature file where length of signature is less than the
      modulus size because the amount of space an MPI takes up is kept as low as
      possible by discarding leading zeros.  This regularly happens for several
      modules during the build.
      
      Fix it by relaxing check in RSA verification code.
      
      Thanks to Tomas Mraz and Miloslav Trmac for help.
      Signed-off-by: NMilan Broz <mbroz@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      0b1568a4
    • D
      RSA: Implement signature verification algorithm [PKCS#1 / RFC3447] · 612e0fe9
      David Howells 提交于
      Implement RSA public key cryptography [PKCS#1 / RFC3447].  At this time, only
      the signature verification algorithm is supported.  This uses the asymmetric
      public key subtype to hold its key data.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      612e0fe9
    • D
      KEYS: Provide signature verification with an asymmetric key · 4ae71c1d
      David Howells 提交于
      Provide signature verification using an asymmetric-type key to indicate the
      public key to be used.
      
      The API is a single function that can be found in crypto/public_key.h:
      
      	int verify_signature(const struct key *key,
      			     const struct public_key_signature *sig)
      
      The first argument is the appropriate key to be used and the second argument
      is the parsed signature data:
      
      	struct public_key_signature {
      		u8 *digest;
      		u16 digest_size;
      		enum pkey_hash_algo pkey_hash_algo : 8;
      		union {
      			MPI mpi[2];
      			struct {
      				MPI s;		/* m^d mod n */
      			} rsa;
      			struct {
      				MPI r;
      				MPI s;
      			} dsa;
      		};
      	};
      
      This should be filled in prior to calling the function.  The hash algorithm
      should already have been called and the hash finalised and the output should
      be in a buffer pointed to by the 'digest' member.
      
      Any extra data to be added to the hash by the hash format (eg. PGP) should
      have been added by the caller prior to finalising the hash.
      
      It is assumed that the signature is made up of a number of MPI values.  If an
      algorithm becomes available for which this is not the case, the above structure
      will have to change.
      
      It is also assumed that it will have been checked that the signature algorithm
      matches the key algorithm.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      4ae71c1d
    • D
      KEYS: Asymmetric public-key algorithm crypto key subtype · a9681bf3
      David Howells 提交于
      Add a subtype for supporting asymmetric public-key encryption algorithms such
      as DSA (FIPS-186) and RSA (PKCS#1 / RFC1337).
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      a9681bf3
    • D
      KEYS: Asymmetric key pluggable data parsers · 46c6f177
      David Howells 提交于
      The instantiation data passed to the asymmetric key type are expected to be
      formatted in some way, and there are several possible standard ways to format
      the data.
      
      The two obvious standards are OpenPGP keys and X.509 certificates.  The latter
      is especially useful when dealing with UEFI, and the former might be useful
      when dealing with, say, eCryptfs.
      
      Further, it might be desirable to provide formatted blobs that indicate
      hardware is to be accessed to retrieve the keys or that the keys live
      unretrievably in a hardware store, but that the keys can be used by means of
      the hardware.
      
      From userspace, the keys can be loaded using the keyctl command, for example,
      an X.509 binary certificate:
      
      	keyctl padd asymmetric foo @s <dhowells.pem
      
      or a PGP key:
      
      	keyctl padd asymmetric bar @s <dhowells.pub
      
      or a pointer into the contents of the TPM:
      
      	keyctl add asymmetric zebra "TPM:04982390582905f8" @s
      
      Inside the kernel, pluggable parsers register themselves and then get to
      examine the payload data to see if they can handle it.  If they can, they get
      to:
      
        (1) Propose a name for the key, to be used it the name is "" or NULL.
      
        (2) Specify the key subtype.
      
        (3) Provide the data for the subtype.
      
      The key type asks the parser to do its stuff before a key is allocated and thus
      before the name is set.  If successful, the parser stores the suggested data
      into the key_preparsed_payload struct, which will be either used (if the key is
      successfully created and instantiated or updated) or discarded.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      46c6f177
    • D
      KEYS: Implement asymmetric key type · 964f3b3b
      David Howells 提交于
      Create a key type that can be used to represent an asymmetric key type for use
      in appropriate cryptographic operations, such as encryption, decryption,
      signature generation and signature verification.
      
      The key type is "asymmetric" and can provide access to a variety of
      cryptographic algorithms.
      
      Possibly, this would be better as "public_key" - but that has the disadvantage
      that "public key" is an overloaded term.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      964f3b3b
  4. 03 10月, 2012 1 次提交
  5. 27 9月, 2012 7 次提交
  6. 11 9月, 2012 2 次提交
  7. 09 9月, 2012 1 次提交
  8. 07 9月, 2012 4 次提交
  9. 29 8月, 2012 1 次提交
  10. 26 8月, 2012 1 次提交
  11. 23 8月, 2012 2 次提交
  12. 21 8月, 2012 4 次提交
  13. 20 8月, 2012 1 次提交
    • J
      crypto: aesni_intel - improve lrw and xts performance by utilizing parallel... · 023af608
      Jussi Kivilinna 提交于
      crypto: aesni_intel - improve lrw and xts performance by utilizing parallel AES-NI hardware pipelines
      
      Use parallel LRW and XTS encryption facilities to better utilize AES-NI
      hardware pipelines and gain extra performance.
      
      Tcrypt benchmark results (async), old vs new ratios:
      
      Intel Core i5-2450M CPU (fam: 6, model: 42, step: 7)
      
      aes:128bit
              lrw:256bit      xts:256bit
      size    lrw-enc lrw-dec xts-dec xts-dec
      16B     0.99x   1.00x   1.22x   1.19x
      64B     1.38x   1.50x   1.58x   1.61x
      256B    2.04x   2.02x   2.27x   2.29x
      1024B   2.56x   2.54x   2.89x   2.92x
      8192B   2.85x   2.99x   3.40x   3.23x
      
      aes:192bit
              lrw:320bit      xts:384bit
      size    lrw-enc lrw-dec xts-dec xts-dec
      16B     1.08x   1.08x   1.16x   1.17x
      64B     1.48x   1.54x   1.59x   1.65x
      256B    2.18x   2.17x   2.29x   2.28x
      1024B   2.67x   2.67x   2.87x   3.05x
      8192B   2.93x   2.84x   3.28x   3.33x
      
      aes:256bit
              lrw:348bit      xts:512bit
      size    lrw-enc lrw-dec xts-dec xts-dec
      16B     1.07x   1.07x   1.18x   1.19x
      64B     1.56x   1.56x   1.70x   1.71x
      256B    2.22x   2.24x   2.46x   2.46x
      1024B   2.76x   2.77x   3.13x   3.05x
      8192B   2.99x   3.05x   3.40x   3.30x
      
      Cc: Huang Ying <ying.huang@intel.com>
      Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Reviewed-by: NKim Phillips <kim.phillips@freescale.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      023af608
  14. 01 8月, 2012 5 次提交
    • S
      powerpc/crypto: add 842 crypto driver · 35a1fc18
      Seth Jennings 提交于
      This patch add the 842 cryptographic API driver that
      submits compression requests to the 842 hardware compression
      accelerator driver (nx-compress).
      
      If the hardware accelerator goes offline for any reason
      (dynamic disable, migration, etc...), this driver will use LZO
      as a software failover for all future compression requests.
      For decompression requests, the 842 hardware driver contains
      a software implementation of the 842 decompressor to support
      the decompression of data that was compressed before the accelerator
      went offline.
      Signed-off-by: NRobert Jennings <rcj@linux.vnet.ibm.com>
      Signed-off-by: NSeth Jennings <sjenning@linux.vnet.ibm.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      35a1fc18
    • J
      crypto: cast6 - add x86_64/avx assembler implementation · 4ea1277d
      Johannes Goetzfried 提交于
      This patch adds a x86_64/avx assembler implementation of the Cast6 block
      cipher. The implementation processes eight blocks in parallel (two 4 block
      chunk AVX operations). The table-lookups are done in general-purpose registers.
      For small blocksizes the functions from the generic module are called. A good
      performance increase is provided for blocksizes greater or equal to 128B.
      
      Patch has been tested with tcrypt and automated filesystem tests.
      
      Tcrypt benchmark results:
      
      Intel Core i5-2500 CPU (fam:6, model:42, step:7)
      
      cast6-avx-x86_64 vs. cast6-generic
      128bit key:                                             (lrw:256bit)    (xts:256bit)
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
      16B     0.97x   1.00x   1.01x   1.01x   0.99x   0.97x   0.98x   1.01x   0.96x   0.98x
      64B     0.98x   0.99x   1.02x   1.01x   0.99x   1.00x   1.01x   0.99x   1.00x   0.99x
      256B    1.77x   1.84x   0.99x   1.85x   1.77x   1.77x   1.70x   1.74x   1.69x   1.72x
      1024B   1.93x   1.95x   0.99x   1.96x   1.93x   1.93x   1.84x   1.85x   1.89x   1.87x
      8192B   1.91x   1.95x   0.99x   1.97x   1.95x   1.91x   1.86x   1.87x   1.93x   1.90x
      
      256bit key:                                             (lrw:384bit)    (xts:512bit)
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec lrw-enc lrw-dec xts-enc xts-dec
      16B     0.97x   0.99x   1.02x   1.01x   0.98x   0.99x   1.00x   1.00x   0.98x   0.98x
      64B     0.98x   0.99x   1.01x   1.00x   1.00x   1.00x   1.01x   1.01x   0.97x   1.00x
      256B    1.77x   1.83x   1.00x   1.86x   1.79x   1.78x   1.70x   1.76x   1.71x   1.69x
      1024B   1.92x   1.95x   0.99x   1.96x   1.93x   1.93x   1.83x   1.86x   1.89x   1.87x
      8192B   1.94x   1.95x   0.99x   1.97x   1.95x   1.95x   1.87x   1.87x   1.93x   1.91x
      Signed-off-by: NJohannes Goetzfried <Johannes.Goetzfried@informatik.stud.uni-erlangen.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      4ea1277d
    • J
      crypto: testmgr - add larger cast6 testvectors · 9b8b0405
      Johannes Goetzfried 提交于
      New ECB, CBC, CTR, LRW and XTS testvectors for cast6. We need larger
      testvectors to check parallel code paths in the optimized implementation. Tests
      have also been added to the tcrypt module.
      Signed-off-by: NJohannes Goetzfried <Johannes.Goetzfried@informatik.stud.uni-erlangen.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      9b8b0405
    • J
      crypto: cast6 - prepare generic module for optimized implementations · 2b49b906
      Johannes Goetzfried 提交于
      Rename cast6 module to cast6_generic to allow autoloading of optimized
      implementations. Generic functions and s-boxes are exported to be able to use
      them within optimized implementations.
      Signed-off-by: NJohannes Goetzfried <Johannes.Goetzfried@informatik.stud.uni-erlangen.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2b49b906
    • J
      crypto: cast5 - add x86_64/avx assembler implementation · 4d6d6a2c
      Johannes Goetzfried 提交于
      This patch adds a x86_64/avx assembler implementation of the Cast5 block
      cipher. The implementation processes sixteen blocks in parallel (four 4 block
      chunk AVX operations). The table-lookups are done in general-purpose registers.
      For small blocksizes the functions from the generic module are called. A good
      performance increase is provided for blocksizes greater or equal to 128B.
      
      Patch has been tested with tcrypt and automated filesystem tests.
      
      Tcrypt benchmark results:
      
      Intel Core i5-2500 CPU (fam:6, model:42, step:7)
      
      cast5-avx-x86_64 vs. cast5-generic
      64bit key:
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec
      16B     0.99x   0.99x   1.00x   1.00x   1.02x   1.01x
      64B     1.00x   1.00x   0.98x   1.00x   1.01x   1.02x
      256B    2.03x   2.01x   0.95x   2.11x   2.12x   2.13x
      1024B   2.30x   2.24x   0.95x   2.29x   2.35x   2.35x
      8192B   2.31x   2.27x   0.95x   2.31x   2.39x   2.39x
      
      128bit key:
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec
      16B     0.99x   0.99x   1.00x   1.00x   1.01x   1.01x
      64B     1.00x   1.00x   0.98x   1.01x   1.02x   1.01x
      256B    2.17x   2.13x   0.96x   2.19x   2.19x   2.19x
      1024B   2.29x   2.32x   0.95x   2.34x   2.37x   2.38x
      8192B   2.35x   2.32x   0.95x   2.35x   2.39x   2.39x
      Signed-off-by: NJohannes Goetzfried <Johannes.Goetzfried@informatik.stud.uni-erlangen.de>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      4d6d6a2c