Re: [PATCH v5 0/7] /dev/random - a new approach

On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller wrote: >> Personally, I don't really use /dev/random, nor would I recommend it >> for most application programmers. At this point, getrandom(2) really >> is the preferred interface unless you have some very specialized >>

Re: [PATCH v5 0/7] /dev/random - a new approach

On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller wrote: >> Personally, I don't really use /dev/random, nor would I recommend it >> for most application programmers. At this point, getrandom(2) really >> is the preferred interface unless you have some very specialized >> needs. > I fully agree.

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Tue, May 3, 2016 at 4:48 PM, <ty...@mit.edu> wrote: > On Tue, May 03, 2016 at 03:57:15PM +0200, Nikos Mavrogiannopoulos wrote: >> I believe their main concern is that they want to protect applications >> which do not check error codes of system calls, when running on a

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Tue, May 3, 2016 at 4:48 PM, wrote: > On Tue, May 03, 2016 at 03:57:15PM +0200, Nikos Mavrogiannopoulos wrote: >> I believe their main concern is that they want to protect applications >> which do not check error codes of system calls, when running on a >> kernel w

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Tue, Apr 26, 2016 at 3:11 AM, Theodore Ts'o <ty...@mit.edu> wrote: > On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote: >> That's far from a solution and I wouldn't recommend to anyone doing >> that. We cannot expect each and every program to do glibc'

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Tue, Apr 26, 2016 at 3:11 AM, Theodore Ts'o wrote: > On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote: >> That's far from a solution and I wouldn't recommend to anyone doing >> that. We cannot expect each and every program to do glibc's job. The >>

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Mon, Apr 25, 2016 at 10:02 AM, Stephan Mueller wrote: >> > One more item to consider: If you do not want to change to use >> > getrandom(2), the LRNG provides you with another means. >> The main problem is not about willing to switch to getrandom() or not, >> but finding

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Mon, Apr 25, 2016 at 10:02 AM, Stephan Mueller wrote: >> > One more item to consider: If you do not want to change to use >> > getrandom(2), the LRNG provides you with another means. >> The main problem is not about willing to switch to getrandom() or not, >> but finding any system where

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Thu, Apr 21, 2016 at 5:16 PM, Stephan Mueller wrote: >> > ... DRBG is “minimally” seeded with 112^6 bits of entropy. >> > This is commonly achieved even before user space is initiated. >> >> Unfortunately one of the issues of the /dev/urandom interface is the >> fact that

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Thu, Apr 21, 2016 at 5:16 PM, Stephan Mueller wrote: >> > ... DRBG is “minimally” seeded with 112^6 bits of entropy. >> > This is commonly achieved even before user space is initiated. >> >> Unfortunately one of the issues of the /dev/urandom interface is the >> fact that it may start

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Thu, Apr 21, 2016 at 11:11 AM, Stephan Mueller wrote: > Hi Herbert, Ted, > > The venerable Linux /dev/random served users of cryptographic mechanisms well > for a long time. Its behavior is well understood to deliver entropic data. In > the last years, however, the Linux

Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Thu, Apr 21, 2016 at 11:11 AM, Stephan Mueller wrote: > Hi Herbert, Ted, > > The venerable Linux /dev/random served users of cryptographic mechanisms well > for a long time. Its behavior is well understood to deliver entropic data. In > the last years, however, the Linux /dev/random showed

Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption

On Thu, Apr 14, 2016 at 12:46 AM, Tadeusz Struk wrote: > Hi Fridolin, > On 04/12/2016 04:13 AM, Fridolin Pokorny wrote: >> we were experimenting with this. We have a prove of concept of a kernel >> TLS type socket, so called AF_KTLS, which is based on Dave Watson's >>

Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption

On Thu, Apr 14, 2016 at 12:46 AM, Tadeusz Struk wrote: > Hi Fridolin, > On 04/12/2016 04:13 AM, Fridolin Pokorny wrote: >> we were experimenting with this. We have a prove of concept of a kernel >> TLS type socket, so called AF_KTLS, which is based on Dave Watson's >> RFC5288 patch. It handles