aboutsummaryrefslogtreecommitdiffstats
path: root/doc
Commit message (Collapse)AuthorAgeFilesLines
* s/x.ptr()/&x[0]/lloyd2010-09-301-5/+5
|
* Document removing appendlloyd2010-09-151-2/+3
|
* Fix examples for destroy being renamed clearlloyd2010-09-132-2/+2
|
* Remove more uses of vector to pointer implicit conversionslloyd2010-09-131-1/+5
|
* Read input as binarylloyd2010-09-081-1/+1
|
* Wording changeslloyd2010-09-081-3/+3
|
* Document recent changeslloyd2010-09-081-2/+5
|
* Specify the target host and port for tls_client on the command linelloyd2010-09-081-3/+18
|
* Big, invasive but mostly automated change, with a further attempt atlloyd2010-09-071-1/+1
| | | | | | | | | | | | | | 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.
* Oops... renamed this quite a while ago, never updated examplelloyd2010-09-071-6/+6
|
* Realization while thinking about the recently added truncate: in a STLlloyd2010-09-071-1/+0
| | | | | | | | | | | | | | | | | | 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.
* Fix dependency update scriptslloyd2010-09-032-2/+2
|
* Document recent changeslloyd2010-09-031-0/+4
|
* Add 1.8.10 change noteslloyd2010-08-311-0/+9
|
* For passhash9, add another interface that allows the caller to specifylloyd2010-08-221-0/+1
| | | | | | | | | | | 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.
* Turns out OpenSSL's implementation of PBKDF2 allows empty passphrases,lloyd2010-08-211-0/+1
| | | | | | | | | | | | | | | | | 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
* In the first round of AES, use a 256 element table and do thelloyd2010-08-181-0/+1
| | | | | | | | | | | | | 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.
* Allow generating larger keys in rsa_kgen example (up to 16K bits)lloyd2010-08-181-1/+1
|
* The changelog for 1.9.4 claimed that the default PKCS #8 encryptionlloyd2010-08-131-1/+4
| | | | | | | | | | 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.
* Update log, readme, configure for 1.9.10 release 2010-08-121.9.10lloyd2010-08-121-1/+1
|
* Add also AES-192 using SSSE3lloyd2010-08-122-1/+4
|
* Missing include, VC++ complainedlloyd2010-08-121-0/+1
|
* Support AES-256 is the SSSE3 implementationlloyd2010-08-121-1/+1
|
* Move the tutorial to old_tutorial since it's badly out of date andlloyd2010-08-092-791/+932
| | | | | | | | | 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.
* Add an implementation of AES-128 using SSSE3 instructions. It runs inlloyd2010-08-091-0/+1
| | | | | | | | | | | | | | | 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.
* Organize CPUID output a little more nicelylloyd2010-07-281-4/+10
|
* Document new engine loaderlloyd2010-07-271-0/+1
|
* Mention byteswap changes, and fix spelling error in 1.9.9 loglloyd2010-07-271-1/+2
|
* Add support in CPUID for detecting PCMULUDQ and MOVBE instructions.lloyd2010-07-271-5/+4
| | | | Rename CPUID::has_aes_intel to has_aes_ni.
* Modify CPUID so all the check functions are purely inline. Add a newlloyd2010-07-261-2/+4
| | | | | initialize() call which must be called prior to use of any other functions.
* Consolidate the two engines that provided assembler implementationslloyd2010-07-131-0/+1
| | | | | | (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.
* Removed UI herelloyd2010-07-121-3/+1
|
* Drop support for running configure with Python 2.4. This allowslloyd2010-07-092-2/+3
| | | | | | | | | 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.
* Small tweaks re 2to3lloyd2010-07-091-4/+4
|
* Rename S2K to PBKDF, because that is by far the most common name - S2Klloyd2010-07-097-70/+72
| | | | | | | | | | | | | 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.
* Read and save the files in binary mode to avoid weird EOF problemslloyd2010-07-072-2/+2
| | | | on Windows.
* Tick version to 1.9.10-devlloyd2010-06-301-0/+3
|
* Tick readme, log, configure for 1.9.9 releaselloyd2010-06-281-1/+1
|
* The fix for build.h also fixes a problem compiling under Apple's GCC 4.2lloyd2010-06-281-0/+1
|
* Give all Filter objects a method for querying their namelloyd2010-06-281-0/+1
|
* Add detection support for upcoming AVXlloyd2010-06-251-0/+1
|
* Reorganize building guide, putting the most important things near thelloyd2010-06-221-59/+101
| | | | | front. Describe more on how to use 2to3, and also describe how to use the amalgamation.
* Document other changes since 1.9.8lloyd2010-06-211-0/+3
|
* Reorder by date then versionlloyd2010-06-181-16/+16
|
* Import the 1.8.9 release noteslloyd2010-06-161-0/+13
|
* Mention Doxygen updates in release loglloyd2010-06-161-0/+1
|
* Increase the iteration count and salt size used for encryptedlloyd2010-06-151-0/+1
| | | | | | | | | | | | | | | | private keys. For the older PBES1, we can only increase the iteration count (from 2048 to 10000); the salt is fixed by the standard to 64 bits. This is probably OK, since PBES1 is also limited to (at best) 64-bit encryption keys and thus is pretty unsafe anyway. For PBES2, increase the iteration count (also 2048 to 10000) and increase the size of the salt from 64 bits to 96 bits. This will only affect keys which are encrypted by a version after this revision.
* More API ref updateslloyd2010-06-151-196/+194
|
* Move reading list to the start, want people to see thislloyd2010-06-151-44/+46
|
* Cleanups, remove dead wordslloyd2010-06-151-191/+204
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 23:26:49 +0000