| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Crypto++ 5.6.0. Includes several largeish (64 and 128 block) tests, as
further tests for a future bitslice implementation.
|
| |
|
|
|
|
|
|
|
|
| |
or 128-bit cipher, but so far only 128-bit ciphers had been tested. I could
not find another implementation of XTS supporting 3DES so these may be wrong,
but at least this ensures they will be consistently wrong.
Mostly in the smaller range (9 to 128 bytes) plus a few with large inputs
(64 blocks) because if a bitslice DES implementation is ever added a test
that actually does 64 blocks in parallel will be needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
cause bad results if the input was not an even multiple of the block
size.
No released version was broken because the changes which caused the
problem were related to using Buffered_Filter, which was introduced
after 1.9.3 was released.
Add more XTS test vectors using AES, Serpent, and Twofish. The AES
tests come from Brian Gladman's XTS implementation. The Serpent and
Twofish tests were generated by botan.
|
| |
|
|
| |
and 1.6x faster using SIMD_Scalar.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
faster than the scalar version on a Core2.
|
| |
|
|
|
|
| |
AES-256 blocks, plus a handful remaining in a general AES block.
This is necessary for any implementation which only supports a particular
key size, since otherwise no tests at all will run on that implementation.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
StreamCipher_Filter
to pass it directly to a Pipe now.
|
| |
|
|
|
|
| |
Remove the Decrypt direction cipher mode tests - now both directions
are always tested for all modes. Also add IVs for Salsa20 (were implicit
all-zeros) since that does not fly anymore in validate.dat
|
| | |
|
| | |
|
| |
|
|
| |
version.
|
| | |
|
| |\
| |
| |
| |
| |
| | |
ef51dd2869ed38dae3aeb1c3b931ca9d595580e1)
to branch 'net.randombit.botan' (head fc1942640045423f411fd865cbd584090b28d7eb)
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Modify ECB to use parallel encryption/decryption where possible
Add toggles in build.h specifying how many blocks to process in parallel.
Defaults to 8 blocks for all modes, which is sufficient that any likely
parallelism can be extracted (via SIMD or concurrent execution) but not
so much as to seem likely to cause cache problems (8*128 bits = 128 bytes,
or two x86 cache lines)
|
| |/
|
|
| |
in the Threefish cipher have changed to increase diffusion.
|
| |
|
|
|
| |
Serpent seems very nicely suited to a SSE2 SIMD implementation, and CTR
mode can handle multiple blocks in parallel. Input lens 1 to 128 bytes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a comment that the limitation of the personalization string
being a maximum of 64 characters is due to the implementation and
not the specification (but it makes it easy to implement, and in
this particular case 64 characters is probably fine).
Add some tests for the personalization option, generated by the
Skein reference implementation.
Disable stripping whitespace in checks/misc.cpp:strip - it strips
the personalization tag, which breaks the test, and isn't needed
otherwise because the test files are well-formed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
commonly used for the GOST 34.11 hash, generated by OpenSSL's GOST code.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GostR3411_94_TestParamSet, this is compatible with the implementations in
Crypto++ and OpenSSL. This is not backwards compatible, though once the
implementation supports multiple param sets (which is required, unfortunately,
for compatability with various standards by CryptoCom, who have defined not
one but at least 4 (!!!) different sboxes to use with GOST), I may offer
Botan's previous sbox set as an option.
Since adding the GOST hash function (34.11) and signing algorithm (34.10)
are on the long term agenda (request by Rickard Bondesson, as the Russian
authorities want to use their local standards for their DNSSEC use), I
renamed the block cipher class (which had been just 'GOST') to GOST_28147_89
to minimize future name clashes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Rename sha256.h and sha_64.h to sha2_32.h and sha2_64.h - this affects
users who instantiate these classes directly.
|
| |
|
|
|
|
|
|
|
|
|
| |
and the TLS v1.0 PRF. These were removed from Botan in v1.4.5.
Initially I had felt that since these protocols were specific to SSL/TLS they
should be placed in Ajisai (an SSL/TLS library based on Botan). However upon
further reflection I have realized it is quite possible that other alternate
implementations of SSL/TLS based on Botan would be quite desirable, and so
to make that (a very slightly bit) easier I am adding back the SSL/TLS
functions to Botan, so other SSL/TLS libs can use them directly.
|
| | |
|
| |
|
|
| |
keying is supported (see section 2.3 of the specification for details)
|
| |
|
|
|
|
|
|
| |
from the NIST CAVS dataset, taken on June 7 2008 from
http://csrc.nist.gov/groups/STM/cavp/standards.html
AES-128, AES-192, AES-256, and 2 and 3-key TripleDES variants are
all tested.
|
| | |
|
| |
|
|
|
|
|
| |
The test vectors were generated by Crypto++ 5.5 on a Linux/x86-64 machine.
Test vectors for CBC-MAC(DES) all pass, for inputs up to 63 bytes. For
CBC-MAC(AES-128), all test vectors with inputs over 10 bytes fail to verify
against what Crypto++ produces. Unknown at this time where the bug lies.
|
| |
|
|
| |
about unknown algorithm names.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
because it turns out to be something of a legal minefield.
|
| |
|
