view libtomcrypt/notes/tech0001.txt @ 1306:34e6127ef02e

merge fixes from PuTTY import.c toint() from misc.c (revids are from hggit conversion) changeset: 4620:60a336a6c85c user: Simon Tatham <[email protected]> date: Thu Feb 25 20:26:33 2016 +0000 files: import.c description: Fix potential segfaults in reading OpenSSH's ASN.1 key format. The length coming back from ber_read_id_len might have overflowed, so treat it as potentially negative. Also, while I'm here, accumulate it inside ber_read_id_len as an unsigned, so as to avoid undefined behaviour on integer overflow, and toint() it before return. Thanks to Hanno Böck for spotting this, with the aid of AFL. (cherry picked from commit 5b7833cd474a24ec098654dcba8cb9509f3bf2c1) Conflicts: import.c (cherry-picker's note: resolving the conflict involved removing an entire section of the original commit which fixed ECDSA code not present on this branch) changeset: 4619:9c6c638d98d8 user: Simon Tatham <[email protected]> date: Sun Jul 14 10:45:54 2013 +0000 files: import.c ssh.c sshdss.c sshpubk.c sshrsa.c description: Tighten up a lot of casts from unsigned to int which are read by one of the GET_32BIT macros and then used as length fields. Missing bounds checks against zero have been added, and also I've introduced a helper function toint() which casts from unsigned to int in such a way as to avoid C undefined behaviour, since I'm not sure I trust compilers any more to do the obviously sensible thing. [originally from svn r9918] changeset: 4618:3957829f24d3 user: Simon Tatham <[email protected]> date: Mon Jul 08 22:36:04 2013 +0000 files: import.c sshdss.c sshrsa.c description: Add an assortment of extra safety checks. [originally from svn r9896] changeset: 4617:2cddee0bce12 user: Jacob Nevins <[email protected]> date: Wed Dec 07 00:24:45 2005 +0000 files: import.c description: Institutional failure to memset() things pointed at rather than pointers. Things should now be zeroed and memory not leaked. Spotted by Brant Thomsen. [originally from svn r6476] changeset: 4616:24ac78a9c71d user: Simon Tatham <[email protected]> date: Wed Feb 11 13:58:27 2004 +0000 files: import.c description: Jacob's last-minute testing found a couple of trivial bugs in import.c, and my attempts to reproduce them in cmdgen found another one there :-) [originally from svn r3847] changeset: 4615:088d39a73db0 user: Simon Tatham <[email protected]> date: Thu Jan 22 18:52:49 2004 +0000 files: import.c description: Placate some gcc warnings. [originally from svn r3761] changeset: 4614:e4288bad4d93 parent: 1758:108b8924593d user: Simon Tatham <[email protected]> date: Fri Oct 03 21:21:23 2003 +0000 files: import.c description: My ASN.1 decoder returned wrong IDs for anything above 0x1E! Good job it's never had to yet. Ahem. [originally from svn r3479]
author Matt Johnston <matt@ucc.asn.au>
date Tue, 12 Jul 2016 23:00:01 +0800
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.