| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
(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.
|
|
|
|
|
|
|
|
|
| |
removing several workarounds for limitations in optparse in that
release, and also allows using the ternary operator added in 2.5.
As far as I can tell, the only still active release of any Linux/BSD
distro that uses 2.4 is RHEL5. The beta of RHEL6 has 2.6, and it seems
likely that RHEL6 will be out before 1.10.0.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
really is only used by OpenPGP, and largely it was named S2K here
because the OpenPGP S2K was implemented years before the ones in PKCS
#5. We have a typedef of PBKDF to S2K, and an inlined get_s2k that
calls get_pbkdf for source compatability.
There doesn't seem to be any reason to have a forward for the renamed
s2k.h header - to actually use a PBKDF, you'd have to either include
lookup.h and call get_s2k / get_pbkdf, or else include an
algorithm-specific header and use it directly. In either case,
including s2k.h is neither necessary nor sufficient.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
private keys.
For the older PBES1, we can only increase the iteration
count (from 2048 to 10000); the salt is fixed by the standard to
64 bits. This is probably OK, since PBES1 is also limited to
(at best) 64-bit encryption keys and thus is pretty unsafe
anyway.
For PBES2, increase the iteration count (also 2048 to 10000) and
increase the size of the salt from 64 bits to 96 bits.
This will only affect keys which are encrypted by a version after
this revision.
|
| |
|
| |
|
|
|
|
|
|
|
| |
--without-boost-python to explicitly disable it.
This makes it much easier to use at least in Gentoo's ebuild system,
and perhaps with other packaging systems as well.
|
| |
|
| |
|
|
|
|
|
| |
More commentary posted to the list:
http://lists.randombit.net/pipermail/botan-devel/2010-May/001123.html
|
|
|
|
| |
that enable botan to be built under the clang C++ compiler.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
be branch-free. This reduces performance noticably on my Core2 (from
32 MiB/s to a bit over 27 MiB), but so it goes.
The IDEA implementation using SSE2 is already branch-free here, and
runs at about 135 MiB/s on my machine.
Also add more IDEA tests, generated by OpenSSL
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
I'm not sure where the old name came from though as literally the only
hits for it on Google are botan-related.
|
| |
|
| |
|
| |
|
| |
|