- 28 11月, 2016 4 次提交
-
-
由 Herbert Xu 提交于
This patch converts aesni (including fpu) over to the skcipher interface. The LRW implementation has been removed as the generic LRW code can now be used directly on top of the accelerated ECB implementation. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Herbert Xu 提交于
This patch adds xts helpers that use the skcipher interface rather than blkcipher. This will be used by aesni_intel. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Herbert Xu 提交于
This patch adds the simd skcipher helper which is meant to be a replacement for ablk helper. It replaces the underlying blkcipher interface with skcipher, and also presents the top-level algorithm as an skcipher. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Jean Delvare 提交于
For consistency with the other 246 kernel configuration options, rename CRYPT_CRC32C_VPMSUM to CRYPTO_CRC32C_VPMSUM. Signed-off-by: NJean Delvare <jdelvare@suse.de> Cc: Anton Blanchard <anton@samba.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 25 10月, 2016 6 次提交
-
-
由 Giovanni Cabiddu 提交于
Add scomp backend for deflate compression algorithm. Signed-off-by: NGiovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Giovanni Cabiddu 提交于
Add scomp backend for 842 compression algorithm. Signed-off-by: NGiovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Giovanni Cabiddu 提交于
Add scomp backend for lz4hc compression algorithm. Signed-off-by: NGiovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Giovanni Cabiddu 提交于
Add scomp backend for lz4 compression algorithm. Signed-off-by: NGiovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Giovanni Cabiddu 提交于
Add scomp backend for lzo compression algorithm. Signed-off-by: NGiovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Giovanni Cabiddu 提交于
Add acomp, an asynchronous compression api that uses scatterlist buffers. Signed-off-by: NGiovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 21 10月, 2016 1 次提交
-
-
由 Alec Ari 提交于
Currently FIPS depends on MODULE_SIG, even if MODULES is disabled. This change allows the enabling of FIPS without support for modules. If module loading support is enabled, only then does FIPS require MODULE_SIG. Signed-off-by: NAlec Ari <neotheuser@gmail.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 09 8月, 2016 1 次提交
-
-
由 Michael Ellerman 提交于
The optimised crc32c implementation depends on VMX (aka. Altivec) instructions, so the kernel must be built with Altivec support in order for the crc32c code to build. Fixes: 6dd7a82c ("crypto: powerpc - Add POWER8 optimised crc32c") Acked-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 05 7月, 2016 1 次提交
-
-
由 Anton Blanchard 提交于
Use the vector polynomial multiply-sum instructions in POWER8 to speed up crc32c. This is just over 41x faster than the slice-by-8 method that it replaces. Measurements on a 4.1 GHz POWER8 show it sustaining 52 GiB/sec. A simple btrfs write performance test: dd if=/dev/zero of=/mnt/tmpfile bs=1M count=4096 sync is over 3.7x faster. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 28 6月, 2016 1 次提交
-
-
由 Megha Dey 提交于
Add the config CRYPTO_SHA512_MB which will enable the computation using the SHA512 multi-buffer algorithm. Signed-off-by: NMegha Dey <megha.dey@linux.intel.com> Reviewed-by: NFenghua Yu <fenghua.yu@intel.com> Reviewed-by: NTim Chen <tim.c.chen@linux.intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 27 6月, 2016 1 次提交
-
-
由 Megha Dey 提交于
Add the config CRYPTO_SHA256_MB which will enable the computation using the SHA256 multi-buffer algorithm. Signed-off-by: NMegha Dey <megha.dey@linux.intel.com> Reviewed-by: NFenghua Yu <fenghua.yu@intel.com> Reviewed-by: NTim Chen <tim.c.chen@linux.intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 23 6月, 2016 3 次提交
-
-
由 Salvatore Benedetto 提交于
* Implement ECDH under kpp API * Provide ECC software support for curve P-192 and P-256. * Add kpp test for ECDH with data generated by OpenSSL Signed-off-by: NSalvatore Benedetto <salvatore.benedetto@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Salvatore Benedetto 提交于
* Implement MPI based Diffie-Hellman under kpp API * Test provided uses data generad by OpenSSL Signed-off-by: NSalvatore Benedetto <salvatore.benedetto@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Salvatore Benedetto 提交于
Add key-agreement protocol primitives (kpp) API which allows to implement primitives required by protocols such as DH and ECDH. The API is composed mainly by the following functions * set_secret() - It allows the user to set his secret, also referred to as his private key, along with the parameters known to both parties involved in the key-agreement session. * generate_public_key() - It generates the public key to be sent to the other counterpart involved in the key-agreement session. The function has to be called after set_params() and set_secret() * generate_secret() - It generates the shared secret for the session Other functions such as init() and exit() are provided for allowing cryptographic hardware to be inizialized properly before use Signed-off-by: NSalvatore Benedetto <salvatore.benedetto@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 20 6月, 2016 1 次提交
-
-
由 Jeff Garzik 提交于
This patch adds the implementation of SHA3 algorithm in software and it's based on original implementation pushed in patch https://lwn.net/Articles/518415/ with additional changes to match the padding rules specified in SHA-3 specification. Signed-off-by: NJeff Garzik <jgarzik@redhat.com> Signed-off-by: NRaveendra Padasalagi <raveendra.padasalagi@broadcom.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 15 6月, 2016 1 次提交
-
-
由 Stephan Mueller 提交于
The CTR DRBG derives its random data from the CTR that is encrypted with AES. This patch now changes the CTR DRBG implementation such that the CTR AES mode is employed. This allows the use of steamlined CTR AES implementation such as ctr-aes-aesni. Unfortunately there are the following subtile changes we need to apply when using the CTR AES mode: - the CTR mode increments the counter after the cipher operation, but the CTR DRBG requires the increment before the cipher op. Hence, the crypto_inc is applied to the counter (drbg->V) once it is recalculated. - the CTR mode wants to encrypt data, but the CTR DRBG is interested in the encrypted counter only. The full CTR mode is the XOR of the encrypted counter with the plaintext data. To access the encrypted counter, the patch uses a NULL data vector as plaintext to be "encrypted". Signed-off-by: NStephan Mueller <smueller@chronox.de> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 05 5月, 2016 1 次提交
-
-
由 Tadeusz Struk 提交于
The pkcs1pad template needs CRYPTO_MANAGER so it needs to be explicitly selected by CRYPTO_RSA. Reported-by: NJamie Heilman <jamie@audible.transient.net> Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 01 2月, 2016 1 次提交
-
-
由 Baolin Wang 提交于
Now block cipher engines need to implement and maintain their own queue/thread for processing requests, moreover currently helpers provided for only the queue itself (in crypto_enqueue_request() and crypto_dequeue_request()) but they don't help with the mechanics of driving the hardware (things like running the request immediately, DMA map it or providing a thread to process the queue in) even though a lot of that code really shouldn't vary that much from device to device. Thus this patch provides a mechanism for pushing requests to the hardware as it becomes free that drivers could use. And this framework is patterned on the SPI code and has worked out well there. (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/ drivers/spi/spi.c?id=ffbbdd21) Signed-off-by: NBaolin Wang <baolin.wang@linaro.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 27 1月, 2016 2 次提交
-
-
由 Arnd Bergmann 提交于
When building the jitterentropy driver by itself, we get a link error when CRYPTO_RNG is not enabled as well: crypto/built-in.o: In function `jent_mod_init': jitterentropy-kcapi.c:(.init.text+0x98): undefined reference to `crypto_register_rng' crypto/built-in.o: In function `jent_mod_exit': jitterentropy-kcapi.c:(.exit.text+0x60): undefined reference to `crypto_unregister_rng' This adds a 'select CRYPTO_RNG' to CRYPTO_JITTERENTROPY to ensure the API is always there when it's used, not just when DRBG is also enabled. CRYPTO_DRBG would set it implicitly through CRYPTO_JITTERENTROPY now, but this leaves it in place to make it explicit what the driver does. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Joonsoo Kim 提交于
It is unused now, so remove it. Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 26 1月, 2016 1 次提交
-
-
由 Arnd Bergmann 提交于
The ghash and poly1305 hash implementations can be enabled when CONFIG_CRYPTO_HASH is turned off, causing a link error: crypto/built-in.o: In function `ghash_mod_init': (.init.text+0xd0): undefined reference to `crypto_register_shash' crypto/built-in.o: In function `ghash_mod_exit': (.exit.text+0xb4): undefined reference to `crypto_unregister_shash' crypto/built-in.o: In function `poly1305_mod_init': (.init.text+0xb4): undefined reference to `crypto_register_shash' crypto/built-in.o: In function `poly1305_mod_exit': (.exit.text+0x98): undefined reference to `crypto_unregister_shash' This adds an explicit 'select', like all other hashes have it. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 15 10月, 2015 1 次提交
-
-
由 Stephan Mueller 提交于
Hook keywrap source code into Kconfig and Makefile Signed-off-by: NStephan Mueller <smueller@chronox.de> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 21 9月, 2015 1 次提交
-
-
由 tim 提交于
This patch provides the configuration and build support to include and build the optimized SHA1 and SHA256 update transforms for the kernel's crypto library. Originally-by: NChandramouli Narayanan <mouli_7982@yahoo.com> Signed-off-by: NTim Chen <tim.c.chen@linux.intel.com> Acked-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 17 8月, 2015 2 次提交
-
-
由 Herbert Xu 提交于
This patch adds a missing tristate statement to Kconfig for the new CRYPTO_NULL2 option. Fixes: 149a3971 ("crypto: aead - Add type-safe geniv init/exit helpers") Reported-by: NStephan Mueller <smueller@chronox.de> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Herbert Xu 提交于
This patch adds the helpers aead_init_geniv and aead_exit_geniv which are type-safe and intended the replace the existing geniv init/exit helpers. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 14 8月, 2015 1 次提交
-
-
由 David Howells 提交于
Move certificate handling out of the kernel/ directory and into a certs/ directory to get all the weird stuff in one place and move the generated signing keys into this directory. Signed-off-by: NDavid Howells <dhowells@redhat.com> Reviewed-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 05 8月, 2015 1 次提交
-
-
由 Herbert Xu 提交于
CRYPTO_AUTHENC needs to depend on CRYPTO_NULL as authenc uses null for copying. Reported-by: NReported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 17 7月, 2015 4 次提交
-
-
由 Martin Willi 提交于
Extends the x86_64 Poly1305 authenticator by a function processing four consecutive Poly1305 blocks in parallel using AVX2 instructions. For large messages, throughput increases by ~15-45% compared to two block SSE2: testing speed of poly1305 (poly1305-simd) test 0 ( 96 byte blocks, 16 bytes per update, 6 updates): 3809514 opers/sec, 365713411 bytes/sec test 1 ( 96 byte blocks, 32 bytes per update, 3 updates): 5973423 opers/sec, 573448627 bytes/sec test 2 ( 96 byte blocks, 96 bytes per update, 1 updates): 9446779 opers/sec, 906890803 bytes/sec test 3 ( 288 byte blocks, 16 bytes per update, 18 updates): 1364814 opers/sec, 393066691 bytes/sec test 4 ( 288 byte blocks, 32 bytes per update, 9 updates): 2045780 opers/sec, 589184697 bytes/sec test 5 ( 288 byte blocks, 288 bytes per update, 1 updates): 3711946 opers/sec, 1069040592 bytes/sec test 6 ( 1056 byte blocks, 32 bytes per update, 33 updates): 573686 opers/sec, 605812732 bytes/sec test 7 ( 1056 byte blocks, 1056 bytes per update, 1 updates): 1647802 opers/sec, 1740079440 bytes/sec test 8 ( 2080 byte blocks, 32 bytes per update, 65 updates): 292970 opers/sec, 609378224 bytes/sec test 9 ( 2080 byte blocks, 2080 bytes per update, 1 updates): 943229 opers/sec, 1961916528 bytes/sec test 10 ( 4128 byte blocks, 4128 bytes per update, 1 updates): 494623 opers/sec, 2041804569 bytes/sec test 11 ( 8224 byte blocks, 8224 bytes per update, 1 updates): 254045 opers/sec, 2089271014 bytes/sec testing speed of poly1305 (poly1305-simd) test 0 ( 96 byte blocks, 16 bytes per update, 6 updates): 3826224 opers/sec, 367317552 bytes/sec test 1 ( 96 byte blocks, 32 bytes per update, 3 updates): 5948638 opers/sec, 571069267 bytes/sec test 2 ( 96 byte blocks, 96 bytes per update, 1 updates): 9439110 opers/sec, 906154627 bytes/sec test 3 ( 288 byte blocks, 16 bytes per update, 18 updates): 1367756 opers/sec, 393913872 bytes/sec test 4 ( 288 byte blocks, 32 bytes per update, 9 updates): 2056881 opers/sec, 592381958 bytes/sec test 5 ( 288 byte blocks, 288 bytes per update, 1 updates): 3711153 opers/sec, 1068812179 bytes/sec test 6 ( 1056 byte blocks, 32 bytes per update, 33 updates): 574940 opers/sec, 607136745 bytes/sec test 7 ( 1056 byte blocks, 1056 bytes per update, 1 updates): 1948830 opers/sec, 2057964585 bytes/sec test 8 ( 2080 byte blocks, 32 bytes per update, 65 updates): 293308 opers/sec, 610082096 bytes/sec test 9 ( 2080 byte blocks, 2080 bytes per update, 1 updates): 1235224 opers/sec, 2569267792 bytes/sec test 10 ( 4128 byte blocks, 4128 bytes per update, 1 updates): 684405 opers/sec, 2825226316 bytes/sec test 11 ( 8224 byte blocks, 8224 bytes per update, 1 updates): 367101 opers/sec, 3019039446 bytes/sec Benchmark results from a Core i5-4670T. Signed-off-by: NMartin Willi <martin@strongswan.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Martin Willi 提交于
Implements an x86_64 assembler driver for the Poly1305 authenticator. This single block variant holds the 130-bit integer in 5 32-bit words, but uses SSE to do two multiplications/additions in parallel. When calling updates with small blocks, the overhead for kernel_fpu_begin/ kernel_fpu_end() negates the perfmance gain. We therefore use the poly1305-generic fallback for small updates. For large messages, throughput increases by ~5-10% compared to poly1305-generic: testing speed of poly1305 (poly1305-generic) test 0 ( 96 byte blocks, 16 bytes per update, 6 updates): 4080026 opers/sec, 391682496 bytes/sec test 1 ( 96 byte blocks, 32 bytes per update, 3 updates): 6221094 opers/sec, 597225024 bytes/sec test 2 ( 96 byte blocks, 96 bytes per update, 1 updates): 9609750 opers/sec, 922536057 bytes/sec test 3 ( 288 byte blocks, 16 bytes per update, 18 updates): 1459379 opers/sec, 420301267 bytes/sec test 4 ( 288 byte blocks, 32 bytes per update, 9 updates): 2115179 opers/sec, 609171609 bytes/sec test 5 ( 288 byte blocks, 288 bytes per update, 1 updates): 3729874 opers/sec, 1074203856 bytes/sec test 6 ( 1056 byte blocks, 32 bytes per update, 33 updates): 593000 opers/sec, 626208000 bytes/sec test 7 ( 1056 byte blocks, 1056 bytes per update, 1 updates): 1081536 opers/sec, 1142102332 bytes/sec test 8 ( 2080 byte blocks, 32 bytes per update, 65 updates): 302077 opers/sec, 628320576 bytes/sec test 9 ( 2080 byte blocks, 2080 bytes per update, 1 updates): 554384 opers/sec, 1153120176 bytes/sec test 10 ( 4128 byte blocks, 4128 bytes per update, 1 updates): 278715 opers/sec, 1150536345 bytes/sec test 11 ( 8224 byte blocks, 8224 bytes per update, 1 updates): 140202 opers/sec, 1153022070 bytes/sec testing speed of poly1305 (poly1305-simd) test 0 ( 96 byte blocks, 16 bytes per update, 6 updates): 3790063 opers/sec, 363846076 bytes/sec test 1 ( 96 byte blocks, 32 bytes per update, 3 updates): 5913378 opers/sec, 567684355 bytes/sec test 2 ( 96 byte blocks, 96 bytes per update, 1 updates): 9352574 opers/sec, 897847104 bytes/sec test 3 ( 288 byte blocks, 16 bytes per update, 18 updates): 1362145 opers/sec, 392297990 bytes/sec test 4 ( 288 byte blocks, 32 bytes per update, 9 updates): 2007075 opers/sec, 578037628 bytes/sec test 5 ( 288 byte blocks, 288 bytes per update, 1 updates): 3709811 opers/sec, 1068425798 bytes/sec test 6 ( 1056 byte blocks, 32 bytes per update, 33 updates): 566272 opers/sec, 597984182 bytes/sec test 7 ( 1056 byte blocks, 1056 bytes per update, 1 updates): 1111657 opers/sec, 1173910108 bytes/sec test 8 ( 2080 byte blocks, 32 bytes per update, 65 updates): 288857 opers/sec, 600823808 bytes/sec test 9 ( 2080 byte blocks, 2080 bytes per update, 1 updates): 590746 opers/sec, 1228751888 bytes/sec test 10 ( 4128 byte blocks, 4128 bytes per update, 1 updates): 301825 opers/sec, 1245936902 bytes/sec test 11 ( 8224 byte blocks, 8224 bytes per update, 1 updates): 153075 opers/sec, 1258896201 bytes/sec Benchmark results from a Core i5-4670T. Signed-off-by: NMartin Willi <martin@strongswan.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Martin Willi 提交于
Extends the x86_64 ChaCha20 implementation by a function processing eight ChaCha20 blocks in parallel using AVX2. For large messages, throughput increases by ~55-70% compared to four block SSSE3: testing speed of chacha20 (chacha20-simd) encryption test 0 (256 bit key, 16 byte blocks): 42249230 operations in 10 seconds (675987680 bytes) test 1 (256 bit key, 64 byte blocks): 46441641 operations in 10 seconds (2972265024 bytes) test 2 (256 bit key, 256 byte blocks): 33028112 operations in 10 seconds (8455196672 bytes) test 3 (256 bit key, 1024 byte blocks): 11568759 operations in 10 seconds (11846409216 bytes) test 4 (256 bit key, 8192 byte blocks): 1448761 operations in 10 seconds (11868250112 bytes) testing speed of chacha20 (chacha20-simd) encryption test 0 (256 bit key, 16 byte blocks): 41999675 operations in 10 seconds (671994800 bytes) test 1 (256 bit key, 64 byte blocks): 45805908 operations in 10 seconds (2931578112 bytes) test 2 (256 bit key, 256 byte blocks): 32814947 operations in 10 seconds (8400626432 bytes) test 3 (256 bit key, 1024 byte blocks): 19777167 operations in 10 seconds (20251819008 bytes) test 4 (256 bit key, 8192 byte blocks): 2279321 operations in 10 seconds (18672197632 bytes) Benchmark results from a Core i5-4670T. Signed-off-by: NMartin Willi <martin@strongswan.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Martin Willi 提交于
Implements an x86_64 assembler driver for the ChaCha20 stream cipher. This single block variant works on a single state matrix using SSE instructions. It requires SSSE3 due the use of pshufb for efficient 8/16-bit rotate operations. For large messages, throughput increases by ~65% compared to chacha20-generic: testing speed of chacha20 (chacha20-generic) encryption test 0 (256 bit key, 16 byte blocks): 45089207 operations in 10 seconds (721427312 bytes) test 1 (256 bit key, 64 byte blocks): 43839521 operations in 10 seconds (2805729344 bytes) test 2 (256 bit key, 256 byte blocks): 12702056 operations in 10 seconds (3251726336 bytes) test 3 (256 bit key, 1024 byte blocks): 3371173 operations in 10 seconds (3452081152 bytes) test 4 (256 bit key, 8192 byte blocks): 422468 operations in 10 seconds (3460857856 bytes) testing speed of chacha20 (chacha20-simd) encryption test 0 (256 bit key, 16 byte blocks): 43141886 operations in 10 seconds (690270176 bytes) test 1 (256 bit key, 64 byte blocks): 46845874 operations in 10 seconds (2998135936 bytes) test 2 (256 bit key, 256 byte blocks): 18458512 operations in 10 seconds (4725379072 bytes) test 3 (256 bit key, 1024 byte blocks): 5360533 operations in 10 seconds (5489185792 bytes) test 4 (256 bit key, 8192 byte blocks): 692846 operations in 10 seconds (5675794432 bytes) Benchmark results from a Core i5-4670T. Signed-off-by: NMartin Willi <martin@strongswan.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 21 6月, 2015 1 次提交
-
-
由 Tadeusz Struk 提交于
Should be CRYPTO_AKCIPHER instead of AKCIPHER Reported-by: NAndreas Ruprecht <andreas.ruprecht@fau.de> Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 17 6月, 2015 3 次提交
-
-
由 Tadeusz Struk 提交于
New test vectors for RSA algorithm. Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Tadeusz Struk 提交于
Add a new rsa generic SW implementation. This implements only cryptographic primitives. Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com> Added select on ASN1. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Tadeusz Struk 提交于
Add Public Key Encryption API. Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com> Made CRYPTO_AKCIPHER invisible like other type config options. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 11 6月, 2015 1 次提交
-
-
由 Herbert Xu 提交于
The hash-based DRBG variants all use sha256 so we need to add a select on it. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-