- 10 Jan, 2008 10 commits
-
-
Zoltan Sogor authored
Add LZO compression algorithm support Signed-off-by:
Zoltan Sogor <weth@inf.u-szeged.hu> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Tan Swee Heng authored
This is a large test vector for Salsa20 that crosses the 4096-bytes page boundary. Signed-off-by:
Tan Swee Heng <thesweeheng@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
The crypto_aead convention for ICVs is to include it directly in the output. If we decided to change this in future then we would make the ICV (if the algorithm has an explicit one) available in the request itself. For now no algorithm needs this so this patch changes gcm to conform to this convention. It also adjusts the tcrypt aead tests to take this into account. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Jan Glauber authored
Add test vectors to tcrypt for AES in CBC mode for key sizes 192 and 256. The test vectors are copied from NIST SP800-38A. Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Tan Swee Heng authored
This patch adds a large AES CTR mode test vector. The test vector is 4100 bytes in size. It was generated using a C++ program that called Crypto++. Note that this patch increases considerably the size of "struct cipher_testvec" and hence the size of tcrypt.ko. Signed-off-by:
Tan Swee Heng <thesweeheng@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Mikko Herranen authored
Add GCM/GMAC support to cryptoapi. GCM (Galois/Counter Mode) is an AEAD mode of operations for any block cipher with a block size of 16. The typical example is AES-GCM. Signed-off-by:
Mikko Herranen <mh1@iki.fi> Reviewed-by:
Mika Kukkonen <mika.kukkonen@nsn.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Mikko Herranen authored
Add AEAD support to tcrypt, needed by GCM. Signed-off-by:
Mikko Herranen <mh1@iki.fi> Reviewed-by:
Mika Kukkonen <mika.kukkonen@nsn.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Tan Swee Heng authored
This patch implements the Salsa20 stream cipher using the blkcipher interface. The core cipher code comes from Daniel Bernstein's submission to eSTREAM: http://www.ecrypt.eu.org/stream/svn/viewcvs.cgi/ecrypt/trunk/submissions/salsa20/full/ref/ The test vectors comes from: http://www.ecrypt.eu.org/stream/svn/viewcvs.cgi/ecrypt/trunk/submissions/salsa20/full/ It has been tested successfully with "modprobe tcrypt mode=34" on an UML instance. Signed-off-by:
Tan Swee Heng <thesweeheng@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Jonathan Lynch authored
Resubmitting this patch which extends sha256_generic.c to support SHA-224 as described in FIPS 180-2 and RFC 3874. HMAC-SHA-224 as described in RFC4231 is then supported through the hmac interface. Patch includes test vectors for SHA-224 and HMAC-SHA-224. SHA-224 chould be chosen as a hash algorithm when 112 bits of security strength is required. Patch generated against the 2.6.24-rc1 kernel and tested against 2.6.24-rc1-git14 which includes fix for scatter gather implementation for HMAC. Signed-off-by:
Jonathan Lynch <jonathan.lynch@intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Joy Latten authored
This patch implements CTR mode for IPsec. It is based off of RFC 3686. Please note: 1. CTR turns a block cipher into a stream cipher. Encryption is done in blocks, however the last block may be a partial block. A "counter block" is encrypted, creating a keystream that is xor'ed with the plaintext. The counter portion of the counter block is incremented after each block of plaintext is encrypted. Decryption is performed in same manner. 2. The CTR counterblock is composed of, nonce + IV + counter The size of the counterblock is equivalent to the blocksize of the cipher. sizeof(nonce) + sizeof(IV) + sizeof(counter) = blocksize The CTR template requires the name of the cipher algorithm, the sizeof the nonce, and the sizeof the iv. ctr(cipher,sizeof_nonce,sizeof_iv) So for example, ctr(aes,4,8) specifies the counterblock will be composed of 4 bytes from a nonce, 8 bytes from the iv, and 4 bytes for counter since aes has a blocksize of 16 bytes. 3. The counter portion of the counter block is stored in big endian for conformance to rfc 3686. Signed-off-by:
Joy Latten <latten@austin.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 10 Oct, 2007 2 commits
-
-
Rik Snel authored
XTS currently considered to be the successor of the LRW mode by the IEEE1619 workgroup. LRW was discarded, because it was not secure if the encyption key itself is encrypted with LRW. XTS does not have this problem. The implementation is pretty straightforward, a new function was added to gf128mul to handle GF(128) elements in ble format. Four testvectors from the specification http://grouper.ieee.org/groups/1619/email/pdf00086.pdf were added, and they verify on my system. Signed-off-by:
Rik Snel <rsnel@cube.dyndns.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Hye-Shik Chang authored
This patch adds support for the SEED cipher (RFC4269). This patch have been used in few VPN appliance vendors in Korea for several years. And it was verified by KISA, who developed the algorithm itself. As its importance in Korean banking industry, it would be great if linux incorporates the support. Signed-off-by:
Hye-Shik Chang <perky@FreeBSD.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 06 Feb, 2007 3 commits
-
-
Noriaki TAKAMIYA authored
This patch adds the code of Camellia code for testing module. Signed-off-by:
Noriaki TAKAMIYA <takamiya@po.ntts.co.jp> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
David Howells authored
Add a crypto module to provide FCrypt encryption as used by RxRPC. Signed-Off-By:
David Howells <dhowells@redhat.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Andrew Donofrio authored
This patch adds tests for SHA384 HMAC and SHA512 HMAC to the tcrypt module. Test data was taken from RFC4231. This patch is a follow-up to the discovery (bug 7646) that the kernel SHA384 HMAC implementation was not generating proper SHA384 HMACs. Signed-off-by:
Andrew Donofrio <linuxbugzilla@kriptik.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 07 Dec, 2006 2 commits
-
-
Rik Snel authored
Do modprobe tcrypt mode=10 to check the included test vectors, they are from: http://grouper.ieee.org/groups/1619/email/pdf00017.pdf and from http://www.mail-archive.com/stds-p1619@listserv.ieee.org/msg00173.html . To make the last test vector fit, I had to increase the buffer size of input and result to 512 bytes. Signed-off-by:
Rik Snel <rsnel@cube.dyndns.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Kazunori MIYAZAWA authored
est vectors of XCBC with AES-128. Signed-off-by:
Kazunori MIYAZAWA <miyazawa@linux-ipv6.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 21 Sep, 2006 2 commits
-
-
Herbert Xu authored
This patch converts tcrypt to use the new HMAC template rather than the hard-coded version of HMAC. It also converts all digest users to use the new cipher interface. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
Now that crc32c has been fixed to conform with standard digest semantics, we can use test_hash for it. I've turned the last test into a chunky test. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 26 Jun, 2006 1 commit
-
-
Michal Ludvig authored
This patch adds speed tests (benchmarks) for digest algorithms. Tests are run with different buffer sizes (16 bytes, ... 8 kBytes) and with each buffer multiple tests are run with different update() sizes (e.g. hash 64 bytes buffer in four 16 byte updates). There is no correctness checking of the result and all tests and algorithms use the same input buffer. Signed-off-by:
Michal Ludvig <michal@logix.cz> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 21 Mar, 2006 1 commit
-
-
Atsushi Nemoto authored
Force 32-bit alignment on keys in tcrypt test vectors. Also rearrange the structure to prevent unnecessary padding. Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 06 Jan, 2006 1 commit
-
-
Jan Glauber authored
Add new test vectors to the AES test suite for AES CBC and AES with plaintext larger than AES blocksize. Signed-off-by:
Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 02 Sep, 2005 1 commit
-
-
Aaron Grothe authored
The XTEA implementation was incorrect due to a misinterpretation of operator precedence. Because of the wide-spread nature of this error, the erroneous implementation will be kept, albeit under the new name of XETA. Signed-off-by:
Aaron Grothe <ajgrothe@yahoo.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 22 Jun, 2005 2 commits
-
-
Harald Welte authored
From: Reyk Floeter <reyk@vantronix.net> I recently had the requirement to do some benchmarking on cryptoapi, and I found reyk's very useful performance test patch [1]. However, I could not find any discussion on why that extension (or something providing a similar feature but different implementation) was not merged into mainline. If there was such a discussion, can someone please point me to the archive[s]? I've now merged the old patch into 2.6.12-rc1, the result can be found attached to this email. [1] http://lists.logix.cz/pipermail/padlock/2004/000010.html Signed-off-by:
Harald Welte <laforge@gnumonks.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Herbert Xu authored
Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 16 Apr, 2005 1 commit
-
-
Linus Torvalds authored
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-