aboutsummaryrefslogtreecommitdiffstats
path: root/src/block
Commit message (Collapse)AuthorAgeFilesLines
* Eliminate the constant size_t values in SymmetricAlgorithm that givelloyd2010-10-287-28/+25
| | | | | | | | | | | | | | | | | | | 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.
* Update AES-NI for SecureVector and BlockCipher changeslloyd2010-10-191-9/+9
|
* Only allocate as much working space as needed in key schedulelloyd2010-10-141-4/+4
|
* Remove standalone S functionlloyd2010-10-141-12/+13
|
* In all cases where the block size of the cipher is fixed, the keylloyd2010-10-1430-137/+176
| | | | | | | | | | | | | | | | 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.
* More size_tlloyd2010-10-133-18/+18
|
* Implicit rounds based on key variable sizelloyd2010-10-134-27/+44
|
* Make the rounds implicit with the size of the key valueslloyd2010-10-132-55/+42
|
* More size_t. Document changeslloyd2010-10-133-8/+8
|
* Add a new subclass for BlockCipher BlockCipher_Fixed_Block_Size, whichlloyd2010-10-1357-203/+232
| | | | | | | | | | | | | | 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)
* s/BLOCK_SIZE/block_size()/lloyd2010-10-1330-143/+143
|
* Use output_length() instead of OUTPUT_LENGTH pseudo-propertylloyd2010-10-132-6/+6
|
* Add accessors for block size and output lengthlloyd2010-10-131-0/+5
|
* Use size_t rather than u32bit in SymmetricAlgorithmlloyd2010-10-1358-132/+131
|
* size_tlloyd2010-10-131-1/+1
|
* More size_tlloyd2010-10-134-25/+25
|
* Use size_t rather than u32bit for the blocks argument of encrypt_nlloyd2010-10-1263-396/+422
|
* s/u32bit/size_t/ for block cipher parallelism querieslloyd2010-10-126-9/+9
|
* Compile fixlloyd2010-10-041-1/+1
|
* Make configure output more sensible wrt incompatible moduleslloyd2010-09-281-0/+4
|
* In the IDEA key schedule, using the extended Euclidean algorithm tolloyd2010-09-231-17/+14
| | | | | | compute the inverses mod 65537 exposed a timing vulnerability. Avoid this by instead using exponentiation, which takes constant time (up to variability in the multiplication operation, at least).
* Remove more implicit vector to pointer conversionslloyd2010-09-141-10/+12
|
* Handle the case that container size() returns something other than u32bitlloyd2010-09-142-2/+3
|
* Completely remove the second parameter to SecureVector which specifieslloyd2010-09-1440-185/+202
| | | | | | | | | | | | | | | | | | | | 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.
* Remove more uses of vector to pointer implicit conversionslloyd2010-09-132-6/+11
|
* First set of changes for avoiding use implicit vector->pointer conversionslloyd2010-09-1319-110/+129
|
* Anywhere where we use MemoryRegion::begin to get access to the raw pointerlloyd2010-09-132-6/+6
| | | | | representation (rather than in an interator context), instead use &buf[0], which works for both MemoryRegion and std::vector
* Big, invasive but mostly automated change, with a further attempt atlloyd2010-09-0726-47/+47
| | | | | | | | | | | | | | 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.
* Prevent shadowing of one loop param with anotherlloyd2010-09-071-1/+1
|
* The SSSE3 intrinsics apparently work under Sun Studio as welllloyd2010-09-071-0/+1
|
* Fix paper ref URL, remove unused prefetch includelloyd2010-08-201-5/+9
|
* Also use a smaller table in the first round of AES in the decrypt directionlloyd2010-08-191-9/+19
|
* In the first round of AES, use a 256 element table and do thelloyd2010-08-181-9/+28
| | | | | | | | | | | | | rotations in the code. This reduces the number of cache lines potentially accessed in the first round from 64 to 16 (assuming 64 byte cache lines). On average, about 10 cache lines will actually be accessed, assuming a uniform distribution of the inputs, so there definitely is still a timing channel here, just a somewhat smaller one. I experimented with using the 256 element table for all rounds but it reduced performance significantly and I'm not sure if the benefit is worth the cost or not.
* Add also AES-192 using SSSE3lloyd2010-08-122-23/+149
|
* Support AES-256 is the SSSE3 implementationlloyd2010-08-122-5/+93
|
* Use _mm_set_epi32 instead of _mm_set_epi64x - VC++ obnoxiously onlylloyd2010-08-112-79/+79
| | | | supports epi64x in 64-bit mode.
* 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.
* Add an implementation of AES-128 using SSSE3 instructions. It runs inlloyd2010-08-093-0/+454
| | | | | | | | | | | | | | | 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-081-19/+0
| | | | fine with latest SVN.
* Only call the scalar versions if we actually have leftover blocks tolloyd2010-06-224-8/+16
| | | | process
* Doxygenlloyd2010-06-211-3/+26
|
* In IDEA, Noekeon, Serpent, XTEA, provide and use ro accessor functionslloyd2010-06-218-15/+43
| | | | | for getting access to the key schedule, instead of giving the key schedule protected status, which is much harder tu audit.
* Make Serpent's key_schedule and actual round keys private. Addlloyd2010-06-211-1/+15
| | | | | protected accessor functions for get and set. Set is needed by the x86 version since it implements the key schedule directly.
* Replace "@return a blah" and "@return the blah" with just "@return blah"lloyd2010-06-162-3/+3
|
* Yet more Doxygen commentslloyd2010-06-164-19/+28
|
* More Doxygenlloyd2010-06-154-3/+27
|
* Don't allow access to key_schedule, just the memberslloyd2010-06-152-3/+5
|
* More Doxygen updateslloyd2010-06-156-13/+42
|
* More Doxygen fixeslloyd2010-06-1528-40/+48
|
* Fix a few hundred Doxygen warningslloyd2010-06-151-2/+2
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 22:08:32 +0000