aboutsummaryrefslogtreecommitdiffstats
path: root/checks/validate.dat
Commit message (Collapse)AuthorAgeFilesLines
* Split up tests by typelloyd2013-12-311-69590/+0
|
* Provide Threefish as a block cipher, add decryptionlloyd2013-12-251-0/+6
|
* Generalize file reading test runner, use it for KDF and PBKDFlloyd2013-11-181-585/+2
|
* Add CCM modelloyd2013-09-051-0/+35
|
* Add long input OCB testslloyd2013-08-261-0/+289
|
* Rename ARC4 to RC4lloyd2013-04-191-1/+1
|
* Add more OCB test vectorslloyd2013-03-271-0/+69
|
* Allow tag sizes other than 128 bits in GCM and OCBlloyd2013-03-271-0/+4
|
* Remove the Turing and WiderWAKE4+1 stream cipher implementations.lloyd2013-03-191-1706/+0
| | | | Both never saw much deployment or analysis.
* Working GCM. Add support for AEAD modes in self testslloyd2013-03-161-8/+83
|
* Some work towards a (very slow) GCM implementationlloyd2013-03-161-0/+15
| | | | | Does not currently work due to some error in ghash, likely a misunderstanding of the field representation.
* OCB decryptionlloyd2013-03-141-0/+17
|
* Add new PBKDF interface that takes a std::chrono::milliseconds andlloyd2012-05-311-31/+0
| | | | | | | | | | | | | | | | | | | | runs the KDF until at least that much time has passed, then returns the number of interations used. New parameter to the PKCS8 encryption routines which tells how long to run the PBKDF. Defaults to 200 milliseconds, which is short enough that it is unlikely to bother anyone but long enough to provide quite reasonable security against cracking attacks. On a Core i7-860, 200 ms with PBKDF2/SHA-1 runs about 180K to 220K iterations (compare with previous default of 10K). New PBE interface, remove new_params/set_key and require all inputs including the passphrase to be passed to the constructor. Drop the PGP S2K as it is pretty weird and not really useful outside of a full PGP implementation. Drop the deprecated PKCS8::encrypt_key and PKCS8::encode functions.
* propagate from branch 'net.randombit.botan' (head ↵lloyd2012-05-181-0/+37
|\ | | | | | | | | | | 6332543aa5a8a4cc13662008ff9ac0f0016d9a4d) to branch 'net.randombit.botan.cxx11' (head 5517c9f8f6d1990f269afb94f569a97a80c5a5f4)
| * A few additional Camellia test vectorslloyd2012-04-271-0/+37
| |
* | propagate from branch 'net.randombit.botan.tls-state-machine' (head ↵lloyd2012-04-251-10/+12
|\| | | | | | | | | | | a4741cd07f50a9e1b29b0dd97c6fb8697c038ade) to branch 'net.randombit.botan.cxx11' (head 116e5ff139c07000be431e07d3472cc8f3919b91)
| * Patrick Pelletier noted on the mailing list that the implementation oflloyd2012-04-241-10/+12
| | | | | | | | | | | | | | | | | | Camellia exposed by the OpenSSL module is parameterized by the key length, much as AES is, while the version in the main source uses a single name/type for all variants. For consistency, convert to using a key length parameterized name in our version as well. In the future this might allow for better loop unrolling, etc but currently we don't make use of that.
* | propagate from branch 'net.randombit.botan.tls-state-machine' (head ↵lloyd2012-02-201-0/+2
|\ \ | |/ |/| | | | | | | 0ceb9cde62a2b3614901ae85a53546d9fc641326) to branch 'net.randombit.botan.cxx11' (head 777e65950ef3706a82e5df20dcca7fcc999ca533)
| * Add string_join; inverse of split_on.lloyd2011-06-171-0/+2
| | | | | | | | | | | | | | | | | | Use auto in a few more places. Use GCC 4.6's range-for Delete rather than hide Algorithm copy constructor/assignment Move version to more or less randomly chosen 1.99 so there is no ambiguity about versions.
* | Add a slow but functional implementation of Camellialloyd2012-01-281-0/+20
|/
* The new method of doing comparisons did not work all of the time: iflloyd2011-05-131-0/+82
| | | | | | | | | | | the low bytes were equal, then the saturating subtraction result in that byte would be 0 with the high byte containing a non-zero value. To deal with this, shift and or together the two values into the low byte. Add some new tests which check out the SIMD implementation more carefully, including values that trigger the problem in the earlier version.
* Disable CMS by default, since it's pretty untested and likely unusablelloyd2011-05-061-0/+55
| | | | | | | | currently. Include the source directory name in object file names. Add some more DES test vectors.
* PR 145 was based around an easy misunderstanding of the CTR code.lloyd2011-04-051-0/+515
| | | | | | Add some comments to help explain what is going on. Also add a test using 512 blocks; all the existing ones were shorter, so increment was not being tested at all. :(
* Update Keccak to the round 3 variant announced 2011-01-17lloyd2011-01-201-1608/+1608
| | | | | Only change is the padding rule. It 'simplifies' the padding by making it less flexible and harder to implement efficiently. :(
* Add a simple but functioning implementation of Keccak. Only thelloyd2010-12-101-6/+9558
| | | | proposed SHA-3 parameter sets are supported.
* Update Skein-512 for the new 1.3 specification, just changes the keylloyd2010-11-031-3452/+1560
| | | | schedule constant to prevent rotational attacks.
* Longer CTR testlloyd2010-10-291-0/+50
|
* Simple standalone base64 encoderlloyd2010-10-281-0/+4
|
* In all cases where the block size of the cipher is fixed, the keylloyd2010-10-141-226/+68
| | | | | | | | | | | | | | | | parameters are as well. So make them template paramters. The sole exception was AES, because you could either initialize AES with a fixed key length, in which case it would only be that specific key length, or not, in which case it would support any valid AES key size. This is removed in this checkin; you have to specifically ask for AES-128, AES-192, or AES-256, depending on which one you want. This is probably actually a good thing, because every implementation other than the base one (SSSE3, AES-NI, OpenSSL) did not support "AES", only the versions with specific fixed key sizes. So forcing the user to ask for the one they want ensures they get the ones that are faster and/or safer.
* Add a set of tests devised by Rivest which are designed to detect alloyd2010-09-231-0/+18
| | | | | range of single bit errors in DES (though really this method is more useful for a hardware implementation than table based software).
* 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
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-17 09:06:13 +0000