aboutsummaryrefslogtreecommitdiffstats
path: root/src/libstate
Commit message (Collapse)AuthorAgeFilesLines
* Add back min_keylength_of, max_keylength_of, keylength_multiple_oflloyd2011-03-212-0/+87
| | | | functions for backwards compatability.
* Add HMAC, AES, SHA-2, HMAC_RNG deps in libstate for the globallloyd2011-02-111-0/+5
| | | | | | RNG. Pretty much required outside of very special cases, and otherwise someone using --no-autoload will have to know to enable them specifically or lots of things will break.
* Remove inclusions of unused headers.lloyd2011-02-101-1/+0
| | | | Avoid using auto_ptr in the CVC headers.
* More VC warning fixeslloyd2011-02-092-4/+4
|
* More VC warning fixeslloyd2010-12-131-1/+1
|
* Move PBKDF lookups to enginelloyd2010-11-041-33/+2
|
* Add a BOTAN_DEPRECATED macro which can provide compile-timelloyd2010-11-021-1/+6
| | | | deprecation warnings (at least for GCC and VC++). Use in some places.
* Doxygen updates.lloyd2010-11-021-1/+1
| | | | | Remove version of search_map that returns two distinguishing results; only used in one place, and that can be replaced by a call to count()
* Eliminate the constant size_t values in SymmetricAlgorithm that givelloyd2010-10-282-115/+0
| | | | | | | | | | | | | | | | | | | the parameters of the key length. Instead define a new function which returns a simple object which contains this information. This definitely breaks backwards compatability, though only with code that directly manipulates low level objects like BlockCipher*s directly, which is probably relatively rare. Also remove some deprecated accessor functions from lookup.h. It turns out block_size_of and output_size_of are being used in the TLS code; I need to remove them from there before I can delete these entirely. Really that didn't make much sense, because they assumed all implementations of a particular algorithm will have the same specifications, which is definitely not necessarily true, especially WRT key length. It is much safer (and probably simpler) to first retrieve an instance of the actual object you are going to use and then ask it directly.
* In all cases where the block size of the cipher is fixed, the keylloyd2010-10-141-1/+0
| | | | | | | | | | | | | | | | 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.
* Remove most uses of HASH_BLOCK_SIZElloyd2010-10-131-1/+1
|
* s/BLOCK_SIZE/block_size()/lloyd2010-10-131-1/+1
|
* Use output_length() instead of OUTPUT_LENGTH pseudo-propertylloyd2010-10-131-3/+3
|
* More size_tlloyd2010-10-132-8/+8
|
* Use size_t instead of u32bit in entropy and rnglloyd2010-10-121-3/+3
|
* Use size_t in SCAN_Namelloyd2010-10-123-23/+23
|
* When creating a PBKDF2, first check if the argument name is a knownlloyd2010-08-211-2/+6
| | | | | | | | | | | | | 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.
* Fix return value for set_global_state_unless_setlloyd2010-08-081-0/+3
|
* Move the functions that directly manipulate the global state singletonlloyd2010-08-066-67/+165
| | | | | | | | | | | into global_state.{h,cpp}. Move all of the functions into a new namespace Global_State_Management, though exposing global_state() into the Botan namespace for compatability. Also add new functions global_state_exists and set_global_state_unless_set which may be helpful in certain tricky initialization scenarios (eg when an application using botan also uses a library which may or may not itself use botan).
* Rename Default_Engine to Core_Engine which describes its purposeslloyd2010-07-272-3/+3
| | | | (slightly) better.
* Modify CPUID so all the check functions are purely inline. Add a newlloyd2010-07-261-0/+3
| | | | | initialize() call which must be called prior to use of any other functions.
* Consolidate the two engines that provided assembler implementationslloyd2010-07-131-12/+4
| | | | | | (amd64_eng and ia32_eng) into a new asm_engine. This same engine could also be used in the event that asm code for other CPUs was added later on.
* Rename S2K to PBKDF, because that is by far the most common name - S2Klloyd2010-07-093-12/+22
| | | | | | | | | | | | | 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.
* If we are going to lazily initialize, just create the type and calllloyd2010-06-251-2/+4
| | | | its constructor directly, instead of going through LibraryInitializer.
* Doxygenlloyd2010-06-211-5/+23
|
* Replace "@return a blah" and "@return the blah" with just "@return blah"lloyd2010-06-165-31/+31
|
* Yet more Doxygen commentslloyd2010-06-161-16/+18
|
* More Doxygen commentslloyd2010-06-162-0/+10
|
* Deprecated some of the old lookup functions in Doxygenlloyd2010-06-152-0/+38
|
* More Doxygen updates/fixeslloyd2010-06-151-2/+2
|
* Fix a few hundred Doxygen warningslloyd2010-06-154-40/+43
|
* Use "/*" instead of "/**" in starting comments at the begining of a file.lloyd2010-06-075-5/+5
| | | | | This caused Doxygen to think this was markup meant for it, which really caused some clutter in the namespace page.
* mutex.h is internal - had been picking up system installed versionlloyd2010-04-231-1/+1
|
* Allow adding engines dynamicallylloyd2010-03-241-10/+8
|
* Delete global RNG and the mutex in ~Library_Statelloyd2010-03-231-3/+5
|
* Don't require the AES module; if it's there its there, if it's notlloyd2010-03-192-4/+2
| | | | then you can't use the global PRNG but everything else still works.
* There are some nasty API problems that are caused by having to pass alloyd2010-03-194-8/+235
| | | | | | | | | | | | | | | | | | | | | | | | 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
* At startup, test if lock_mem() at least seems to work. If it doesn't,lloyd2010-03-131-1/+2
| | | | | immediately fall back the the plain malloc-based allocator, which is typically quite a bit faster.
* Remove config options to toggle if X.509 extensions are critical orlloyd2010-03-103-48/+0
| | | | | | | | not. Instead provide via Extensions::add(). No way to modify behavior currently, it just follows the previous default police. Remove the config options from Library_State entirely. Die, mutable singletons, die.
* Remove the base/default_allocator option, instead save as a per-libstatelloyd2010-03-103-19/+25
| | | | variable directly.
* Rename PK_Encryptor_MR_with_EME and PK_Decryptor_MR_with_EME tolloyd2010-03-081-2/+2
| | | | | PK_Encryptor_EME and PK_Decryptor_EME; the message recovery is somewhat implicit in the recovery of the plaintext.
* Have the constructors in pubkey.h take all arguments look_pk does, andlloyd2010-03-081-9/+5
| | | | convert look_pk to simple forwarders.
* Remove the now no-op classes PK_Encrypting_Key,lloyd2010-03-081-20/+4
| | | | | PK_Decrypting_Key, PK_Signing_Key, PK_Verifying_with_MR_Key, and PK_Verifying_wo_MR_Key.
* Inline Engine_Core::mod_exp into singler caller, and deletelloyd2010-03-053-72/+0
|
* Remove IF_Corelloyd2010-03-052-31/+0
|
* Add ops for ElGamal encryption and decryption.lloyd2010-03-052-27/+0
| | | | | Note: blinding is not currently being used for RSA, RW, DH or ElGamal, which used to have them. This should be added back before release.
* Remove NR and DSA specific hookslloyd2010-03-052-54/+0
|
* Add verification ops for all signature key typeslloyd2010-03-051-2/+2
|
* Inline look_pk funcslloyd2010-03-053-102/+49
|
* This checkin represents a pretty major change in how PK operations arelloyd2010-03-042-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 11:50:08 +0000