| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Check the cache; if found, return value
- Populate cache, if the value is already there, delete the old
object and save the new one.
- Recheck the cache value
Raja <[email protected]> pointed out on the list that this could race
if multiple threads called a lookup function in close succession while
the cache was cold. All of them would fail the lookup, then each of
them would add it, but the values returned would be deleted by other
threads.
Instead, declare that first write wins. Then, the cache stays
consistent even if there is a race, the only issue is an extra search
and delete.
Modify GOST and Skein, as their name() function did not roundtrip
properly which caused failures otherwise.
|
|
|
|
| |
coalesce the dir and file name if identical.
|
|
|
|
|
|
|
|
| |
amalgamation properly, but would happen to work if a previously
written amalgamation was around.
Also make changes allowing using the SIMD optimized versions of SHA-1
and Serpent to be used in the amalgamation.
|
|
|
|
|
|
| |
Back the reported version from 1.10.0 to 1.9.17 for the time
being. Still on the fence if this will be 1.10.0 or another release
candidate instead.
|
|
|
|
| |
added to the flags here.
|
|
|
|
|
|
|
| |
disabled under gcc.
Hide asm labels in the x86-32 code; some did not begin with a .L so
they were being exported.
|
| |
|
|
|
|
| |
an i7-860 goes from 197 MiB/s to 256 - a 30% improvement!
|
|
|
|
|
|
| |
registers as needed (16 turns before the value is used), with indexes
fully precomputed. On a Core i7-860 with GCC 4.5.2, performance went
from 152 MiB/s to 167 MiB/s.
|
|
|
|
|
| |
Only change is the padding rule. It 'simplifies' the padding by making
it less flexible and harder to implement efficiently. :(
|
| |
|
|
|
|
|
| |
to the level of the version using xor_buf, at least on a little-endian
CPU.
|
| |
|
| |
|
|
|
|
|
|
| |
on motoko), but does also reduce memory overhead. Perhaps doing the
XOR by hand and then doing aligned 64-bit XORs where possible would be
beneficial here.
|
| |
|
|
|
|
| |
proposed SHA-3 parameter sets are supported.
|
|
|
|
| |
safe/useful
|
|
|
|
| |
schedule constant to prevent rotational attacks.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
query, clearing, and cloning. Applies to ciphers, hashes, MACs, and
PBKDFs. May extend to KDFs later as well.
A single combined hierarchy in particular will make the algo_factory
much simpler.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
of each other anyway.
|
| |
|
|
|
|
| |
tests on Nehalem indicate a small but measurable win there (about 3%).
|
|
|
|
| |
alternative methods of getting pieces of the expanded message.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the initial/default length of the array, update all users to instead
pass the value to the constructor.
This is a old vestigal thing from a class (SecureBuffer) that used
this compile-time constant in order to store the values in an
array. However this was changed way back in 2002 to use the same
allocator hooks as the rest of the containers, so the only advantage
to using the length field was that the initial length was set and
didn't have to be set in the constructor which was midly convenient.
However this directly conflicts with the desire to be able to
(eventually) use std::vector with a custom allocator, since of course
vector doesn't support this.
Fortunately almost all of the uses are in classes which have only a
single constructor, so there is little to no duplication by instead
initializing the size in the constructor.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
fine with latest SVN.
|
|
|
|
| |
an .S file is, so allow it for x86-64. Tested/works with Clang SVN.
|
|
|
|
|
|
| |
(amd64_eng and ia32_eng) into a new asm_engine. This same engine could
also be used in the event that asm code for other CPUs was added later
on.
|
|
|
|
|
| |
things, just share the compression function via an anon namespace
member, and replicate the simple stuff like copy_out.
|
| |
|
| |
|
| |
|
| |
|