| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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().
|
| |
|
|
|
|
| |
by using the ops.
Add real ECDSA test vectors (two found in ANSI X9.62)
|
| | |
|
| |
|
|
| |
using SHA-224, SHA-256, and RIPEMD-160
|
| |
|
|
|
| |
using hashes SHA-224, SHA-256, SHA-384, SHA-512, RIPEMD-128, RIPEMD-160,
and Whirlpool.
|
| |
|
|
| |
Crypto++ 5.5.2 on motoko (x86-64 Gentoo)
|
| |
|
|
| |
SHA-384, and SHA-512 generated using Crypto++ 5.5.2
|
| |
|
