aboutsummaryrefslogtreecommitdiffstats
path: root/checks
Commit message (Collapse)AuthorAgeFilesLines
* Thomas Keller reports that Mac OS X 10.5 still uses gcc 4.0.1 and it haslloyd2010-11-121-0/+12
| | | | the same reverse iterator bug. Use the workaround for gcc 4.0.*
* 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
|
* Compile fixlloyd2010-10-291-1/+1
|
* 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.
* s/BLOCK_SIZE/block_size()/lloyd2010-10-131-1/+1
|
* Update for RNG changeslloyd2010-10-121-4/+4
|
* Use size_t in filterslloyd2010-10-122-6/+6
| | | | | This breaks API for anyone creating their own Filter types, but it had to happen eventually.
* Fix CRL reason codes and updating of CRLs. Add tests for both cases.lloyd2010-10-073-3/+1
|
* Forward port CRL fixes from rev 7bb2001cd554a1acc3d345914ea710ff0e1d3a6blloyd2010-10-071-0/+16
|
* 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).
* Split up src/cert/x509 into a set of modules, though mostly mutuallylloyd2010-09-171-2/+4
| | | | dependent right now.
* Update all uses of MemoryRegion::append to use either push_back or operator+=lloyd2010-09-153-10/+10
|
* Remove more implicit vector to pointer conversionslloyd2010-09-141-3/+3
|
* Remove more uses of vector to pointer implicit conversionslloyd2010-09-135-24/+15
|
* Anywhere where we use MemoryRegion::begin to get access to the raw pointerlloyd2010-09-135-58/+58
| | | | | representation (rather than in an interator context), instead use &buf[0], which works for both MemoryRegion and std::vector
* Add a basic test for cryptoboxlloyd2010-09-071-0/+46
|
* Call test that was defined but not usedlloyd2010-09-071-4/+5
|
* My version of Sun Studio has the same reverse iterator bug as GCC 3lloyd2010-09-071-1/+1
|
* If the numeric_limits tests fail, make the output a little less dramaticlloyd2010-09-031-4/+4
|
* Wrap lineslloyd2010-09-031-7/+23
|
* Use the standalone version of the hex decoder instead of the wrapper thatlloyd2010-09-038-122/+102
| | | | previously existed in misc.cpp that emulated it via a pipe and filter.
* Add 3 more tests of Tiger, test vectors via Crypto++lloyd2010-08-231-0/+20
|
* For passhash9, add another interface that allows the caller to specifylloyd2010-08-221-4/+9
| | | | | | | | | | | which PRF they want to use. The old interface just calls this new version with alg_id set to 0 which is HMAC(SHA-1), which was previously the only supported PRF. Assign new codepoints for HMAC(SHA-256) and CMAC(Blowfish) to allow their use with passhash9. Have the generate+check tests run a test for each supported PRF.
* 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
* Add a new option for benchmarking --buf-size which specifies the size oflloyd2010-07-303-9/+25
| | | | the buffer (in KiB) to process.
* Add new option --dyn-load to the check/selftest prog that will loadlloyd2010-07-281-1/+18
| | | | the named shared engine object.
* Rename S2K to PBKDF, because that is by far the most common name - S2Klloyd2010-07-093-23/+25
| | | | | | | | | | | | | 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.
* Fix ECB benchmarkinglloyd2010-06-301-1/+3
|
* Give all Filter objects a method for querying their namelloyd2010-06-282-2/+21
|
* Expose a datestamp in build.h, provide function in version.h forlloyd2010-06-141-1/+2
| | | | getting runtime value.
* Work around GCC 3.x bug with reverse iteratorslloyd2010-06-111-2/+6
|
* Remove FORK-256; it's obscure and has been definitively broken.lloyd2010-05-252-936/+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
|
* Prevent crash if asked to benchmark unknown block cipher with a modelloyd2010-05-051-4/+11
| | | | (eg "NoSuchCipher/CBC")
* 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 a test for RSA verification with raw padding and an unusual keylloyd2010-04-211-0/+33
|
* Don't bother benchmarking 512 or 768 bit keys; considering an RSAlloyd2010-03-211-7/+4
| | | | | | | | | modulus of 768 bits has already been publicly factored, and discrete logarithm algorithms run in about the same time, these keys aren't safe to use no matter how fast they are. Also remove the 8192 bit RSA/RW keys - it took too long to generate them, and nobody is likely to be using 8K bit keys anytime soon anyway.
* Replace PointGFp::check_invaraints, which would either return silentlylloyd2010-03-192-16/+20
| | | | | | | | | | | or throw an exception, with PointGFp::on_the_curve, which returns a bool. Update callers. This showed several cases where check_invaraints was being called multiple times, for instance when decoding a point with OS2ECP, check_invaraints was called; many callers of OS2ECP would then call check_invaraints again on the same object.
* If check against copy fails, print algo namelloyd2010-03-191-1/+1
|
* There are some nasty API problems that are caused by having to pass alloyd2010-03-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | PRNG everywhere. The removal of the global PRNG was generated by a desire to remove the global library state entirely. However the real point of this was to remove the use of globally visible _mutable_ state; of the mutable state, the PRNG is probably the least important, and the most useful to share. And it seems unlikely that thread contention would be a major issue in the PRNG. Add back a global PRNG to Library_State. Use lazy initialization, so apps that don't ever use a PRNG don't need a seeding step. Then have AutoSeeded_RNG call that global PRNG. Offer once again RandomNumberGenerator& Library_State::global_rng(); which returns a reference to the global PRNG. This RNG object serializes access to itself with a mutex. Remove the hack known as Blinding::choose_nonce, replace with using the global PRNG to choose a blinding nonce
* Add a couple of verification tests for GOST 34.10lloyd2010-03-162-0/+49
| | | | | | | | | | | Generating the test vectors found yet another inane (and, of course, undocumented) behavior in the GOST implementation included in OpenSSL; it treats the hash inputs as little endian. Just out of curiousity, I checked RFC 5832, which supposedly specifies this algorithm; not a peep about endian conversions. The more I deal with standards coming out of the CryptoPro people, the less confidence I have in them.
* Fix GOST 34.10 benchmarklloyd2010-03-161-1/+1
|
* Disable fault protection for DSA, NR, and GOST 34.10 benchmarkslloyd2010-03-151-2/+2
|
* Centralize which ECC domains are used for benchmarkinglloyd2010-03-131-34/+17
|
* Skip bench on very small ECC groups; 112 == DESlloyd2010-03-131-3/+1
|
* Add 192 and 256 bit groups to the ECDSA benchmark lineuplloyd2010-03-131-1/+3
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-13 21:54:15 +0000