aboutsummaryrefslogtreecommitdiffstats
path: root/checks/validate.dat
Commit message (Collapse)AuthorAgeFilesLines
* Add 3 more tests of Tiger, test vectors via Crypto++lloyd2010-08-231-0/+20
|
* When creating a PBKDF2, first check if the argument name is a knownlloyd2010-08-211-0/+5
| | | | | | | | | | | | | MAC. If it is, use it as the PRF. Otherwise assume it is a hash function and use it with HMAC. Instead of instantiating the HMAC directly, go through the algorithm factory. Add a test using PBKDF2 with CMAC(Blowfish); Blowfish mainly because it supports arbitrarily large keys, and also the required 4 KiB of sbox tables actually would make it fairly useful in that it would make cracking using hardware or GPUs rather expensive. Have not confirmed this vector against any other implementation because I don't know of any other implementation of PBKDF2 that supports MACs other than HMAC.
* Turns out OpenSSL's implementation of PBKDF2 allows empty passphrases,lloyd2010-08-211-0/+4
| | | | | | | | | | | | | | | | | so for compatability with keys that were encrypted with an empty passphrase we probably want to support it as well. In PBKDF2, don't reject empty passphrases out of hand; simply call set_key and if the underlying MAC cannot use the key, throw an informative exception. This will also be more helpful in the case that someone tries using another MAC (say, CMAC) with a block cipher that only supports keys of specific sizes. In HMAC, allow zero-length keys. This is not really optimal in the sense of allowing the user to do something dumb, but a 1 byte key would be pretty dumb as well and we already allowed that. Add a test vector using an empty passphrase generated by OpenSSL
* Rename S2K to PBKDF, because that is by far the most common name - S2Klloyd2010-07-091-5/+5
| | | | | | | | | | | | | really is only used by OpenPGP, and largely it was named S2K here because the OpenPGP S2K was implemented years before the ones in PKCS #5. We have a typedef of PBKDF to S2K, and an inlined get_s2k that calls get_pbkdf for source compatability. There doesn't seem to be any reason to have a forward for the renamed s2k.h header - to actually use a PBKDF, you'd have to either include lookup.h and call get_s2k / get_pbkdf, or else include an algorithm-specific header and use it directly. In either case, including s2k.h is neither necessary nor sufficient.
* Remove FORK-256; it's obscure and has been definitively broken.lloyd2010-05-251-935/+0
| | | | | More commentary posted to the list: http://lists.randombit.net/pipermail/botan-devel/2010-May/001123.html
* Another XTEA vectorlloyd2010-05-101-0/+1
|
* Modify the implementation of multiplication mod 65537 used in IDEA tolloyd2010-04-301-0/+520
| | | | | | | | | | be branch-free. This reduces performance noticably on my Core2 (from 32 MiB/s to a bit over 27 MiB), but so it goes. The IDEA implementation using SSE2 is already branch-free here, and runs at about 135 MiB/s on my machine. Also add more IDEA tests, generated by OpenSSL
* Add a couple of Comb4P tests, generated by the python implementationlloyd2010-04-231-0/+9
|
* Add XSalsa20lloyd2010-03-031-0/+82
|
* Add a set of test vectors for 3DES in counter mode generated bylloyd2010-01-291-0/+2746
| | | | | Crypto++ 5.6.0. Includes several largeish (64 and 128 block) tests, as further tests for a future bitslice implementation.
* Add a set of XTS tests using TripleDES; XTS mode supports either a 64-bitlloyd2010-01-281-0/+1408
| | | | | | | | | | or 128-bit cipher, but so far only 128-bit ciphers had been tested. I could not find another implementation of XTS supporting 3DES so these may be wrong, but at least this ensures they will be consistently wrong. Mostly in the smaller range (9 to 128 bytes) plus a few with large inputs (64 blocks) because if a bitslice DES implementation is ever added a test that actually does 64 blocks in parallel will be needed.
* Fix several buffering problems in the XTS implementation that wouldlloyd2010-01-251-0/+7110
| | | | | | | | | | | | | cause bad results if the input was not an even multiple of the block size. No released version was broken because the changes which caused the problem were related to using Buffered_Filter, which was introduced after 1.9.3 was released. Add more XTS test vectors using AES, Serpent, and Twofish. The AES tests come from Brian Gladman's XTS implementation. The Serpent and Twofish tests were generated by botan.
* Add SIMD version of Noekeon. On a Core2, about 2.7x faster using SIMD_SSE2lloyd2010-01-121-0/+2021
| | | | and 1.6x faster using SIMD_Scalar.
* Add block cipher cascadelloyd2010-01-111-0/+46
|
* Split AES tests by key length for AES-NIlloyd2010-01-051-44/+45
|
* Specific large tests for AES-128 to hit engineslloyd2010-01-041-3/+7
|
* Add last nights project, an SSE2 implementation of IDEA. Right about 4xlloyd2009-12-231-0/+17
| | | | faster than the scalar version on a Core2.
* Split the AES vectors into 3 specifically named AES-128, AES-192, andlloyd2009-11-101-1651/+1650
| | | | | | AES-256 blocks, plus a handful remaining in a general AES block. This is necessary for any implementation which only supports a particular key size, since otherwise no tests at all will run on that implementation.
* Add TEA and XTEA ECB vectorslloyd2009-10-231-0/+650
|
* Add test vectors for TEA and XTEA in CTR modelloyd2009-10-231-0/+1242
|
* Convert CTR_BE from a Filter to a StreamCipher. Must wrap in a ↵lloyd2009-10-141-0/+7
| | | | | | StreamCipher_Filter to pass it directly to a Pipe now.
* Use the new selftest framework for testing hashes, MACs, and ciphers.lloyd2009-10-071-1217/+36
| | | | | | Remove the Decrypt direction cipher mode tests - now both directions are always tested for all modes. Also add IVs for Salsa20 (were implicit all-zeros) since that does not fly anymore in validate.dat
* Remove redundant SHA-1 test vector of empty inputlloyd2009-09-221-1/+0
|
* Add 4 test vectors for HMAC(BMW-512)lloyd2009-09-211-0/+41
|
* Update the implementation of Blue Midnight Wish to use the Round 2 tweakedlloyd2009-09-211-512/+1122
| | | | version.
* Add an implementation of Blue Midnight Wish (512 bit version only)lloyd2009-09-151-0/+1914
|
* propagate from branch 'net.randombit.botan.1_8' (head ↵lloyd2009-09-151-0/+822
|\ | | | | | | | | | | ef51dd2869ed38dae3aeb1c3b931ca9d595580e1) to branch 'net.randombit.botan' (head fc1942640045423f411fd865cbd584090b28d7eb)
| * Add a couple of Serpent/XTS test vectors (SQLite data pages)lloyd2009-09-101-0/+273
| |
| * Add some longer Serpent CTR vectorslloyd2009-08-121-0/+460
| |
| * Modify Keyed_Filter so it is a pure interfacelloyd2009-08-111-0/+89
| | | | | | | | | | | | | | | | | | | | Modify ECB to use parallel encryption/decryption where possible Add toggles in build.h specifying how many blocks to process in parallel. Defaults to 8 blocks for all modes, which is sufficient that any likely parallelism can be extracted (via SIMD or concurrent execution) but not so much as to seem likely to cause cache problems (8*128 bits = 128 bytes, or two x86 cache lines)
* | Change Skein-512 to match the tweaked 1.2 specification. Round constantslloyd2009-09-151-18454/+1637
|/ | | | in the Threefish cipher have changed to increase diffusion.
* Add a set of Serpent/CTR tests. The primary reason for this is becauselloyd2009-08-101-0/+541
| | | | | Serpent seems very nicely suited to a SSE2 SIMD implementation, and CTR mode can handle multiple blocks in parallel. Input lens 1 to 128 bytes.
* Mark Skein_512 with the BOTAN_DLL macrolloyd2009-06-061-2/+21
| | | | | | | | | | | | | | Add a comment that the limitation of the personalization string being a maximum of 64 characters is due to the implementation and not the specification (but it makes it easy to implement, and in this particular case 64 characters is probably fine). Add some tests for the personalization option, generated by the Skein reference implementation. Disable stripping whitespace in checks/misc.cpp:strip - it strips the personalization tag, which breaks the test, and isn't needed otherwise because the test files are well-formed.
* Add an implementation of Skein-512lloyd2009-06-021-0/+26444
|
* Add XTS mode, from IEEE P1619lloyd2009-04-161-0/+367
|
* Add the GOST 34.11 hash function. Pretty slow, but functional.lloyd2009-04-071-0/+70
|
* Add a set of test vectors for GOST 28147-89 using the CryptoPro paramslloyd2009-04-011-0/+32
| | | | commonly used for the GOST 34.11 hash, generated by OpenSSL's GOST code.
* Use the full name for the GOST test vectorslloyd2009-03-311-1/+1
|
* GOST was using a completely non-standard set of sboxes. Change it to uselloyd2009-03-271-20/+59
| | | | | | | | | | | | | | | GostR3411_94_TestParamSet, this is compatible with the implementations in Crypto++ and OpenSSL. This is not backwards compatible, though once the implementation supports multiple param sets (which is required, unfortunately, for compatability with various standards by CryptoCom, who have defined not one but at least 4 (!!!) different sboxes to use with GOST), I may offer Botan's previous sbox set as an option. Since adding the GOST hash function (34.11) and signing algorithm (34.10) are on the long term agenda (request by Rickard Bondesson, as the Russian authorities want to use their local standards for their DNSSEC use), I renamed the block cipher class (which had been just 'GOST') to GOST_28147_89 to minimize future name clashes.
* Add a few test vectors for SHA-1 with longer inputslloyd2008-11-231-0/+129
|
* Another check for Parallel matching TLS.Digest.0 checklloyd2008-11-101-0/+3
|
* Remove stray textlloyd2008-10-281-1/+0
|
* Add a CBC-MAC/AES test vector from Bounce Castle via InSiTo's cbcmac_tests.cpplloyd2008-10-141-0/+6
|
* Add SHA-224 from InSiTo, written and (C) by FlexSecure GmbHlloyd2008-10-081-0/+5
| | | | | Rename sha256.h and sha_64.h to sha2_32.h and sha2_64.h - this affects users who instantiate these classes directly.
* Add back from Ajisai 0.5.0 the implementations of the SSLv3 MAC and PRFlloyd2008-09-271-0/+240
| | | | | | | | | | | and the TLS v1.0 PRF. These were removed from Botan in v1.4.5. Initially I had felt that since these protocols were specific to SSL/TLS they should be placed in Ajisai (an SSL/TLS library based on Botan). However upon further reflection I have realized it is quite possible that other alternate implementations of SSL/TLS based on Botan would be quite desirable, and so to make that (a very slightly bit) easier I am adding back the SSL/TLS functions to Botan, so other SSL/TLS libs can use them directly.
* Add implementation of Salsa20 stream cipherlloyd2008-09-091-0/+280
|
* Add the block cipher Noekeon (http://gro.noekeon.org/). Only "indirect mode"lloyd2008-07-111-1/+12
| | | | keying is supported (see section 2.3 of the specification for details)
* Add a full set of tests for the ANSI X9.31 PRNG, using data takenlloyd2008-06-071-0/+2059
| | | | | | | | from the NIST CAVS dataset, taken on June 7 2008 from http://csrc.nist.gov/groups/STM/cavp/standards.html AES-128, AES-192, AES-256, and 2 and 3-key TripleDES variants are all tested.
* Add CBC-MAC(AES) tests that use longer inputslloyd2007-09-171-1/+85
|
* Check in an initial implementation of CBC-MAC.lloyd2007-09-161-136/+136
| | | | | | | The test vectors were generated by Crypto++ 5.5 on a Linux/x86-64 machine. Test vectors for CBC-MAC(DES) all pass, for inputs up to 63 bytes. For CBC-MAC(AES-128), all test vectors with inputs over 10 bytes fail to verify against what Crypto++ produces. Unknown at this time where the bug lies.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 19:37:55 +0000