| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
of each other anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
destructor function which would delete the engine; this was to handle
the case that the heaps were not shared between the application and
the library. However in this case we have bigger problems, because we
want to be able to pass std::strings into the engine, and additionally
be able to return objects from the library which are later deleted by
the algorithm factory. So without a major restructuring we can't
support this style of operation anyway; the DLL and application must
share the same heap. This can be done on Windows using the /MD linking
scheme for both the library and the DLL. The library already uses this
model by default on Windows.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
expected value is 20100728 (ie, today). This will allow for checking
for and/or working around changes to interfaces.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
(slightly) better.
|
|\
| |
| |
| | |
and 'ada4c9893d70affd8934ab9664e390087feab3c9'
|
| |
| |
| |
| | |
Rename CPUID::has_aes_intel to has_aes_ni.
|
| | |
|
|/ |
|
|
|
|
|
|
| |
(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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
source file. Otherwise we ran into a conflict between Doxygen
comments, which require us to name the params, and GCC's
-Wunused-parameters, which will warn about parameters which aren't
being used.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This caused Doxygen to think this was markup meant for it, which really
caused some clutter in the namespace page.
|
|
|
|
|
| |
More commentary posted to the list:
http://lists.randombit.net/pipermail/botan-devel/2010-May/001123.html
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
precompute only as needed, or will want to access some other expensive
resource or etc.
Change how the secret for generating blinding is done in cases where a
PRNG isn't available. Use the operations public op to hide the secret,
for instance the seed for a DH blinding variable is 2^x mod p.
Make use of being able to mutate internal structures in the RW signer,
since that does have access to a PRNG, so use it to initialize the
blinder on first call to sign().
|
|
|
|
| |
exponentiation that has countermeasures against side-channel attacks.
|
|
|
|
| |
support for ElGamal and NR, leaving only RSA, DSA, and DH support.
|
| |
|
|
|
|
|
| |
Drop support for ElGamal and NR from GMP engine, leaving just DH, DSA,
and RSA
|
| |
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
| |
Rename PK_Ops::KA_Operation to PK_Ops::Key_Agreement
|
| |
|
| |
|
|
|
|
|
|
| |
PK_Signing_Key, though for the moment the class remains because there
are a few pieces of code that use it to detect if signatures are
supported, or for passing to functions in look_pk
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|