| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
generated using Crypto++ 5.6.1.
Requested in PR 141.
|
| |
|
|
|
|
|
|
|
| |
derived from a DNSSEC RFC. Bug reported by Bert Hubert to the
mailing list. According to Bert, this ordering is compatible with
the version included in OpenSSL.
Also, benchmark GOST 34.10 using the GOST 34.11 hash since that
is always what it is used with.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
