[Cryptography] ChaCha20 DRNG

[Jason Cooper]

Hi Stephan,

On Thu, Aug 04, 2016 at 06:02:42PM +0200, Stephan Mueller wrote:
> Am Donnerstag, 4. August 2016, 15:48:30 CEST schrieb Jason Cooper:
> > On Thu, Aug 04, 2016 at 02:22:08PM +0200, Stephan Mueller wrote:
...
> > > A complete documentation, including its API is given at [1].
> > > 
> > > [1] http://www.chronox.de/chacha20_drng.html
> > 
> > I took a quick look.  Small, concise, clean. :)  If you don't mind, I'd
> > like to send some patches for you to review.  I have a couple of things
> > in mind:
> 
> I am all for it. I would be waiting for your patches. The only think I would 
> like to add is the version functions as discussed below.
> > 
> >  - namespace the version number macros, or use signed git tags [1]
> 
> I am using signed git tags. But the tag numbers are derived from the macros. 
> That is how I commonly maintain version numbers to allow compile and runtime 
> access to such version information. I do that for a long time in my libkcapi 
> already.

Sure, I'll break out that one for comment and give an explanation for why I
like it.

> >     - add version number call to the API
> 
> Right, I should copy that code from my libkcapi library. I have those 
> functions:
> 
> void kcapi_versionstring(char *buf, uint32_t buflen)
> {
>         snprintf(buf, buflen, "libkcapi %d.%d.%d", MAJVERSION, MINVERSION,
>                  PATCHLEVEL);
> }
> 
> uint32_t kcapi_version(void)
> {
>         uint32_t version = 0;
> 
>         version =  MAJVERSION * 1000000;
>         version += MINVERSION * 10000;
>         version += PATCHLEVEL * 100;
> 
>         return version;
> }

Yes, this is better, then you can remove the macros from the public API.

> >  - split the different seed sources out to separate files
> 
> Ok, but I thought it is much easier to integrate one file into other code. 
> But if you think that is the way to go, I will make it so.

Well, I completely agree with making it easy to use the code.  But I'd
also like to make other configurations doable.  A good example is
SQLite.  It's repo is multi-file, with the ability to merge it into one
file for those that chose to do so.  Also, shared and static libs work
too.

> >  - Allow other chacha20 implementations (e.g. libsodium)
> 
> Sure, but my plan was to have a full standalone implementation :-)
> 
> If you have a patch, let us discuss that.

Sure.  On small systems, there's no need to waste space by having a
chacha20 implementation here as well as in another lib.  So we can make
the default to use INTERNAL_CHACHA20.  Easy for the common case,
configurable for others.

> >     - tolerate no internal seed sources / set a cb
> 
> Well, that is an interesting point: the internal seed sources are more and 
> more en vogue, see SP800-90A for example. The caller should simply not think 
> about that topic.

Agreed.

> The code structure however is such, that you can easily add a seed source at 
> compile time (just add 3 function calls). Thus, I am not in favor of a 
> runtime-setable seed source

We agree.  I'm thinking of baremetal/zephyr/rtos.  I'd like to make it
possible to build in your own for your HW.

> >     - add seed save/restore cbs.
> 
> Let us discuss your patch :-)

It's in the "user shouldn't have to think too much" vein.  Set the
callbacks, and the lib occasionally saves a seed to disk for reading
after reboot.  Similar to /etc/init.d/urandom in Linux userspace.

Understanding that it takes a while to gather sufficient entropy on
embedded systems (with or without Linux), A tapering off series of
writes would be very advantageous, modulo flash wear.  Especially on
systems where the shutdown sequence amounts to power being removed.


thx,

Jason.