aboutsummaryrefslogtreecommitdiffstats
path: root/src/rng
Commit message (Collapse)AuthorAgeFilesLines
* More Doxygen updates/fixeslloyd2010-06-152-2/+5
|
* 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.
* Remove add_entropy_vec. Much cleaner way of doing this: add the entirelloyd2010-04-271-3/+0
| | | | contents of all SSL/TLS handshake messages into the PRNG input.
* Add add_entropy_vec which calls add_entropy on the passed vector. Haslloyd2010-04-231-0/+3
| | | | | to be named differently from add_entropy to deal with odd C++ overloading/virtual rules.
* Don't delete the global RNG in AutoSeeded_RNG's destructorlloyd2010-03-231-1/+0
|
* 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.
* There are some nasty API problems that are caused by having to pass alloyd2010-03-193-151/+10
| | | | | | | | | | | | | | | | | | | | | | | | PRNG everywhere. The removal of the global PRNG was generated by a desire to remove the global library state entirely. However the real point of this was to remove the use of globally visible _mutable_ state; of the mutable state, the PRNG is probably the least important, and the most useful to share. And it seems unlikely that thread contention would be a major issue in the PRNG. Add back a global PRNG to Library_State. Use lazy initialization, so apps that don't ever use a PRNG don't need a seeding step. Then have AutoSeeded_RNG call that global PRNG. Offer once again RandomNumberGenerator& Library_State::global_rng(); which returns a reference to the global PRNG. This RNG object serializes access to itself with a mutex. Remove the hack known as Blinding::choose_nonce, replace with using the global PRNG to choose a blinding nonce
* Move the get_byte template to its own header, because many fileslloyd2010-02-022-2/+2
| | | | including loadstor.h actually just needed get_byte and nothing else.
* Use Algorithm_Factory instead of instantiating directly; will allow the uselloyd2010-01-071-10/+14
| | | | of AES-NI instructions, etc, in the PRNGs.
* Un-internal loadstor.h (and its header deps, rotate.h andlloyd2009-12-212-2/+2
| | | | | | | | | | | | | | 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-163-7/+7
| | | | | | | | | | | | | 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-166-45/+10
|
* Consolidate the non-canonical epoch timers, like cpuid and Win32'slloyd2009-12-013-30/+4
| | | | | | | | | | | | | | QueryPerformanceCounter, into an entropy source hres_timer. Its results, if any, do not count as contributing entropy to the poll. Convert the other (monotonic/fixed epoch) timers to a single function get_nanoseconds_clock(), living in time.h, which statically chooses the 'best' timer type (clock_gettime, gettimeofday, std::clock, in that order depending on what is available). Add feature test macros for clock_gettime and gettimeofday. Remove the Timer class and timer.h. Remove the Timer& argument to the algorithm benchmark function.
* Rename/remove some secmem member variables for better matching with STLlloyd2009-11-173-7/+7
| | | | | | | | 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-295-10/+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-228-9/+9
| | | | | | 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.
* propagate from branch 'net.randombit.botan.1_8' (head ↵lloyd2009-10-133-3/+2
|\ | | | | | | | | | | c5ae189464f6ef16e3ce73ea7c563412460d76a3) to branch 'net.randombit.botan' (head e2b95b6ad31c7539cf9ac0ebddb1d80bf63b5b21)
| * Split up util.h into 3 fileslloyd2009-09-172-2/+1
| | | | | | | | | | | | | | - rounding.h (round_up, round_down) - workfactor.h (dl_work_factor) - timer.h (system_time) And update all users of the previous util.h
| * Throw Internal_Error instead of Algorithm_Not_Found if no usable RNGlloyd2009-09-081-1/+1
| | | | | | | | is enabled in the build.
* | Don't make auto_rng require AES; using it is optional as long as HMAC_RNGlloyd2009-10-132-4/+6
|/ | | | is being used and not Randpool.
* Add a script that reads the output of print_deps.py and rewriteslloyd2009-07-155-7/+20
| | | | | | 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-212-8/+14
| | | | | | | | | | | 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.
* Change the order of preference for /dev/*random polling tolloyd2009-06-091-1/+1
| | | | | | /dev/urandom /dev/random /dev/srandom (OpenBSD-specific)
* 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.
* Make AutoSeeded_RNG::reseed's parameter default to 256 for compatabilitylloyd2009-04-161-1/+1
| | | | | with the version in earlier releases. Rickard Bondesson pointed out that this was a problem on the mailing list.
* Thomas Moschny passed along a request from the Fedora packagers which camelloyd2009-03-3010-26/+46
| | | | | | | | | | | | | | | 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-314-35/+14
| | | | | | | | | 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-312-2/+2
| | | | | techniques, with the one using BufferedComputation being the new subclass with the charming name Entropy_Accumulator_BufferedComputation.
* In the X9.31 PRNG, move the code that rekeys the cipher and generates V tolloyd2009-01-312-44/+53
| | | | | | | | a new member function rekey, calling it from both reseed and add_entropy. Previously add_entropy worked without this because the PRNG would reseed itself automatically if it was not at the point when randomize() was called, but once this was removed it was necessary to ensure a rekey kicked off, if appropriate, when calling add_entropy.
* Have Entropy_Accumulator dump everything into a BufferedComputation.lloyd2009-01-272-5/+3
| | | | | | | | | | | | 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-273-20/+4
| | | | randomize, or PRNG_Unseeded will be thrown.
* Check in a branch with a major redesign on how entropy polling is performed.lloyd2009-01-279-238/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-232-0/+5
| | | | 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-112-17/+20
| | | | | | 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.
* Rename timers.h to timer.hlloyd2008-11-111-1/+1
|
* 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).
* Split base.h into block_cipher.h and stream_cipher.hlloyd2008-11-083-3/+3
| | | | | | It turned out many files were including base.h merely to get other includes (like types.h, secmem.h, and exceptn.h). Those have been changed to directly include the files containing the declarations that code needs.
* Move declaration of MessageAuthenticationCode base class to mac.h (from base.h)lloyd2008-11-082-1/+2
|
* 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-063-68/+27
| | | | | 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.
* Modify AutoSeeded_RNG to use HMAC_RNG instead of Randpool, if HMAC_RNG islloyd2008-10-282-5/+20
| | | | | | | | available in the build. If neither is avilable, the constructor will throw an exception. As before, the underlying RNG will be wrapped in an X9.31 PRNG using AES-256 as the block cipher (if X9.31 is enabled in the build).
* 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).
* In ANSI_X931_RNG::reseed, only attempt to reseed the X9.31 state iflloyd2008-10-281-7/+10
| | | | the underlying PRNG's reseed was a success.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 10:50:48 +0000