Eric Biggers wrote:
> (I also still need to convince myself that there aren't any race conditions
> in key type unregistering. It's a little weird how it changes the key type
> to the ".dead" key type, rather than pinning the key type in memory while
> it's still used.)
Keys are converted to th
Geert Uytterhoeven wrote:
> Now this has hit mainline, the "BIG_KEYS" Kconfig symbol appeared on my
> radar. Is there any reason this cannot be tristate?
It was tristate, but it got converted to bool:
commit 2eaf6b5dcafda2b8c22930eff7f48a364fce1741
KEYS: Make BIG_KEYS boolean
a
On Mon, Oct 02, 2017 at 09:14:36AM +0200, Geert Uytterhoeven wrote:
> Now this has hit mainline, the "BIG_KEYS" Kconfig symbol appeared on my
> radar. Is there any reason this cannot be tristate?
>
> The help text says:
>
> This option provides support for holding large keys within the kernel
Hi Jason,
On Sat, Sep 16, 2017 at 3:00 PM, Jason A. Donenfeld wrote:
> This started out as just replacing the use of crypto/rng with
> get_random_bytes_wait, so that we wouldn't use bad randomness at boot time.
> But, upon looking further, it appears that there were even deeper
> underlying crypt
On Tue, Sep 19, 2017 at 03:04:29PM -0400, Sandy Harris wrote:
> On the other hand, I do not see why the driver should not
> use a FIPS-compliant PRNG where it can. This would make
> things easier for anyone who does seek certification. One
> of the big distro vendors? A gov't department or contract
On Tue, Sep 19, 2017 at 9:04 PM, Sandy Harris wrote:
> On the other hand, I do not see why the driver should not
>From my perspective, this discussion is over. I'll be carrying out
David's requested patchset changes and submitting it. If you'd like
different cryptography, you'll have to find some
On Tue, Sep 19, 2017 at 9:39 AM, Theodore Ts'o wrote:
> On Mon, Sep 18, 2017 at 01:24:18PM +0200, Jason A. Donenfeld wrote:
>> Good luck with getting approval... While Ted and I have our
>> differences like any two kernel developers, I really tend agree with
>> him in his attitude about this FIPS
On Mon, Sep 18, 2017 at 01:24:18PM +0200, Jason A. Donenfeld wrote:
> Good luck with getting approval... While Ted and I have our
> differences like any two kernel developers, I really tend agree with
> him in his attitude about this FIPS silliness. It's unlikely you're
> going to be able to shovel
Hello Stephan,
I realize you have your Linux RNG project, which is a very worthwhile
goal that I support you in. I hope you're eventually successful, and I
apologize for not being more available in the last 2.5 months to chime
in on that patchset thread you posted.
However, your message to this t
Am Montag, 18. September 2017, 11:04:55 CEST schrieb Greg KH:
Hi Greg,
> On Mon, Sep 18, 2017 at 10:49:56AM +0200, Stephan Mueller wrote:
> > Am Samstag, 16. September 2017, 15:00:34 CEST schrieb Jason A. Donenfeld:
> >
> > Hi Jason,
> >
> > > This started out as just replacing the use of crypt
On Mon, Sep 18, 2017 at 10:49:56AM +0200, Stephan Mueller wrote:
> Am Samstag, 16. September 2017, 15:00:34 CEST schrieb Jason A. Donenfeld:
>
> Hi Jason,
>
> > This started out as just replacing the use of crypto/rng with
> > get_random_bytes_wait,
>
> This change is a challenge. The use of th
Am Samstag, 16. September 2017, 15:00:34 CEST schrieb Jason A. Donenfeld:
Hi Jason,
> This started out as just replacing the use of crypto/rng with
> get_random_bytes_wait,
This change is a challenge. The use of the kernel crypto API's DRNG has been
made to allow FIPS 140-2 compliance. Otherwi
This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot time.
But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little
13 matches
Mail list logo
