[Cryptography] ChaCha20 DRNG

Stephan Mueller smueller at chronox.de
Thu Aug 4 12:02:42 EDT 2016


Am Donnerstag, 4. August 2016, 15:48:30 CEST schrieb Jason Cooper:

Hi Jason,

> Hi Stephan,
> 
> On Thu, Aug 04, 2016 at 02:22:08PM +0200, Stephan Mueller wrote:
> > As part of the development of my "Linux Random Number Generator -- a new
> > approach to the Linux /dev/random" project, I implemented a DRNG based on
> > ChaCha20.
> > 
> > This DRNG is now extracted into a standalone code base and is provided at
> > [1]. The DRNG is completely standalone in the sense that it does not
> > require services from any library other than libc. This implies that it
> > implements all cryptographic aspects itself.
> > 
> > The implementation is very small with some 400 lines of code. The
> > implementation draws ideas from SP800-90A, AIS 20/31 and Peter Gutmann's
> > work:
> > 
> > * the DRNG seeds itself
> > 
> > * the DRNG reseeds itself when reaching a time-based or volume-based
> > threshold
> > 
> > * the DRNG performs a continuous reseeding using a high-resolution time
> > stamp
> > 
> > * the DRNG implements enhanced backward secrecy
> > 
> > 
> > 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.

But you are absolutely right, I should namespace them.

>     - 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;
}

>  - 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.

>  - 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.

>  - work towards baremetal
>     - replace/remove printfs (add a log() cb?)

Ok.

>     - 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.

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

>     - add seed save/restore cbs.

Let us discuss your patch :-)

>     - other items I don't recall off the top of my head


Thank you for the review.

Ciao
Stephan


More information about the cryptography mailing list