| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
using a custom allocator. Currently our allocator just does new/delete
with a memset before deletion, and the mmap and mlock allocators have
been removed.
|
|\
| |
| |
| |
| |
| | |
6332543aa5a8a4cc13662008ff9ac0f0016d9a4d)
to branch 'net.randombit.botan.cxx11' (head 5517c9f8f6d1990f269afb94f569a97a80c5a5f4)
|
| |
| |
| |
| | |
caused huge performance issues with DSA/ECDSA signing performance.
|
|\|
| |
| |
| |
| |
| | |
c247a55e7c0bcd239fcfc672139b59ef63d7ee84)
to branch 'net.randombit.botan.cxx11' (head 16d7756c6b8933d0d543ebdda9c7e8f4908a4a33)
|
| |
| |
| |
| |
| |
| |
| | |
how much we ask for on the basis of how many bits we're counting each
byte as contributing. Change /dev/*random estimate to 7 bits per byte.
Small cleanup in HMAC_RNG.
|
| |
| |
| |
| |
| |
| | |
waiting for a full kilobyte. This is for the benefit of DSA/ECDSA
which want a call to add_entropy to update the state in some way,
passing just a hash input which might be as small as 20 bytes.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use auto in a few more places. Use GCC 4.6's range-for
Delete rather than hide Algorithm copy constructor/assignment
Move version to more or less randomly chosen 1.99 so there is no
ambiguity about versions.
|
|\ \
| |/
|/|
| |
| |
| | |
303b2518a80553214b1e5ab4d9b96ef54629cbc7)
to branch 'net.randombit.botan.c++0x' (head d734eefabe4816be4dd3e3e6e7bb13b7ab5be148)
|
| |\
| | |
| | |
| | |
| | |
| | | |
2898d79f992f27a328a3e41d34b46eb1052da0de)
to branch 'net.randombit.botan.c++0x' (head 6cba76268fd69a73195760c021b7f881b8a6552c)
|
| | |\
| | | |
| | | |
| | | |
| | | |
| | | | |
294e2082ce9231d6165276e2f2a4153a0116aca3)
to branch 'net.randombit.botan.c++0x' (head 0b695fad10f924601e07b009fcd781191fafcb28)
|
| | |\ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
a5f25a3b954f24c5d07fa0dab6c4d76f63767165)
to branch 'net.randombit.botan.c++0x' (head a365694b70b4b84ca713272d56d496acca351cb5)
|
| | |\ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
75d272c759511a9a99a371ddc74bd17b2c1453b6)
to branch 'net.randombit.botan.c++0x' (head 2ce9ba37cb9287a3d875921240d6682100625b9f)
|
| | |\ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
96d0a1885774b624812fd143d541c8bcda319217)
to branch 'net.randombit.botan.c++0x' (head e14368ab9d7976f3e111c6bc0adf24eebeb7c114)
|
| | | |\ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
5bfc3e699003b86615c584f8ae40bd6e761f96c0)
to branch 'net.randombit.botan.c++0x' (head 8c64a107b58d41f376bfffc69dfab4514d722c5c)
|
| | | | |\ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
12382647ef0a28fcb11c824c77b670cc88a4f721)
to branch 'net.randombit.botan.c++0x' (head b586a3286d2c4d547ad3add5af9df1455bf4b87b)
|
| | | | | |\ \ \ \
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
14c1d4dc8696d2705a70ec3d2403e01d2ca95265)
to branch 'net.randombit.botan.c++0x' (head c567fa7310ba082a837562092728c4b4b882bf82)
|
| | | | | | | | | | |
|
| | | | | | |\ \ \ \
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
744dccf92270cf16b80b50ee2759424c9866b256)
to branch 'net.randombit.botan.c++0x' (head 2aa1acac1d05e8ea9991fe39015b1db9abc3b24e)
|
| | | | | | |\ \ \ \ \
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
b3515264af291b4785d3d296e2cc0e877ca7816a)
to branch 'net.randombit.botan.c++0x' (head 66ca78008f08bb5efc2eca52a3d4501f02ffd736)
|
| | | | | | |\ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
cfb19182987fc95b2a8885584a38edb10b4709b3)
to branch 'net.randombit.botan.c++0x' (head 1570877c463fed4b632bc49a5b5ee27c57de2cb5)
|
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
It will be nice to convert to the range-based for loop once that's available.
|
| | | | | | |\ \ \ \ \ \ \
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
2773c2310e8c0a51975987a2dd6c5824c8d43882)
to branch 'net.randombit.botan.c++0x' (head f13cf5d7e89706c882604299b508f356c20aae3a)
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
(which will go later) which will live in the new time.h
|
| | | | | | | |\ \ \ \ \ \ \
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
139d6957d20f0b1202e0eacc63cb011588faffde)
to branch 'net.randombit.botan.c++0x' (head c16676fa6c393bc3f46a044755ce525a013380a6)
|
| | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | |
|
|/ / / / / / / / / / / / / /
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
the parameters of the key length. Instead define a new function which
returns a simple object which contains this information.
This definitely breaks backwards compatability, though only with code
that directly manipulates low level objects like BlockCipher*s
directly, which is probably relatively rare.
Also remove some deprecated accessor functions from lookup.h. It turns
out block_size_of and output_size_of are being used in the TLS code; I
need to remove them from there before I can delete these entirely.
Really that didn't make much sense, because they assumed all
implementations of a particular algorithm will have the same
specifications, which is definitely not necessarily true, especially
WRT key length. It is much safer (and probably simpler) to first
retrieve an instance of the actual object you are going to use and
then ask it directly.
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
Add RandomNumberGenerator::random_vec, which takes an length n and
returns a new SecureVector with randomized contents of that size. This
nicely covers most of the cases where randomize was being called on a
vector, and is a little cleaner in the code as well, instead of
vec.resize(length);
rng.randomize(&vec[0], vec.size());
we just write
vec = rng.random_vec(length);
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
representation (rather than in an interator context), instead use &buf[0],
which works for both MemoryRegion and std::vector
|
| | | | | | | | | | | | | | |
|
| |_|_|_|_|_|_|_|_|_|_|_|/
|/| | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
harmonising MemoryRegion with std::vector:
The MemoryRegion::clear() function would zeroise the buffer, but keep
the memory allocated and the size unchanged. This is very different
from STL's clear(), which is basically the equivalent to what is
called destroy() in MemoryRegion. So to be able to replace MemoryRegion
with a std::vector, we have to rename destroy() to clear() and we have
to expose the current functionality of clear() in some other way, since
vector doesn't support this operation. Do so by adding a global function
named zeroise() which takes a MemoryRegion which is zeroed. Remove clear()
to ensure all callers are updated.
|
| | | | | | | | | | | | | |
|
| |_|_|_|_|_|_|_|_|_|_|/
|/| | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
entirely. add_entropy() just adds the input into the extractor; if
more than 1024 bytes of input have been added by the user since the
last reseed, then force a reseed. Until that point, the data simply
remains accumulating in the extractor, which is fast and helps ensure
a large block of data is input when we finally do reseed.
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
contents of all SSL/TLS handshake messages into the PRNG input.
|
| |_|_|_|_|_|_|_|_|_|/
|/| | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
to be named differently from add_entropy to deal with odd C++
overloading/virtual rules.
|
|/ / / / / / / / / / |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
to mix in with the user input.
Check that the prf and extractor are compatible.
For the initial PRF key, use all zeros of the appropriate size,
and for the initial XTS key, use PRF("Botan HMAC_RNG XTS"). This
ensures that only the one fixed key size is ever used with either
the prf or extractor objects, allowing you to use, say
HMAC(SHA-256)+CMAC(AES-256), or even CMAC(AES-128)+CMAC(AES-128)
as the PRFs in the RNG.
|
|/ / / / / / / / /
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
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
|
|/ / / / / / / /
| | | | | | | |
| | | | | | | |
| | | | | | | | |
including loadstor.h actually just needed get_byte and nothing else.
|
|/ / / / / / /
| | | | | | |
| | | | | | |
| | | | | | | |
of AES-NI instructions, etc, in the PRNGs.
|
| |_|_|_|_|/
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
bswap.h); too many external apps rely on loadstor.h existing.
Define 64-bit generic bswap in terms of 32-bit bswap, since it's
not much slower if 32-bit is also generic, and much faster if
it's not. This may be quite helpful on 32-bit x86 in particular.
Change formulation of generic 32-bit bswap. It may be faster or
slower depending on the CPU, especially the latency and throuput
of rotate instructions, but should be faster on an ideally
superscalar processor with rotate instructions (ie, what I expect
future CPUs to look more like).
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fixes for the amalgamation generator for internal headers.
Remove BOTAN_DLL exporting macros from all internal-only headers;
the classes/functions there don't need to be exported, and
avoiding the PIC/GOT indirection can be a big win.
Add missing BOTAN_DLLs where necessary, mostly gfpmath and cvc
For GCC, use -fvisibility=hidden and set BOTAN_DLL to the
visibility __attribute__ to export those classes/functions.
|
| |_|_|_|/
|/| | | | |
|