aboutsummaryrefslogtreecommitdiffstats
path: root/src/block/idea/idea.h
Commit message (Collapse)AuthorAgeFilesLines
* Add new helper zap which zeros a vector, clears it, and then callslloyd2012-11-291-1/+1
| | | | shrink_to_fit to actually deallocate memory.
* For block and stream ciphers, don't set the size of the key vectorslloyd2012-05-251-3/+2
| | | | | | | | | | | until we are actually setting a key. This avoids the problem of prototype objects consuming not just memory but the precious few bytes of mlock'able memory that we're given by Linux. Use clear_mem instead of a loop in BigInt::mask_bits If OS2ECP encounters an invalid format type, include what type it was in the exception message.
* Fairly huge update that replaces the old secmem types with std::vectorlloyd2012-05-181-3/+3
| | | | | | using a custom allocator. Currently our allocator just does new/delete with a memset before deletion, and the mmap and mlock allocators have been removed.
* In all cases where the block size of the cipher is fixed, the keylloyd2010-10-141-2/+2
| | | | | | | | | | | | | | | | 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 new subclass for BlockCipher BlockCipher_Fixed_Block_Size, whichlloyd2010-10-131-2/+2
| | | | | | | | | | | | | | sets the block size statically and also creates an enum with the size. Use the enum instead of calling block_size() where possible, since that uses two virtual function calls per block which is quite unfortunate. The real advantages here as compared to the previous version which kept the block size as a per-object u32bit: - The compiler can inline the constant as an immediate operand (previously it would load the value via an indirection on this) - Removes 32 bits per object overhead (except in cases with actually variable block sizes, which are very few and rarely used)
* Use size_t rather than u32bit in SymmetricAlgorithmlloyd2010-10-131-1/+1
|
* Use size_t rather than u32bit for the blocks argument of encrypt_nlloyd2010-10-121-2/+2
|
* Completely remove the second parameter to SecureVector which specifieslloyd2010-09-141-4/+4
| | | | | | | | | | | | | | | | | | | | the initial/default length of the array, update all users to instead pass the value to the constructor. This is a old vestigal thing from a class (SecureBuffer) that used this compile-time constant in order to store the values in an array. However this was changed way back in 2002 to use the same allocator hooks as the rest of the containers, so the only advantage to using the length field was that the initial length was set and didn't have to be set in the constructor which was midly convenient. However this directly conflicts with the desire to be able to (eventually) use std::vector with a custom allocator, since of course vector doesn't support this. Fortunately almost all of the uses are in classes which have only a single constructor, so there is little to no duplication by instead initializing the size in the constructor.
* Big, invasive but mostly automated change, with a further attempt atlloyd2010-09-071-1/+1
| | | | | | | | | | | | | | harmonising MemoryRegion with std::vector: The MemoryRegion::clear() function would zeroise the buffer, but keep the memory allocated and the size unchanged. This is very different from STL's clear(), which is basically the equivalent to what is called destroy() in MemoryRegion. So to be able to replace MemoryRegion with a std::vector, we have to rename destroy() to clear() and we have to expose the current functionality of clear() in some other way, since vector doesn't support this operation. Do so by adding a global function named zeroise() which takes a MemoryRegion which is zeroed. Remove clear() to ensure all callers are updated.
* In IDEA, Noekeon, Serpent, XTEA, provide and use ro accessor functionslloyd2010-06-211-2/+11
| | | | | for getting access to the key schedule, instead of giving the key schedule protected status, which is much harder tu audit.
* Don't allow access to key_schedule, just the memberslloyd2010-06-151-1/+3
|
* More Doxygen fixeslloyd2010-06-151-1/+1
|
* Remove SecureBuffer, which is the fixed-size variant of SecureVector.lloyd2010-03-231-1/+1
| | | | | | | | | | | | | | Add a second template param to SecureVector which specifies the initial length. Change all callers to be SecureVector instead of SecureBuffer. This can go away in C++0x, once compilers implement N2712 ("Non-static data member initializers"), and we can just write code as SecureVector<byte> P{18}; instead
* Add last nights project, an SSE2 implementation of IDEA. Right about 4xlloyd2009-12-231-1/+1
| | | | faster than the scalar version on a Core2.
* Remove all exception specifications. The way these are designed in C++ islloyd2009-10-221-1/+1
| | | | | | just too fragile and not that useful. Something like Java's checked exceptions might be nice, but simply killing the process entirely if an unexpected exception is thrown is not exactly useful for something trying to be robust.
* Make encrypt_n public for all BlockCipher implementations - unlike thelloyd2009-08-111-2/+4
| | | | | | enc/dec functions it replaces, these are public interfaces. Add the first bits of a SSE2 implementation of Serpent. Currently incomplete.
* Change the BlockCipher interface to support multi-block encryption andlloyd2009-08-111-2/+2
| | | | | | | | | decryption. Currently only used for counter mode. Doesn't offer much advantage as-is (though might help slightly, in terms of cache effects), but allows for SIMD implementations to process multiple blocks in parallel when possible. Particularly thinking here of Serpent; TEA/XTEA also seem promising in this sense, as is Threefish once that is implemented as a standalone block cipher.
* Thomas Moschny passed along a request from the Fedora packagers which camelloyd2009-03-301-7/+9
| | | | | | | | | | | | | | | up during the Fedora submission review, that each source file include some text about the license. One handy Perl script later and each file now has the line Distributed under the terms of the Botan license after the copyright notices. While I was in there modifying every file anyway, I also stripped out the remainder of the block comments (lots of astericks before and after the text); this is stylistic thing I picked up when I was first learning C++ but in retrospect it is not a good style as the structure makes it harder to modify comments (with the result that comments become fewer, shorter and are less likely to be updated, which are not good things).
* Rename SymmetricAlgorithm::key to key_schedule to avoid many namelloyd2008-11-091-1/+1
| | | | conflicts/collisions
* Split ciphers into block and stream ciphers. Move base class headerslloyd2008-11-081-0/+32