| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
referencing it.
|
| |
|
| |
|
| |
|
|
|
|
| |
schedule constant to prevent rotational attacks.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
container like vector, truncate is simply resize, but what
MemoryRegion called resize will zap the entire contents, and then what
was resize was called grow_to. This is really problematic in terms of
the goal of replacing MemoryRegion with a vector with a custom
allocator.
In this checkin:
- Remove MemoryRegion::grow_to and MemoryRegion::truncate
- Change the semantics of MemoryRegion::resize to change the size
while keeping any current contents intact (up to the new size),
zero initializing any new values.
Unrelated, just noticed the lack while I was in there, add a version
of CryptoBox::decrypt taking a std::string for the input.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
which PRF they want to use. The old interface just calls this new
version with alg_id set to 0 which is HMAC(SHA-1), which was
previously the only supported PRF.
Assign new codepoints for HMAC(SHA-256) and CMAC(Blowfish) to allow
their use with passhash9.
Have the generate+check tests run a test for each supported PRF.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rotations in the code. This reduces the number of cache lines
potentially accessed in the first round from 64 to 16 (assuming 64
byte cache lines). On average, about 10 cache lines will actually be
accessed, assuming a uniform distribution of the inputs, so there
definitely is still a timing channel here, just a somewhat smaller
one.
I experimented with using the 256 element table for all rounds but it
reduced performance significantly and I'm not sure if the benefit is
worth the cost or not.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
algorithm had changed to AES-256. This was wrong, it actually changed
to AES-128. However in retrospect AES-256 is probably a reasonable
move (in particular for the 4 extra rounds; the related key attacks
possible against AES-256 are probably not viable since we generate the
key using PBKDF2), so update the 1.9.4 changelog to correctly indicate
the change made in that release, and also modify PKCS #8 to actually
use AES-256.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
doesn't really answer questions people commonly have. Add the first
bits of a new tutorial that will hopefully be more helpful; more of a
"Q: I want to do X, how do I do this?" "A: You do X with this code
..." and spending less time doing things like incrementally building
code starting from poorly done versions since that really is probably
just confusing people.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constant time and on a Nehalem is significantly faster than the table
based version. This implementation technique was invented by Mike
Hamburg and described in a paper in CHES 2009 "Accelerating AES with
Vector Permute Instructions". This code is basically a translation of
his public domain x86-64 assembly code into intrinsics.
Todo: Adding support for AES-192 and AES-256; this just requires
implementing the key schedules.
Currently only tested on an i7 with GCC (32 and 64 bit code);
testing/optimization on 32-bit processors with SSSE3 like the Atom,
and with Visual C++ and other compilers, are also todos.
|
| |
|
| |
|
| |
|
|
|
|
| |
Rename CPUID::has_aes_intel to has_aes_ni.
|
|
|
|
|
| |
initialize() call which must be called prior to use of any other
functions.
|
|
|
|
|
|
| |
(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.
|
| |
|
|
|
|
|
|
|
|
|
| |
removing several workarounds for limitations in optparse in that
release, and also allows using the ternary operator added in 2.5.
As far as I can tell, the only still active release of any Linux/BSD
distro that uses 2.4 is RHEL5. The beta of RHEL6 has 2.6, and it seems
likely that RHEL6 will be out before 1.10.0.
|