aboutsummaryrefslogtreecommitdiffstats
path: root/src/pubkey/pkcs8.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Shuffle things around. Add NIST X.509 test to build.lloyd2014-01-011-284/+0
|
* Split asn1_obj.h into asn1_alt_name.h, asn1_attribute.h, andlloyd2012-11-061-1/+1
| | | | asn1_time.h
* Modify DL_Group::PEM_decode and BER_decode to take values instead oflloyd2012-06-051-1/+1
| | | | | | | | DataSource&. Remove spurious DataSource_Memory from ec_group.cpp Some indent fixes
* Add new PBKDF interface that takes a std::chrono::milliseconds andlloyd2012-05-311-15/+14
| | | | | | | | | | | | | | | | | | | | runs the KDF until at least that much time has passed, then returns the number of interations used. New parameter to the PKCS8 encryption routines which tells how long to run the PBKDF. Defaults to 200 milliseconds, which is short enough that it is unlikely to bother anyone but long enough to provide quite reasonable security against cracking attacks. On a Core i7-860, 200 ms with PBKDF2/SHA-1 runs about 180K to 220K iterations (compare with previous default of 10K). New PBE interface, remove new_params/set_key and require all inputs including the passphrase to be passed to the constructor. Drop the PGP S2K as it is pretty weird and not really useful outside of a full PGP implementation. Drop the deprecated PKCS8::encrypt_key and PKCS8::encode functions.
* Fairly huge update that replaces the old secmem types with std::vectorlloyd2012-05-181-9/+9
| | | | | | 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.
* propagate from branch 'net.randombit.botan' (head ↵lloyd2011-02-111-15/+41
|\ | | | | | | | | | | 13a0d36dac3709f3cb88e830ed7f8cab9e7433ab) to branch 'net.randombit.botan.c++0x' (head 2221ad8796466e7e096645de77ba856a9c902d14)
| * propagate from branch 'net.randombit.botan' (head ↵lloyd2010-10-131-15/+41
| |\ | | | | | | | | | | | | | | | 2898d79f992f27a328a3e41d34b46eb1052da0de) to branch 'net.randombit.botan.c++0x' (head 6cba76268fd69a73195760c021b7f881b8a6552c)
| | * propagate from branch 'net.randombit.botan' (head ↵lloyd2010-08-131-15/+41
| | |\ | | | | | | | | | | | | | | | | | | | | 0a3348f52bf558bc2282e1066c2913a72a1aeda5) to branch 'net.randombit.botan.c++0x' (head 552c20ae8874f12da779fc25ea368e36e71cbfe8)
| | | * Drop User_Interface; replace with a std::function callbacklloyd2010-07-091-13/+39
| | | |
| | | * propagate from branch 'net.randombit.botan' (head ↵lloyd2010-06-171-52/+21
| | | |\ | | | | | | | | | | | | | | | | | | | | | | | | | 294e2082ce9231d6165276e2f2a4153a0116aca3) to branch 'net.randombit.botan.c++0x' (head 0b695fad10f924601e07b009fcd781191fafcb28)
| | | * \ propagate from branch 'net.randombit.botan' (head ↵lloyd2010-03-211-2/+2
| | | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 96d0a1885774b624812fd143d541c8bcda319217) to branch 'net.randombit.botan.c++0x' (head e14368ab9d7976f3e111c6bc0adf24eebeb7c114)
| | | | * \ propagate from branch 'net.randombit.botan' (head ↵lloyd2010-03-091-2/+2
| | | | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 9932d4d63417f7fcc199ada244cbaa6c1c32d9c1) to branch 'net.randombit.botan.c++0x' (head f4a385a376311edc62ef506c72cc56f69e6efd5a)
* | | | | | | Convert the BER/DER coders to use size_t instead of u32bit for smalllloyd2011-02-091-2/+2
|/ / / / / / | | | | | | | | | | | | | | | | | | integer values. Update callers.
* | | | | | Use size_t instead of u32bit in all of pubkeylloyd2010-10-121-2/+2
| | | | | |
* | | | | | More changes to avoid vector to pointer implicit conversionslloyd2010-09-141-1/+1
|/ / / / /
* | | | / The changelog for 1.9.4 claimed that the default PKCS #8 encryptionlloyd2010-08-131-1/+1
| |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | New BER encoding funcs for PKCS and X.509. Remove Private_Key dep herelloyd2010-06-151-35/+28
| | | |
* | | | Simplify PKCS8::copy_keylloyd2010-06-151-7/+1
| | | |
* | | | Some PKCS #8 simplificationslloyd2010-06-141-21/+3
|/ / /
* / / Add a couple of new helper functions to BER_Decoder:lloyd2010-03-191-6/+1
|/ / | | | | | | | | | | | | | | | | | | decode_and_check takes an expected value; if the decoded value does not match, a Decoding_Error with a specified string is thrown. Useful for checking embedded version codes. decode_octet_string_bigint is for decoding INTEGER values that are stored as OCTET STRINGs. Totally obnoxious and useless, but common especially in the ECC standards.
* | Quite the hack, here.lloyd2010-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GOST 34.10 public keys use a funky encoding. There is no standard for PKCS #8 format private keys, so the obvious choice is to act exactly the same as ECDSA/ECDH (following the rule of thumb that if you're going to make up a random non-standard thing, at least try to copy something that's standard for something else). However the public key encoding uses a weird scheme for encoding the OID in the algorithm identifier, which we don't want to use for the PKCS #8 encoding. Add a new function to Private_Key, pkcs8_algorithm_identifier, which by default just calls algorithm_identifier(). However GOST_3410_PrivateKey overrides it, and calls EC_PublicKey::algorithm_identifier(), basically skipping over the virtual function hierarchy, so it doesn't pick up the funky format from the public key's version of algorithm_identifier().
* | Add a new constructor to each public key algorithm (only the publiclloyd2010-03-041-16/+2
| | | | | | | | | | | | | | keys so far, private keys not changed) that takes an AlgorithmIdentifier and a MemoryRegion<byte>&. This performs the X.509 decoding. It is not possible anymore to create uninitialized PK objects.
* | The code in pk_codecs was actually entirely tied to the code inlloyd2010-03-041-0/+309
|/ | | | | | pubkey; you literally could not compile any pubkey code without it. Move it up to the pubkey dir, it wasn't at all useful to have it in its own dir.
* Move back to pk_codecs, propagate to pubkey-refactor donelloyd2009-07-211-313/+0
|
* Move from pk_codecs to pubkey to solve merge problemlloyd2009-07-211-0/+313