| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This breaks API for anyone creating their own Filter types, but it had
to happen eventually.
|
| |
|
| |
|
|
|
|
|
| |
range of single bit errors in DES (though really this method is more
useful for a hardware implementation than table based software).
|
|
|
|
| |
dependent right now.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
representation (rather than in an interator context), instead use &buf[0],
which works for both MemoryRegion and std::vector
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
previously existed in misc.cpp that emulated it via a pipe and filter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
which PRF they want to use. The old interface just calls this new
version with alg_id set to 0 which is HMAC(SHA-1), which was
previously the only supported PRF.
Assign new codepoints for HMAC(SHA-256) and CMAC(Blowfish) to allow
their use with passhash9.
Have the generate+check tests run a test for each supported PRF.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MAC. If it is, use it as the PRF. Otherwise assume it is a hash
function and use it with HMAC. Instead of instantiating the HMAC
directly, go through the algorithm factory.
Add a test using PBKDF2 with CMAC(Blowfish); Blowfish mainly because
it supports arbitrarily large keys, and also the required 4 KiB of
sbox tables actually would make it fairly useful in that it would make
cracking using hardware or GPUs rather expensive. Have not confirmed
this vector against any other implementation because I don't know of
any other implementation of PBKDF2 that supports MACs other than HMAC.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so for compatability with keys that were encrypted with an empty
passphrase we probably want to support it as well.
In PBKDF2, don't reject empty passphrases out of hand; simply call
set_key and if the underlying MAC cannot use the key, throw an
informative exception. This will also be more helpful in the case that
someone tries using another MAC (say, CMAC) with a block cipher that
only supports keys of specific sizes.
In HMAC, allow zero-length keys. This is not really optimal in the
sense of allowing the user to do something dumb, but a 1 byte key
would be pretty dumb as well and we already allowed that.
Add a test vector using an empty passphrase generated by OpenSSL
|
|
|
|
| |
the buffer (in KiB) to process.
|
|
|
|
| |
the named shared engine object.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
getting runtime value.
|
| |
|
|
|
|
|
| |
More commentary posted to the list:
http://lists.randombit.net/pipermail/botan-devel/2010-May/001123.html
|
| |
|
|
|
|
| |
(eg "NoSuchCipher/CBC")
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
modulus of 768 bits has already been publicly factored, and discrete
logarithm algorithms run in about the same time, these keys aren't safe
to use no matter how fast they are.
Also remove the 8192 bit RSA/RW keys - it took too long to generate them,
and nobody is likely to be using 8K bit keys anytime soon anyway.
|
|
|
|
|
|
|
|
|
|
|
| |
or throw an exception, with PointGFp::on_the_curve, which returns a bool.
Update callers.
This showed several cases where check_invaraints was being called
multiple times, for instance when decoding a point with OS2ECP,
check_invaraints was called; many callers of OS2ECP would then call
check_invaraints again on the same object.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PRNG everywhere. The removal of the global PRNG was generated by a
desire to remove the global library state entirely. However the real
point of this was to remove the use of globally visible _mutable_
state; of the mutable state, the PRNG is probably the least important,
and the most useful to share. And it seems unlikely that thread
contention would be a major issue in the PRNG.
Add back a global PRNG to Library_State. Use lazy initialization, so
apps that don't ever use a PRNG don't need a seeding step. Then have
AutoSeeded_RNG call that global PRNG.
Offer once again
RandomNumberGenerator& Library_State::global_rng();
which returns a reference to the global PRNG.
This RNG object serializes access to itself with a mutex.
Remove the hack known as Blinding::choose_nonce, replace with using
the global PRNG to choose a blinding nonce
|
|
|
|
|
|
|
|
|
|
|
| |
Generating the test vectors found yet another inane (and, of course,
undocumented) behavior in the GOST implementation included in OpenSSL;
it treats the hash inputs as little endian. Just out of curiousity, I
checked RFC 5832, which supposedly specifies this algorithm; not a
peep about endian conversions.
The more I deal with standards coming out of the CryptoPro people, the
less confidence I have in them.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as the 4-argument constructor.
Define operator==() in terms of the affine coordinates.
Rewrite tests that assumed access to the Jacobian coodinates in terms
of the affine coordinates.
This change allows for using arbitrary coordinate systems in PointGFp,
as long as it can convert to the normal affine coordinates (which are
what is used by all ECC algorithms implemented currently, and probably
all interesting ECC algorithms in general).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
|
|
|
|
| |
PK_Encryptor_EME and PK_Decryptor_EME; the message recovery is somewhat
implicit in the recovery of the plaintext.
|
|
|
|
|
| |
Remove use of look_pk from the source and examples, instead
instantiate classes directly.
|