Mercurial > dropbear
view libtomcrypt/notes/tech0001.txt @ 1499:2d450c1056e3
options: Complete the transition to numeric toggles (`#if')
For the sake of review, this commit alters only the code; the affiliated
comments within the source files also need to be updated, but doing so
now would obscure the operational changes that have been made here.
* All on/off options have been switched to the numeric `#if' variant;
that is the only way to make this `default_options.h.in' thing work
in a reasonable manner.
* There is now some very minor compile-time checking of the user's
choice of options.
* NO_FAST_EXPTMOD doesn't seem to be used, so it has been removed.
* ENABLE_USER_ALGO_LIST was supposed to be renamed DROPBEAR_USER_ALGO_LIST,
and this commit completes that work.
* DROPBEAR_FUZZ seems to be a relatively new, as-yet undocumented option,
which was added by the following commit:
commit 6e0b539e9ca0b5628c6c5a3d118ad6a2e79e8039
Author: Matt Johnston <[email protected]>
Date: Tue May 23 22:29:21 2017 +0800
split out checkpubkey_line() separately
It has now been added to `sysoptions.h' and defined as `0' by default.
* The configuration option `DROPBEAR_PASSWORD_ENV' is no longer listed in
`default_options.h.in'; it is no longer meant to be set by the user, and
is instead left to be defined in `sysoptions.h' (where it was already being
defined) as merely the name of the environment variable in question:
DROPBEAR_PASSWORD
To enable or disable use of that environment variable, the user must now
toggle `DROPBEAR_USE_DROPBEAR_PASSWORD'.
* The sFTP support is now toggled by setting `DROPBEAR_SFTPSERVER', and the
path of the sFTP server program is set independently through the usual
SFTPSERVER_PATH.
author | Michael Witten <mfwitten@gmail.com> |
---|---|
date | Thu, 20 Jul 2017 19:38:26 +0000 |
parents | 1b9e69c058d2 |
children |
line wrap: on
line source
Tech Note 0001 How to Gather Entropy on Embedded Systems Tom St Denis Introduction ------------ This tech note explains a relatively simple way to gather entropy for a PRNG (Yarrow in this case) in embedded systems where there are few sources of entropy or physical sources. When trying to setup a secure random number generator a fresh source of random data (entropy) is required to ensure the deterministic state of the PRNG is not known or predetermined with respect to an attacker. At the very least the system requires one timer and one source of un-timed interrupts. by "un-timed" I mean interrupts that do not occur at regular intervals [e.g. joypad/keypad input, network packets, etc...]. First we shall begin by taking an overview of how the Yarrow PRNG works within libtomcrypt. At the heart of all PRNGs is the "prng_state" data type. This is a union of structures that hold the PRNG state for the various prngs. The first thing we require is a state... prng_state myPrng; Next we must initialize the state once to get the ball rolling if (yarrow_start(&myPrng) != CRYPT_OK) { // error should never happen! } At this point the PRNG is ready to accept fresh entropy which is added with int yarrow_add_entropy(const unsigned char *buf, unsigned long len, prng_state *prng) This function is **NOT** thread safe which will come under consideration later. To add entropy to our PRNG we must call this function with fresh data as its sampled. Lets say we have a timer counter called "uTimer" which is a 32-bit long and say a 32-bit joyPad state called "uPad". An example interrupt handler would look like void joypad_interrupt(...) { unsigned char buf[8]; STORE32L(uTimer, buf); STORE32L(uPad, buf+4) if (yarrow_add_entropy(buf, 8, &myPrng) != CRYPT_OK) { // this should never occur either unless you didn't call yarrow_start } // handle interrupt } In this snippet the timer count and state of the joypad are added together into the entropy pool. The timer is important because with respect to the joypad it is a good source of entropy (on its own its not). For example, the probability of the user pushing the up arrow is fairly high, but at a specific time is not. This method doesn't gather alot of entropy and has to be used to for quite a while. One way to speed it up is to tap multiple sources. If you have a network adapter and other sources of events (keyboard, mouse, etc...) trapping their data is ideal as well. Its important to gather the timer along with the event data. As mentioned the "yarrow_add_entropy()" function is not thread safe. If your system allows interrupt handlers to be interrupted themselves then you could have trouble. One simple way is to detect when an interrupt is in progress and simply not add entropy during the call (jump over the yarrow_add_entropy() call) Once you feel that there has been enough entropy added to the pool then within a single thread you can call int yarrow_ready(prng_state *prng) Now the PRNG is ready to read via the unsigned long yarrow_read(unsigned char *buf, unsigned long len, prng_state *prng) It is a very good idea that once you call the yarrow_ready() function that you stop harvesting entropy in your interrupt functions. This will free up alot of CPU time. Also one more final note. The yarrow_read() function is not thread safe either. This means if you have multiple threads or processes that read from it you will have to add your own semaphores around calls to it.