aboutsummaryrefslogtreecommitdiffstats
path: root/checks/validate.dat
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-16 18:56:02 +0000