| Age | Commit message (Collapse) | Author |
|---|
|
Currently if you speed test a hash that requires a key you'll get an
error because tcrypt does not set a key by default. This patch
allows a key to be set using the new module parameter klen.
Signed-off-by: Herbert Xu <[email protected]>
|
|
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Add additional test vectors from "The SM4 Blockcipher Algorithm And Its
Modes Of Operations" draft-ribose-cfrg-sm4-10 and register cipher speed
tests for sm4.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Adds individual ChaCha20 and Poly1305 and a combined rfc7539esp AEAD speed
test using mode numbers 214, 321 and 213. For Poly1305 we add a specific
speed template, as it expects the key prepended to the input data.
Signed-off-by: Martin Willi <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This patch adds a speed test for rfc4309(ccm(aes)) as mode 212.
Signed-off-by: Herbert Xu <[email protected]>
|
|
suite
Adding simple speed tests for a range of block sizes for AEAD crypto
algorithms.
Signed-off-by: Tim Chen <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Some hardware crypto drivers register asynchronous ctr(aes), which is left
unused in IPSEC because rfc3686 template only supports synchronous block
ciphers. Some other drivers register rfc3686(ctr(aes)) to workaround this
limitation but not all.
This patch changes rfc3686 to use asynchronous block ciphers, to allow async
ctr(aes) algorithms to be utilized automatically by IPSEC.
Signed-off-by: Jussi Kivilinna <[email protected]>
Acked-by: Herbert Xu <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
|
|
New ECB, CBC and CTR testvectors for cast5. 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: Johannes Goetzfried <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Signed-off-by: Jussi Kivilinna <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Signed-off-by: Jussi Kivilinna <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Because ghash needs setkey, the setkey and keysize template support
for test_hash_speed is added.
Signed-off-by: Huang Ying <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This patch moves the newly created alg_test infrastructure into
cryptomgr. This shall allow us to use it for testing at algorithm
registrations.
Signed-off-by: Herbert Xu <[email protected]>
|
|
If tcrypt is to be used as a run-time integrity test, it needs to be
more resilient in a hostile environment. For a start allocating 32K
of physically contiguous memory is definitely out.
This patch teaches it to use separate pages instead.
Signed-off-by: Herbert Xu <[email protected]>
|
|
Patch to add checking of DES3 test vectors using CBC mode. FIPS-140-2
compliance mandates that any supported mode of operation must include a self
test. This satisfies that requirement for cbc(des3_ede). The included test
vector was generated by me using openssl. Key/IV was generated with the
following command:
openssl enc -des_ede_cbc -P
input and output values were generated by repeating the string "Too many
secrets" a few times over, truncating it to 128 bytes, and encrypting it with
openssl using the aformentioned key. Tested successfully by myself
Signed-off-by: Neil Horman <[email protected]>
Acked-by: Adrian-Ken Rueegsegger <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This patch adds test vectors for RIPEMD-256 and
RIPEMD-320 hash algorithms.
The test vectors are taken from
<http://homes.esat.kuleuven.be/~bosselae/ripemd160.html>
Signed-off-by: Adrian-Ken Rueegsegger <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Change logs should be kept in source control systems, not the source.
This patch removes the change log from tcrpyt to stop people from
extending it any more.
Signed-off-by: Herbert Xu <[email protected]>
|
|
This patch adds test vectors for RIPEMD-128 and
RIPEMD-160 hash algorithms and digests (HMAC).
The test vectors are taken from ISO:IEC 10118-3 (2004)
and RFC2286.
Signed-off-by: Adrian-Ken Rueegsegger <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Implement CTS wrapper for CBC mode required for support of AES
encryption support for Kerberos (rfc3962).
Signed-off-by: Kevin Coffman <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The third test vector of ECB-XTEA-ENC fails for me all other
are fine. I could not find a RFC or something else where they
are defined. The test vector has not been modified since git
started recording histrory. The implementation is very close
(not to say equal) to what is available as Public Domain (they
recommend 64 rounds and the in kernel uses 32). Therefore I
belive that there is typo somewhere and tcrypt reported always
*fail* instead of *okey*.
This patch replaces input + result of the third test vector with
result + input from the third decryption vector. The key is the
same, the other three test vectors are also the reverse.
Signed-off-by: Sebastian Siewior <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Currently the tcrypt module is about 2 MiB on x86-32. The
main reason for the huge size is the data segment which contains
all the test vectors for each algorithm. The test vectors are
staticly allocated in an array and the size of the array has been
drastically increased by the merge of the Salsa20 test vectors.
With a hint from Benedigt Spranger I found a way how I could
convert those fixed-length arrays to strings which are flexible
in size. VIM and regex were also very helpfull :)
So, I am talking about a shrinking of ~97% on x86-32:
text data bss dec hex filename
18309 2039708 20 2058037 1f6735 tcrypt-b4.ko
45628 23516 80 69224 10e68 tcrypt.ko
Signed-off-by: Sebastian Siewior <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The speed templates as it look always the same. The key size
is repeated for each block size and we test always the same
block size. The addition of one inner loop makes it possible
to get rid of the struct and it is possible to use a tiny
u8 array :)
Signed-off-by: Sebastian Siewior <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Some crypto ciphers which are impleneted support similar key sizes
(16,24 & 32 byte). They can be grouped together and use a common
templatte instead of their own which contains the same data.
Signed-off-by: Sebastian Siewior <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This patch adds 7 test vectors to tcrypt for CCM.
The test vectors are from rfc 3610.
There are about 10 more test vectors in RFC 3610
and 4 or 5 more in NIST. I can add these as time permits.
I also needed to set authsize. CCM has a prerequisite of
authsize.
Signed-off-by: Joy Latten <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This patch adds a simple speed test for salsa20.
Usage: modprobe tcrypt mode=206
Signed-of-by: Tan Swee Heng <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add LZO compression algorithm support
Signed-off-by: Zoltan Sogor <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This is a large test vector for Salsa20 that crosses the 4096-bytes
page boundary.
Signed-off-by: Tan Swee Heng <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Mika Kukkonen <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add AEAD support to tcrypt, needed by GCM.
Signed-off-by: Mikko Herranen <[email protected]>
Reviewed-by: Mika Kukkonen <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This patch adds the code of Camellia code for testing module.
Signed-off-by: Noriaki TAKAMIYA <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add a crypto module to provide FCrypt encryption as used by RxRPC.
Signed-Off-By: David Howells <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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/[email protected]/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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
est vectors of XCBC with AES-128.
Signed-off-by: Kazunori MIYAZAWA <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Force 32-bit alignment on keys in tcrypt test vectors. Also rearrange the
structure to prevent unnecessary padding.
Signed-off-by: Atsushi Nemoto <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
From: Reyk Floeter <[email protected]>
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
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!
|
