| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
range of single bit errors in DES (though really this method is more
useful for a hardware implementation than table based software).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
More commentary posted to the list:
http://lists.randombit.net/pipermail/botan-devel/2010-May/001123.html
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
| |
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.
|
| |
|