| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
(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.
|
|
|
|
|
|
| |
by using the ops.
Add real ECDSA test vectors (two found in ANSI X9.62)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
keys so far, private keys not changed) that takes an
AlgorithmIdentifier and a MemoryRegion<byte>&. This performs the X.509
decoding. It is not possible anymore to create uninitialized PK
objects.
|
| |
|
| |
|
|
|
|
|
| |
what x509_encoder()->key_bits() used to return. This is much simpler
than using the explicit encoder objects. Remove X509_Encoder entirely.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
scheme, which is supposed to use the IEEE 1363-style concatenation
format, was identified with the X9.62 OIDs, which are documented to
use the DER sequence format. Switch the BSI ones to use the OIDs
allocated for this purpose by BSI, and add the X9.62 ECDSA/SHA-1 OID
since that was missing.
Correct an ECDSA test that assumed the cert was identified with the BSI
OID, even though in fact the cert in question uses an X9.62-style format.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
I'm not sure where the old name came from though as literally the only
hits for it on Google are botan-related.
|
| |
|
|
|
|
|
|
|
| |
handling ImplicitCA ECDSA keys in the CVC code. Currently dealt with
in CVC by simply commenting out the calls - CVC is already pretty
broken and I'd much rather have ECC sane and under control and CVC
totally broken than ECC remaining in its current state.
|
| |
|
| |
|
| |
|
| |
|
| |
|