| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
pointer to a nonce struct; presumably for slightly better typechecking.
In case we're compiling under such a mode, case the first argument to
FreeLibrary and GetProcAddress to a HMODULE.
|
|
|
|
| |
the directory when building a DLL
|
|
|
|
|
| |
Use a slightly cleaner invocation that doesn't require duplicating so much
code between the binary and non-binary cases.
|
|
|
|
| |
Tested against a GnuTLS server.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
amount of value. Add a note that -library=stlport4 may be needed on
Linux (seems to depend on glibc version).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Also use -xO5 instead of -xO2; everything seems to work under -xO5 on
x86-32 and x86-64 with my version of Sun Studio. Curiously, several things
are miscompiled with -xO2! Definitely doesn't give me positive feelings
about this optimizer.
|
| |
|
|
|
|
|
| |
to fix compilation on Solaris. Everybody else, including POSIX.1, uses
void* here, but as usual Solaris likes to be special.
|
| |
|
|
|
|
|
| |
way to create a static library using Sun Studio is to invoke the
compiler with the -xar flag.
|
|
|
|
|
|
| |
priorities slightly, pushing netstat -s and netstat -an higher since
they change freqently and don't have a huge amount of output. Use the
-n flag with lsof, which inhibits name lookups which we don't need.
|
| |
|
| |
|
|
|
|
| |
to avoid a Sun Studio bug.
|
|
|
|
|
| |
various compilers/platforms, and likely doesn't contribute much of
anything. Also only grab real uid and gid, ignoring effective ids.
|
|
|
|
| |
checkin.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
really didn't need to.
The ones in symkey and big_code were actually calling accessor
functions to do the encoding themselves without a Pipe (should have
definitely recognized that as a code smell). These versions have
changed semantically with this checkin - previously they would completely
ignore bad inputs, but now invalid inputs are rejected. For instance, you
cannot say
SymmetricKey key("Only some of this is hex, most of it isn't");
And expect to get a valid key formed by filtering out the non-hex
characters and then decoding it. This is almost certainly a good thing.
Also fix include in Botan.xs
|
|
|
|
| |
Required by the hex decoder.
|
|
|
|
|
|
|
|
| |
in terms of these calls.
The header for the hex filter is renamed hex_filt.h. This probably
won't affect people because filters.h (included by botan.h) already
included hex.h, and now just includes hex_filt.h instead.
|
|
|
|
|
|
|
| |
allowed by the standard, however specializing it is. Fix this for
BigInt; it appears the Flexsecure guys knew this since the CurveGFp
and PointGFp classes already uses the template specialization rather
than an overload.
|
|
|
|
|
| |
IA-64 (and, hypothetically, any other 64 bit CPU Visual C++ might
target in the future).
|
|
|
|
| |
yet tested.
|
|\
| |
| |
| | |
and '9e16b5a133480199541647fe245b79b059c9d5ca'
|
| |
| |
| |
| |
| |
| |
| | |
Fix a bug that would cause a harmless but bogus macro to be generated
in build.h if you used --enable-sse2
Add --enable-movbe to turn on a macro marking movbe as available
|
|/
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
| |
passed a ref and having to allocate a new stream object, a little bit
cleaner I think.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
supports epi64x in 64-bit mode.
|
|
|
|
| |
causes obnoxious problems under MinGW.
|
|
|
|
|
|
| |
to pointers-to-functions (which, admittedly, is undefined in ISO C++,
but doing this is required to use dlopen). Using the dumb hammer of a
C-style cast works, though.
|