crypto.rand on OpenBSD

150 views
Skip to first unread message

Otto Moerbeek

unread,
Oct 19, 2017, 4:42:45 PM10/19/17
to golang-dev

Hi,                                                                             

                                                                                

I'm studying go and noticed that on OpenBSD (I'm an OpenBSD developer),         

crypt.rand.Reader gets its data via direct calls to the system call             

getentropy(2).                                                                  

                                                                                

That's not the best way to use getentropy(2). Programs or libraries             

are supposed to use a libc function arc4random(3) that produced secure          

random secquences. arc4random(3) is implemented using a ChaCha20                

cipher atm, and seeds itself using getrandom(2). To quote from the man          

page:                                                                           

                                                                                

     getentropy() fills a buffer with high-quality entropy, which can be used   

     as input for process-context pseudorandom generators like arc4random(3).   

                                                                                

     The maximum buffer size permitted is 256 bytes.  If buflen exceeds this,   

     an error of EIO will be indicated.                                         

                                                                                

     getentropy() is not intended for regular code; please use the              

     arc4random(3) family of functions instead.                                 

                                                                                

Since arc4random(3) is not available in the go runtime, the next best           

thing would be if go used it's own X9.31 based routine seeding itself           

by using getentropy(2).                                                         

                                                                                

Any particular reason why it was not implemented like this?                     

                                                                                

Regards,                                                                        

                                                                                

        -Otto Moerbeek                                                          

Ian Lance Taylor

unread,
Oct 19, 2017, 4:51:01 PM10/19/17
to Otto Moerbeek, golang-dev
On Thu, Oct 19, 2017 at 1:21 PM, Otto Moerbeek <otto.m...@gmail.com> wrote:


>
> I'm studying go and noticed that on OpenBSD (I'm an OpenBSD developer),
>
> crypt.rand.Reader gets its data via direct calls to the system call
>
> getentropy(2).
>
>
>
> That's not the best way to use getentropy(2). Programs or libraries
>
> are supposed to use a libc function arc4random(3) that produced secure
>
> random secquences. arc4random(3) is implemented using a ChaCha20
>
> cipher atm, and seeds itself using getrandom(2). To quote from the man
>
> page:
>
>
>
> getentropy() fills a buffer with high-quality entropy, which can be
> used
>
> as input for process-context pseudorandom generators like
> arc4random(3).
>
>
>
> The maximum buffer size permitted is 256 bytes. If buflen exceeds
> this,
>
> an error of EIO will be indicated.
>
>
>
> getentropy() is not intended for regular code; please use the
>
> arc4random(3) family of functions instead.
>
>
>
> Since arc4random(3) is not available in the go runtime, the next best
>
> thing would be if go used it's own X9.31 based routine seeding itself
>
> by using getentropy(2).
>
>
>
> Any particular reason why it was not implemented like this?


I don't claim to fully understand this issue, but this was explicitly
discussed on https://golang.org/issue/13785 .

Ian

Otto Moerbeek

unread,
Oct 20, 2017, 2:01:54 AM10/20/17
to golang-dev
Thanks,

If Matthew Dempsky is OK with the current approach, I'm happy too. 

Having a library CSPRNG that's being seeded periodically by getentropy(2)/getrandom(2) is still an idea one might consider to limit the number of syscalls.

 -Otto


 
Reply all
Reply to author
Forward
0 new messages