aboutsummaryrefslogtreecommitdiffstats
path: root/src/rng/hmac_rng
Commit message (Collapse)AuthorAgeFilesLines
* Use output_length() instead of OUTPUT_LENGTH pseudo-propertylloyd2010-10-131-4/+4
|
* Use size_t instead of u32bit in entropy and rnglloyd2010-10-122-11/+11
|
* More changes to avoid vector to pointer implicit conversionslloyd2010-09-141-3/+3
|
* Handle the case that container size() returns something other than u32bitlloyd2010-09-141-1/+1
|
* Anywhere where we use MemoryRegion::begin to get access to the raw pointerlloyd2010-09-131-1/+1
| | | | | representation (rather than in an interator context), instead use &buf[0], which works for both MemoryRegion and std::vector
* Big, invasive but mostly automated change, with a further attempt atlloyd2010-09-071-2/+2
| | | | | | | | | | | | | | 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.
* Yet more Doxygen commentslloyd2010-06-162-8/+12
|
* HMAC_RNG handling changes - split up reseed() and add_entropy()lloyd2010-04-272-35/+31
| | | | | | | | entirely. add_entropy() just adds the input into the extractor; if more than 1024 bytes of input have been added by the user since the last reseed, then force a reseed. Until that point, the data simply remains accumulating in the extractor, which is fast and helps ensure a large block of data is input when we finally do reseed.
* In add_entropy(), additionally poll for 64 bits of system entropylloyd2010-03-191-15/+20
| | | | | | | | | | | | | to mix in with the user input. Check that the prf and extractor are compatible. For the initial PRF key, use all zeros of the appropriate size, and for the initial XTS key, use PRF("Botan HMAC_RNG XTS"). This ensures that only the one fixed key size is ever used with either the prf or extractor objects, allowing you to use, say HMAC(SHA-256)+CMAC(AES-256), or even CMAC(AES-128)+CMAC(AES-128) as the PRFs in the RNG.
* Move the get_byte template to its own header, because many fileslloyd2010-02-021-1/+1
| | | | including loadstor.h actually just needed get_byte and nothing else.
* Un-internal loadstor.h (and its header deps, rotate.h andlloyd2009-12-211-1/+1
| | | | | | | | | | | | | | bswap.h); too many external apps rely on loadstor.h existing. Define 64-bit generic bswap in terms of 32-bit bswap, since it's not much slower if 32-bit is also generic, and much faster if it's not. This may be quite helpful on 32-bit x86 in particular. Change formulation of generic 32-bit bswap. It may be faster or slower depending on the CPU, especially the latency and throuput of rotate instructions, but should be faster on an ideally superscalar processor with rotate instructions (ie, what I expect future CPUs to look more like).
* Make many more headers internal-only.lloyd2009-12-161-3/+3
| | | | | | | | | | | | | Fixes for the amalgamation generator for internal headers. Remove BOTAN_DLL exporting macros from all internal-only headers; the classes/functions there don't need to be exported, and avoiding the PIC/GOT indirection can be a big win. Add missing BOTAN_DLLs where necessary, mostly gfpmath and cvc For GCC, use -fvisibility=hidden and set BOTAN_DLL to the visibility __attribute__ to export those classes/functions.
* Full working amalgamation build, plus internal-only headers concept.lloyd2009-12-161-7/+0
|
* Rename/remove some secmem member variables for better matching with STLlloyd2009-11-171-1/+1
| | | | | | | | containers (specifically vector). Rename is_empty to empty Remove has_items Rename create to resize
* Remove the 'realname' attribute on all modules and cc/cpu/os info files.lloyd2009-10-291-2/+0
| | | | | Pretty much useless and unused, except for listing the module names in build.h and the short versions totally suffice for that.
* Remove all exception specifications. The way these are designed in C++ islloyd2009-10-222-2/+2
| | | | | | just too fragile and not that useful. Something like Java's checked exceptions might be nice, but simply killing the process entirely if an unexpected exception is thrown is not exactly useful for something trying to be robust.
* Split up util.h into 3 fileslloyd2009-09-171-1/+0
| | | | | | | - rounding.h (round_up, round_down) - workfactor.h (dl_work_factor) - timer.h (system_time) And update all users of the previous util.h
* Add a script that reads the output of print_deps.py and rewriteslloyd2009-07-151-0/+4
| | | | | | the info.txt files with the right module dependencies. Apply it across the codebase.
* Improve handling of low-entropy situations in HMAC_RNG and Randpool.lloyd2009-06-211-4/+7
| | | | | | | | | | | When a reseed is attempted, up to poll_bits attempts will be made, running in order through the set of available sources. So for instance if poll_bits is set to the default 256, then up to 256 polls will be performed (some of which might not provide any entropy, of course) before stopping; of course if the accumulators goal is achived before that point, then the polling stops. This should greatly help to resolve the recent rash of PRNG unseeded problems some people have been having.
* Many source files included bit_ops.h when what was really desired waslloyd2009-05-131-1/+0
| | | | | rotate.h, or when it was not needed at all. Remove or change the includes as needed.
* Thomas Moschny passed along a request from the Fedora packagers which camelloyd2009-03-302-0/+4
| | | | | | | | | | | | | | | up during the Fedora submission review, that each source file include some text about the license. One handy Perl script later and each file now has the line Distributed under the terms of the Botan license after the copyright notices. While I was in there modifying every file anyway, I also stripped out the remainder of the block comments (lots of astericks before and after the text); this is stylistic thing I picked up when I was first learning C++ but in retrospect it is not a good style as the structure makes it harder to modify comments (with the result that comments become fewer, shorter and are less likely to be updated, which are not good things).
* Remove the notion of counting entropy bits in HMAC_RNG or Randpool.lloyd2009-01-312-17/+6
| | | | | | | | | Instead simply consider the PRNG seeded if a poll kicked off from reseed met its goal, or if the user adds data. Doing anything else prevents creating (for instance) a PRNG seeded with 64 bits of entropy, which is unsafe for some purposes (key generation) but quite possibly safe enough for others (generating salts and such).
* Make Entropy_Accumulator a pure virtual to allow other accumulationlloyd2009-01-311-1/+1
| | | | | techniques, with the one using BufferedComputation being the new subclass with the charming name Entropy_Accumulator_BufferedComputation.
* Have Entropy_Accumulator dump everything into a BufferedComputation.lloyd2009-01-271-3/+1
| | | | | | | | | | | | Since both Randpool and HMAC_RNG fed the input into a MAC anyway, this works nicely. (It would be nicer to use tr1::function but, argh, don't want to fully depend on TR1 quite yet. C++0x cannot come soon enough). This avoids requiring to do run length encoding, it just dumps everything as-is into the MAC. This ensures the buffer is not a potential narrow pipe for the entropy (for instance, one might imagine an entropy source which outputs one random byte every 16 bytes, and the rest some repeating pattern - using a 16 byte buffer, you would only get 8 bits of entropy total, no matter how many times you sampled).
* Major change in RNG semantics: you must call reseed before callinglloyd2009-01-271-13/+2
| | | | randomize, or PRNG_Unseeded will be thrown.
* Check in a branch with a major redesign on how entropy polling is performed.lloyd2009-01-272-120/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Combine the fast and slow polls, into a single poll() operation. Instead of being given a buffer to write output into, the EntropySource is passed an Entropy_Accumulator. This handles the RLE encoding that xor_into_buf used to do. It also contains a cached I/O buffer so entropy sources do not individually need to allocate memory for that with each poll. When data is added to the accumulator, the source specifies an estimate of the number of bits of entropy per byte, as a double. This is tracked in the accumulator. Once the estimated entropy hits a target (set by the constructor), the accumulator's member function predicate polling_goal_achieved flips to true. This signals to the PRNG that it can stop performing polling on sources, also polls that take a long time periodically check this flag and return immediately. The Win32 and BeOS entropy sources have been updated, but blindly; testing is needed. The test_es example program has been modified: now it polls twice and outputs the XOR of the two collected results. That helps show if the output is consistent across polls (not a good thing). I have noticed on the Unix entropy source, occasionally there are many 0x00 bytes in the output, which is not optimal. This also needs to be investigated. The RLE is not actually RLE anymore. It works well for non-random inputs (ASCII text, etc), but I noticed that when /dev/random output was fed into it, the output buffer would end up being RR01RR01RR01 where RR is a random byte and 00 is the byte count. The buffer sizing also needs to be examined carefully. It might be useful to choose a prime number for the size to XOR stuff into, to help ensure an even distribution of entropy across the entire buffer space. Or: feed it all into a hash function? This change should (perhaps with further modifications) help WRT the concerns Zack W raised about the RNG on the monotone-dev list.
* Reduce size of I/O buffer in HMAC_RNG from 128 to 96 bytes. Unlikely that anylloyd2008-11-231-1/+1
| | | | | entropy source will realistically be able to provide even 768 bits of entropy, so this is probably overkill even still.
* In Randpool and HMAC_RNG, zeroize the I/O buffer used for holding polledlloyd2008-11-231-0/+3
| | | | randomness data after the contents have been fed into the MAC.
* Drop use of entropy estimation in Randpool for the same reason as HMAC_RNG.lloyd2008-11-111-1/+0
| | | | | | As with HMAC_RNG, instead assume one bit of conditional entropy per byte of polled material. Since they are no longer used, drop the entropy estimation routines entirely.
* Wrap at 80 columnslloyd2008-11-111-1/+3
|
* Several changes to HMAC_RNG, many on the basis of the paperlloyd2008-11-101-27/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Boaz Barak, Shai Halevi: A model and architecture for pseudo-random generation with applications to /dev/random. ACM Conference on Computer and Communications Security 2005. which I was referred to by Hugo Krawczyk. Changes include: Remove the entropy estimation. This is a major point of Barak and Halevi's paper: the entropy we want to estimate is the condtional entropy of the collected data from the point of view of an unknown attacker. Obviously this cannot be computed! Instead HMAC_RNG simply counts each byte of sampled data as one bit of estimated entropy. Increase the reseed threshold from 2^14 to 2^20 outputs, and change the fast poll during generation from once every 1024 outputs to once every 65536 outputs (though the fast poll might not trigger that often, if output lengths are very large - however this doesn't really matter much, and with the X9.31 wrapper it does kick off exactly every 2^16 outputs). The paper also has some good arguments why it is better to reseed rarely, making sure you have collected a large amount of (hopefully) unguessable state. Remove a second HMAC PRF operation which was only being done to destroy the previous K value. Considering it has a short lifetime, seems excessive (and really hurt performance).
* Move declaration of MessageAuthenticationCode base class to mac.h (from base.h)lloyd2008-11-081-1/+1
|
* In HMAC_RNG, periodically fast poll a source while operating normally.lloyd2008-11-072-46/+32
| | | | | Generate new XTS (extractor salt) values using PRF outputs rather than the clock.
* HMAC_RNG will only check to see if it should reseed once per calllloyd2008-11-071-60/+47
| | | | | | | | | | | | to randomize(), at the start of the function. After that it will generate as many outputs as needed. The counter cannot overflow, as only up to 2**32 bytes can be requested per call to RandomNumberGenerator::randomize, wheras HMAC_RNG can generate 32 bytes (256 bits) per counter value and uses a 32-bit counter. The PRF is 'stepped' once after the call to RandomNumberGenerator::randomize is completed. This reduces the window of exposure to data that was already output for use by the RNG.
* Disable final upper bound limit since the min takes care of itlloyd2008-11-061-5/+1
|
* Move Entropy_Estimator to utils/entropy.h (from anon namespace in HMAC_RNGlloyd2008-11-062-57/+12
| | | | | implementation), remove freestanding estimate_entropy function, change Randpool to use entropy estimator.
* In HMAC_RNG, force a reseed after 8192 blockslloyd2008-10-281-0/+3
|
* Clear K after new PRK is generated.lloyd2008-10-281-4/+7
|
* Set the default XTS (ASCII value of "Botan HMAC_RNG XTS") only once, inlloyd2008-10-281-86/+92
| | | | | | | the constructor. This avoids repeatedly resetting it for each reseed, if HMAC_RNG is used without entropy sources and using only application-provided entropy. Very slightly more efficient and also the code for reseed becomes a bit clearer.
* Add HMAC_RNG, which is an RNG design based on Hugo Krawczyk's paperlloyd2008-10-283-0/+403
"On Extract-then-Expand Key Derivation Functions and an HMAC-based KDF". While it has much smaller state than Randpool (256-512 bits, typically, versus 4096 bits commonly used in Randpool), the more formal design analysis seems attractive (and realistically if the RNG can manage to contain 256 bits of conditional entropy, that is more than sufficient).
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 15:38:27 +0000