guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sufficiently safe random information for security-critical Guile app


From: Josh Datko
Subject: Re: Sufficiently safe random information for security-critical Guile applications
Date: Fri, 26 Aug 2016 15:54:30 -0600

On Fri, 2016-08-26 at 14:59 -0500, Christopher Allan Webber wrote:
> Hello!  So, as some of you know, I'm working on a federation
> implementation in Guile.  This needs a few things:
> 
>  - Random tokens which won't collide, for various purposes

There's a function in libgcrypt, gcry_create_nonce. Perhaps this would
provide better performance in this use-case. From the libgcrypt 1.6.4
manual:

void gcry_create_nonce (unsigned char *buffer, size t length)

Fill buffer with length unpredictable bytes. This is commonly called a
nonce and may also be used for initialization vectors and padding. This
is an extra function nearly independent of the other random function
for 3 reasons: It better protects the regular random generator’s
internal state, provides better performance and does not drain the
precious entropy pool


>  - The ability to generate a solid random key, which is used for...

Well, besides this unfortunate recent bug/cve (http://formal.iti.kit.ed
u/~klebanov/pubs/libgcrypt-cve-2016-6313.pdf), I would take
cryptographic PRNG over a non-one, with no offense to the guile
developers.

>  - The ability to generate an HMAC (for signed cooke based sessions)

HMAC is deterministic, so once you have your key generated, there is no
random input into HMAC (besides the key of course).

> 
> So!  Does someone much better informed than I am have any insights?
> :)
> 

Seeding one RNG (/dev/random) from another (libgcrypt) doesn't sit well
with me. The problem you need to seed a PRNG from ideally, real random.
How did you generate *that* random? Well, you quickly have a Rube
Goldberg machine.

At the application level, perhaps the best you can do is hope that the
sys admin of that machine has probably seeding /dev/random. Which, is
probably naive, but I'm not sure there is a good solution at your
layer.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]