view libtomcrypt/notes/tech0001.txt @ 1672:3a97f14c0235

Add Chacha20-Poly1305, AES128-GCM and AES256-GCM support (#93) * Add Chacha20-Poly1305 authenticated encryption * Add general AEAD approach. * Add [email protected] algo using LibTomCrypt chacha and poly1305 routines. Chacha20-Poly1305 is generally faster than AES256 on CPU w/o dedicated AES instructions, having the same key size. Compiling in will add ~5,5kB to binary size on x86-64. function old new delta chacha_crypt - 1397 +1397 _poly1305_block - 608 +608 poly1305_done - 595 +595 dropbear_chachapoly_crypt - 457 +457 .rodata 26976 27392 +416 poly1305_process - 290 +290 poly1305_init - 221 +221 chacha_setup - 218 +218 encrypt_packet 1068 1270 +202 dropbear_chachapoly_getlength - 147 +147 decrypt_packet 756 897 +141 chacha_ivctr64 - 137 +137 read_packet 543 637 +94 dropbear_chachapoly_start - 94 +94 read_kex_algos 792 880 +88 chacha_keystream - 69 +69 dropbear_mode_chachapoly - 48 +48 sshciphers 280 320 +40 dropbear_mode_none 24 48 +24 dropbear_mode_ctr 24 48 +24 dropbear_mode_cbc 24 48 +24 dropbear_chachapoly_mac - 24 +24 dropbear_chachapoly - 24 +24 gen_new_keys 848 854 +6 ------------------------------------------------------------------------------ (add/remove: 14/0 grow/shrink: 10/0 up/down: 5388/0) Total: 5388 bytes * Add AES128-GCM and AES256-GCM authenticated encryption * Add general AES-GCM mode. * Add [email protected] and [email protected] algo using LibTomCrypt gcm routines. AES-GCM is combination of AES CTR mode and GHASH, slower than AES-CTR on CPU w/o dedicated AES/GHASH instructions therefore disabled by default. Compiling in will add ~6kB to binary size on x86-64. function old new delta gcm_process - 1060 +1060 .rodata 26976 27808 +832 gcm_gf_mult - 820 +820 gcm_add_aad - 660 +660 gcm_shift_table - 512 +512 gcm_done - 471 +471 gcm_add_iv - 384 +384 gcm_init - 347 +347 dropbear_gcm_crypt - 309 +309 encrypt_packet 1068 1270 +202 decrypt_packet 756 897 +141 gcm_reset - 118 +118 read_packet 543 637 +94 read_kex_algos 792 880 +88 sshciphers 280 360 +80 gcm_mult_h - 80 +80 dropbear_gcm_start - 62 +62 dropbear_mode_gcm - 48 +48 dropbear_mode_none 24 48 +24 dropbear_mode_ctr 24 48 +24 dropbear_mode_cbc 24 48 +24 dropbear_ghash - 24 +24 dropbear_gcm_getlength - 24 +24 gen_new_keys 848 854 +6 ------------------------------------------------------------------------------ (add/remove: 14/0 grow/shrink: 10/0 up/down: 6434/0) Total: 6434 bytes
author Vladislav Grishenko <themiron@users.noreply.github.com>
date Mon, 25 May 2020 20:50:25 +0500
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.