| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
shrink_to_fit to actually deallocate memory.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
|
|
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.
|
