4 ms·

In Common Lisp: (ql:quickload :secure-random) (secure-random:number 100) => 73 (secure-random:bytes 20 secure-random:generator) => <a simple arra

In Common Lisp: (ql:quickload :secure-random) (secure-random:number 100) => 73 (secure-random:bytes 20 secure-random:*generator*) => <a simple array with 20 random bytes> (This library requires OpenSSL)

junke 10y ago
Or without OpenSSL (ql:quickload :isaac) ;; FIRST TIME (one of both) ;; using (random), which on sane implementations should rely on /dev/urandom (defvar *isaac* (isaac:init-common-lisp-random-seed)) ;; using /dev/urandom directly (defvar *isaac* (isaac:init-kernel-seed)) ;; Generate bits (isaac:rand-bits *isaac* 30) ISAAC is supposed to be secure, but I don't know enough about cryptography to judge it.
- avodonosov 10y ago
  The main reason to use OpenSSL in secure-random is to get a seed - not all platforms have /dev/[u]ramdon. OpenSSL has code to initialize a seed from platform-dependent APIs
  - CiPHPerCoder 10y ago
    We can't condone any solution that depends on userspace PRNGs like OpenSSL instead of the kernel's CSPRNG. There are probably worse examples of userspace PRNGs that attempt to be cryptographically secure than what OpenSSL provides, but we wrote this to encourage good habits. Reliance on OpenSSL's PRNG is definitely not a good habit to get into. The "General Requirements for Inclusion" section is our basic evaluation criteria. Cross-platform APIs that wrap the operating system's CSPRNG aren't that difficult. See https://github.com/cryptosphere/sysrandom/blob/master/ext/sysrandom/randombytes_sysrandom.c https://github.com/cryptosphere/sysrandom/blob/master/ext/sy...
    - avodonosov 10y ago
      Hm, why userspace PRNGs are bad? Does code executed in kernel mode become better automatically? If OpenSSL has bad RNG, then a lot of SSL traffic is in danger... Also, do you think Java's SecureRandom is not a user space implementation? I guess it only uses /dev/[u]random for seed.
      - CiPHPerCoder 10y ago
        > Hm, why userspace PRNGs are bad? Does code executed in kernel mode become better automatically? At the beginning of the blog post there are three links. adequately -> http://www.2uo.de/myths-about-urandom/ covered -> http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ elsewhere -> https://blog.cr.yp.to/20140205-entropy.html I highly recommend reading all three. They answer your question in painstaking detail. > Also, do you think Java's SecureRandom is not a user space implementation? I guess it only uses /dev/[u]random for seed. In Java 8, it just reads from urandom. The relevant section has a cautionary note: https://paragonie.com/blog/2016/05/how-generate-secure-random-numbers-in-various-programming-languages#java-csprng https://paragonie.com/blog/2016/05/how-generate-secure-rando...
tptacek 10y ago
A big part of the point of this blog post is avoiding the OpenSSL userland CSPRNG, which has not proven to be consistently safe. Far better would be the snippet of Common Lisp that reads random from getrandom(), and then /dev/urandom.
- zeveb 10y ago
  > Far better would be the snippet of Common Lisp that reads random from getrandom(), and then /dev/urandom. Yup. Here's an example of the latter (I don't have getrandom(2) on my machine): (defun random-bytes (len) (declare (type (integer 1) len)) (with-open-file (rand "/dev/urandom" :element-type 'unsigned-byte) (let ((buf (make-array len :element-type 'unsigned-byte))) (read-sequence buf rand) buf))) N.b.: I dashed this off quickly. Do not rely on it for security-sensitive code. Do not bet your life on it.
wtbob 10y ago
Since the article doesn't want a userspace CSPRNG (which is probably a good idea, even though the Linux PRNG design is embarrassingly bad), better to just read from /dev/urandom or make the appropriate syscall.
- CiPHPerCoder 10y ago
  In balance, Linux 4.8 will bring some much-needed improvements to Linux's urandom implementation. But they still maintain a "meaningful" distinction between random and urandom, which is the most frustrating design smell.
  - zeveb 10y ago
    And to think, if Ted Ts'o had understood PRNGs at the time, we could have had a better PRNG a dozen years ago: https://lwn.net/Articles/103653/ https://lwn.net/Articles/103653/ It's so sad.

In Common Lisp: (ql:quickload :secure-random) (secure-random:number 100) => 73 (secure-random:bytes 20 secure-random:*generator*) => <a simple arra

junke 10y ago

Or without OpenSSL (ql:quickload :isaac) ;; FIRST TIME (one of both) ;; using (random), which on sane implementations should rely on /dev/urandom (defvar *isaac* (isaac:init-common-lisp-random-seed)) ;; using /dev/urandom directly (defvar *isaac* (isaac:init-kernel-seed)) ;; Generate bits (isaac:rand-bits *isaac* 30) ISAAC is supposed to be secure, but I don't know enough about cryptography to judge it.

avodonosov 10y ago
The main reason to use OpenSSL in secure-random is to get a seed - not all platforms have /dev/[u]ramdon. OpenSSL has code to initialize a seed from platform-dependent APIs
- CiPHPerCoder 10y ago
  We can't condone any solution that depends on userspace PRNGs like OpenSSL instead of the kernel's CSPRNG. There are probably worse examples of userspace PRNGs that attempt to be cryptographically secure than what OpenSSL provides, but we wrote this to encourage good habits. Reliance on OpenSSL's PRNG is definitely not a good habit to get into. The "General Requirements for Inclusion" section is our basic evaluation criteria. Cross-platform APIs that wrap the operating system's CSPRNG aren't that difficult. See https://github.com/cryptosphere/sysrandom/blob/master/ext/sysrandom/randombytes_sysrandom.c https://github.com/cryptosphere/sysrandom/blob/master/ext/sy...
  - avodonosov 10y ago
    Hm, why userspace PRNGs are bad? Does code executed in kernel mode become better automatically? If OpenSSL has bad RNG, then a lot of SSL traffic is in danger... Also, do you think Java's SecureRandom is not a user space implementation? I guess it only uses /dev/[u]random for seed.
    - CiPHPerCoder 10y ago
      > Hm, why userspace PRNGs are bad? Does code executed in kernel mode become better automatically? At the beginning of the blog post there are three links. adequately -> http://www.2uo.de/myths-about-urandom/ covered -> http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ elsewhere -> https://blog.cr.yp.to/20140205-entropy.html I highly recommend reading all three. They answer your question in painstaking detail. > Also, do you think Java's SecureRandom is not a user space implementation? I guess it only uses /dev/[u]random for seed. In Java 8, it just reads from urandom. The relevant section has a cautionary note: https://paragonie.com/blog/2016/05/how-generate-secure-random-numbers-in-various-programming-languages#java-csprng https://paragonie.com/blog/2016/05/how-generate-secure-rando...

tptacek 10y ago

A big part of the point of this blog post is avoiding the OpenSSL userland CSPRNG, which has not proven to be consistently safe. Far better would be the snippet of Common Lisp that reads random from getrandom(), and then /dev/urandom.

zeveb 10y ago
> Far better would be the snippet of Common Lisp that reads random from getrandom(), and then /dev/urandom. Yup. Here's an example of the latter (I don't have getrandom(2) on my machine): (defun random-bytes (len) (declare (type (integer 1) len)) (with-open-file (rand "/dev/urandom" :element-type 'unsigned-byte) (let ((buf (make-array len :element-type 'unsigned-byte))) (read-sequence buf rand) buf))) N.b.: I dashed this off quickly. Do not rely on it for security-sensitive code. Do not bet your life on it.

wtbob 10y ago

Since the article doesn't want a userspace CSPRNG (which is probably a good idea, even though the Linux PRNG design is embarrassingly bad), better to just read from /dev/urandom or make the appropriate syscall.

CiPHPerCoder 10y ago
In balance, Linux 4.8 will bring some much-needed improvements to Linux's urandom implementation. But they still maintain a "meaningful" distinction between random and urandom, which is the most frustrating design smell.
- zeveb 10y ago
  And to think, if Ted Ts'o had understood PRNGs at the time, we could have had a better PRNG a dozen years ago: https://lwn.net/Articles/103653/ https://lwn.net/Articles/103653/ It's so sad.