[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