aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Tick to 1.9.11-devlloyd2010-08-132-5/+5
|
* The changelog for 1.9.4 claimed that the default PKCS #8 encryptionlloyd2010-08-132-2/+5
| | | | | | | | | | algorithm had changed to AES-256. This was wrong, it actually changed to AES-128. However in retrospect AES-256 is probably a reasonable move (in particular for the 4 extra rounds; the related key attacks possible against AES-256 are probably not viable since we generate the key using PBKDF2), so update the 1.9.4 changelog to correctly indicate the change made in that release, and also modify PKCS #8 to actually use AES-256.
* Update log, readme, configure for 1.9.10 release 2010-08-121.9.10lloyd2010-08-123-4/+4
|
* Add also AES-192 using SSSE3lloyd2010-08-125-24/+155
|
* Missing include, VC++ complainedlloyd2010-08-121-0/+1
|
* Support AES-256 is the SSSE3 implementationlloyd2010-08-124-6/+96
|
* Handle the cast of configure.py --cpu=i386 --enable-ssse3. Previouslylloyd2010-08-111-0/+5
| | | | | this would only enable SSSE3 and not SSE2, though SSE2 is a subset. Now that works.
* Use _mm_set_epi32 instead of _mm_set_epi64x - VC++ obnoxiously onlylloyd2010-08-112-79/+79
| | | | supports epi64x in 64-bit mode.
* Remove use of -ansi; it's not particularly helpful anyway, and itlloyd2010-08-111-1/+1
| | | | causes obnoxious problems under MinGW.
* Workaround problem with GCC 3 - it doesn't like you casting pointerslloyd2010-08-101-0/+4
| | | | | | to pointers-to-functions (which, admittedly, is undefined in ISO C++, but doing this is required to use dlopen). Using the dumb hammer of a C-style cast works, though.
* Add Filter::name implementationlloyd2010-08-101-0/+2
|
* Typo fixeslloyd2010-08-101-2/+2
|
* In 1.9.9 I moved the cryptobox functions out of the CryptoBoxlloyd2010-08-102-11/+22
| | | | | | | namespace, but this causes backwards compat problems, since cryptobox is already in 1.8, and also it's likely that other functions along these lines will be useful at some point (eg using RSA encryption instead of a passphrase for the key transfer).
* Only enable aes_ssse3 when compiling with GCC or Clang. For some dumbasslloyd2010-08-091-0/+7
| | | | | | | | | | | | | | | reasons, Intel C++ rejects const __m128i foo = _mm_set_epi64x(...) though it will accept if you use one of the _mm_set1 variants. And Visual C++ doesn't know about _mm_set_epi64x() in 32-bit mode for similarly dumb reasons - it works fine compiling for 64 bit but for whatever reason they don't offer this function when compiling as 32 bit. Unfortunately there isn't a good way to specify it's OK with a particular compiler with one arch but not another, so just disable it globally for the time being. The workaround for VC++ is probably to use _mm_set_epi32 and break up the input values into 32 bit chunks. ICC is a lost cause I fear.
* Move the tutorial to old_tutorial since it's badly out of date andlloyd2010-08-092-791/+932
| | | | | | | | | doesn't really answer questions people commonly have. Add the first bits of a new tutorial that will hopefully be more helpful; more of a "Q: I want to do X, how do I do this?" "A: You do X with this code ..." and spending less time doing things like incrementally building code starting from poorly done versions since that really is probably just confusing people.
* Clang supports -marchlloyd2010-08-091-0/+4
|
* Add an implementation of AES-128 using SSSE3 instructions. It runs inlloyd2010-08-095-0/+464
| | | | | | | | | | | | | | | constant time and on a Nehalem is significantly faster than the table based version. This implementation technique was invented by Mike Hamburg and described in a paper in CHES 2009 "Accelerating AES with Vector Permute Instructions". This code is basically a translation of his public domain x86-64 assembly code into intrinsics. Todo: Adding support for AES-192 and AES-256; this just requires implementing the key schedules. Currently only tested on an i7 with GCC (32 and 64 bit code); testing/optimization on 32-bit processors with SSSE3 like the Atom, and with Visual C++ and other compilers, are also todos.
* Also allow clang with 32-bit assembly code, everything seems to worklloyd2010-08-088-94/+20
| | | | fine with latest SVN.
* Clang understands at least some GCC inline asm syntax as well as whatlloyd2010-08-083-0/+3
| | | | an .S file is, so allow it for x86-64. Tested/works with Clang SVN.
* Identify a i7-860 as Nehalemlloyd2010-08-081-0/+1
|
* If we can't access cpuid, but we know that we are compiling forlloyd2010-08-081-0/+9
| | | | | | x86-64, then enable SSE2 anyway because we know any x86-64 processor does have SSE2, and the OS has to support it because it's part of the standard ABIs.
* Use clang++ instead of clang for the compiler driver, otherwise linklloyd2010-08-081-1/+1
| | | | errors can result due to not getting the C++ runtime library.
* Clang fixlloyd2010-08-081-0/+1
|
* 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).
* merge of '28d57385c0f1a9a2665288ce728e8b3231634f59'lloyd2010-08-038-17/+67
|\ | | | | | | and 'a4d88442d5f6b8554234c7f7468856868919b614'
| * Forbid copying an Algorithm_Factory; could easily cause double-delete,lloyd2010-07-301-0/+4
| | | | | | | | | | | | | | | | | | | | especially in a multithreaded environment, and doesn't seem like a useful operation to support. (In principle, we could support this by adding a clone() call to Algorithm_Cache, which would in turn call clone on each of it's held prototype objects, plus adding a clone to Engine. Doesn't seem worth the bother, though.
| * Add a new option for benchmarking --buf-size which specifies the size oflloyd2010-07-303-9/+25
| | | | | | | | the buffer (in KiB) to process.
| * Change the benchmark code to also take a buf_size, instead of using hardcodedlloyd2010-07-302-7/+28
| | | | | | | | | | | | | | | | 16 KiB buffer. Also reorder the parameters to make somewhat more sense, with the first arguments being totally mandatory and the later ones potentially optional. Provide inlined version matching the old interface that just forwards to the new call, marking it as deprecated.
| * If dynamic loading fails, include result of dlerror() in the exception msglloyd2010-07-301-1/+8
| |
| * Add name() function to DataSource_Stream for Filter interfacelloyd2010-07-301-0/+2
| |
* | We've already predeclared Engine at the start of the header, so nolloyd2010-07-291-4/+4
|/ | | | reason to say `class Engine*` later on.
* Organize CPUID output a little more nicelylloyd2010-07-281-4/+10
|
* Restrict dyn_load to platforms where it might theoretically work:lloyd2010-07-281-0/+9
| | | | | | | | Linux, Solaris, and the BSDs. Solaris and BSD are untested, but it seems like they should work. Using libdl on Solaris is seemingly only required in Solaris 9 and earlier, but 10 has a stub library so it should work there as well.
* Remove redundant setting for adding libdl link on Linux in dyn_engine;lloyd2010-07-281-4/+0
| | | | | it relies on dyn_load which should be the sole source for this kind of stuff, since dyn_engine itself does not touch the OS level APIs.
* Add new option --dyn-load to the check/selftest prog that will loadlloyd2010-07-281-1/+18
| | | | the named shared engine object.
* Add a version info function which returns a u32bit. The currentlylloyd2010-07-281-1/+12
| | | | | expected value is 20100728 (ie, today). This will allow for checking for and/or working around changes to interfaces.
* Expose Algorithm_Factory::clear_caches which clears out all of thelloyd2010-07-272-1/+10
| | | | | caches; this might be useful for applications which are, say, particularly sensitive to memory usage.
* There was an interesting bug affecting dynamically loaded engines.lloyd2010-07-272-4/+14
| | | | | | | | | | | | | | | | | | | | | | | The library initializer runs some self tests; this brings objects for a few select types (AES, SHA-1, etc) into the caches. Later on, when we add a dynamic engine, the engines aren't requeried because the cache has hits. So, for instance an dlopen'ed engine that provided AES-128 would not actually be used unless you called on the algo factory with a provider of "blah" - even using set_preferred_provider would have no effect, because that's just a request. Add a new function to Algorithm_Cache, clear_cache, which just deletes everything that is currently loaded (this is 90% of the destructor). Then call this on each cache in Algorithm_Factory when a new Engine is loaded. In normal use, this should be very fast because on init the engines are loaded one after another so clear_cache() won't do much work at all, but it ensures that if you load an engine later on in runtime it will always be found. It does have the downside that the app will then requery each Engine for each new algo after this point, but I think typically loading a dynamic engine will happen very early on so this won't be too much of a hassle. (And even if it happens in the middle of execution, everything still works, it just means some overhead the first time you ask for algo X).
* Document new engine loaderlloyd2010-07-271-0/+1
|
* In Algorithm_Factory, delete the Engines after deleting the cacheslloyd2010-07-271-2/+2
| | | | | | | | rather than before. Otherwise, we run into a problem with dynamically loaded engines: the engine will be deleted (and thus, the external library unloaded), before calling the destructors on any objects which may have been cached, so we jump to a now invalid address instead of the destructor code.
* Add a new utility class Dynamically_Loaded_Library which wraps aroundlloyd2010-07-277-0/+308
| | | | | | | | | | the system dynamic linker (if any). Currently it only supports dlopen, and is only enabled on Linux. It will almost certainly work on BSDs and Solaris as well, though, and should be easy to extend to support Win32-style dynamic loading. Also add a new engine, Dynamically_Loaded_Engine, which loads up a new Engine object from a shared library/DLL.
* Rename Default_Engine to Core_Engine which describes its purposeslloyd2010-07-2713-38/+36
| | | | (slightly) better.
* merge of '5aea1fdc054f2e74f31717a1bc34763780537039'lloyd2010-07-273-3/+12
|\ | | | | | | and '7f8e62920b57dc79418cbd02eb91337617628b61'
| * merge of '17389a973545d2f8e25813894cdd2da1b01aa534'lloyd2010-07-277-62/+84
| |\ | | | | | | | | | and 'ada4c9893d70affd8934ab9664e390087feab3c9'
| * | Add support for Camellia in OpenSSL enginelloyd2010-07-221-0/+6
| | |
| * | Avoid unused argument warninglloyd2010-07-221-1/+3
| | |
| * | Use configured compiler for Pythonlloyd2010-07-221-2/+3
| | |
* | | merge of '068683e77f11701262d6ff5f4004629734c28cd9'lloyd2010-07-277-62/+84
|\ \ \ | |/ / |/| / | |/ and 'ada4c9893d70affd8934ab9664e390087feab3c9'
| * Mention byteswap changes, and fix spelling error in 1.9.9 loglloyd2010-07-271-1/+2
| |