aboutsummaryrefslogtreecommitdiffstats
path: root/checks
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* Disable fault protection for ECDSA benchmark, easier profilinglloyd2010-03-131-1/+1
|
* Simple cleanupslloyd2010-03-131-6/+13
|
* Remove access to the Jacobian coordinate getters get_{x,y,z}, as welllloyd2010-03-131-136/+59
| | | | | | | | | | | | | | as the 4-argument constructor. Define operator==() in terms of the affine coordinates. Rewrite tests that assumed access to the Jacobian coodinates in terms of the affine coordinates. This change allows for using arbitrary coordinate systems in PointGFp, as long as it can convert to the normal affine coordinates (which are what is used by all ECC algorithms implemented currently, and probably all interesting ECC algorithms in general).
* Remove call to disable key testing, now a per-build optionlloyd2010-03-101-4/+2
|
* Deconstify PK_Ops. It's quite reasonable that some op will want tolloyd2010-03-092-27/+34
| | | | | | | | | | | | | precompute only as needed, or will want to access some other expensive resource or etc. Change how the secret for generating blinding is done in cases where a PRNG isn't available. Use the operations public op to hide the secret, for instance the seed for a DH blinding variable is 2^x mod p. Make use of being able to mutate internal structures in the RW signer, since that does have access to a PRNG, so use it to initialize the blinder on first call to sign().
* Dont need RNG in this testlloyd2010-03-091-3/+2
|
* Rename PK_Encryptor_MR_with_EME and PK_Decryptor_MR_with_EME tolloyd2010-03-082-10/+10
| | | | | PK_Encryptor_EME and PK_Decryptor_EME; the message recovery is somewhat implicit in the recovery of the plaintext.
* Modify pubkey classes to take names instead of object pointers.lloyd2010-03-085-139/+139
| | | | | Remove use of look_pk from the source and examples, instead instantiate classes directly.
* Remove the sign() operation from the public key objects, totally replacedlloyd2010-03-054-203/+113
| | | | | | by using the ops. Add real ECDSA test vectors (two found in ANSI X9.62)
* This checkin represents a pretty major change in how PK operations arelloyd2010-03-042-138/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | performed. Up until now, each key object (eg DSA_PublicKey or ECDH_PrivateKey) had two jobs: contain the key material, and know how to perform any operations on that key. However because of a desire to support alternative implementations (GNU MP, hardware, whatever), there was a notion of operations, with the key objects containing an op that they got via engine rather than actually implementing the underlying algorithms directly. Now, represent the operation as an abstract interface (typically mapping a byte string to a byte string), and pass a plain Public_Key& or Private_Key& to the engine. The engine does any checks it wants (eg based on name, typeid, key sizes, etc), and either returns nothing (I'll pass) or a pointer to a new operation that represents signatures or encryption or what-have-you using that key. This means that plain key objects no longer contain operations. This is a major break with the traditional interface. On the other hand, using these 'bare' operations without padding, KDFs, etc is 99% of the time a bad idea anyway (and if you really need them, there are options so you get the bare op but via the pubkey.h interfaces). Currently this change is only implemented for DH and ECDH (ie, key agreement algorithms). Additionally the optional engines (gnump and openssl) have not been updated. I'll probably wait to touch those until after I can change them all in one go for all algos.
* Use KDF2/PK_Key_Agreement in DH benchmarklloyd2010-03-041-5/+5
|
* More keygen testslloyd2010-03-041-0/+8
|
* Test GOST with 521-bit prime field (was setting off bug before)lloyd2010-03-041-1/+1
|
* Split up load/store tests public vs privatelloyd2010-03-041-11/+29
|
* For each keygen tests, save the file as pem then reload it.lloyd2010-03-041-27/+80
|
* Add similar decoding constructors to the private keyslloyd2010-03-042-3/+3
|
* Add a new constructor to each public key algorithm (only the publiclloyd2010-03-042-97/+2
| | | | | | | keys so far, private keys not changed) that takes an AlgorithmIdentifier and a MemoryRegion<byte>&. This performs the X.509 decoding. It is not possible anymore to create uninitialized PK objects.
* Remove odd DH use in ECDH testlloyd2010-03-041-4/+0
|
* Some botan exception throws are plain STL exceptionslloyd2010-03-041-7/+1
|
* Add a new function to public key x509_subject_public_key which returnslloyd2010-03-041-6/+2
| | | | | what x509_encoder()->key_bits() used to return. This is much simpler than using the explicit encoder objects. Remove X509_Encoder entirely.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-15 13:56:47 +0000