On Sun, Jun 18, 2017 at 7:55 PM, Stephan Müller wrote:
> But you bring up an interesting point: if it is true you say that it is hard
> for people to use differnent types of APIs regarding entropy and random
> numbers right (which I would concur with), and considering that
On Sun, Jun 18, 2017 at 5:46 PM, Theodore Ts'o wrote:
> You are effectively proposing that there ought to be a middle range of
> security between prandom_32, get_random_u32/get_random_u64 and
> get_random_bytes(). I think that's going to lead to all sorts of
> complexity and bugs
Am Sonntag, 18. Juni 2017, 17:46:25 CEST schrieb Theodore Ts'o:
Hi Theodore,
> > IMHO, users using the get_random_u64 or get_random_u32 are use cases that
> > do not require a fully seeded DRNG thus do not need a cryptographically
> > strong random number. Hence, I would think that the logging
On Thu, Jun 15, 2017 at 01:59:43PM +0200, Stephan Müller wrote:
> I would think that the issue regarding the logging is relevant for
> cryptographic use cases or use cases requiring strong random numbers only.
> Only those use cases should be fixed eventually to wait for a fully seeded
> DRNG.
Am Donnerstag, 15. Juni 2017, 13:03:48 CEST schrieb Michael Ellerman:
Hi Michael,
>
> Even with this patch, it's still pretty spammy (today's linux-next):
>
I would think that the issue regarding the logging is relevant for
cryptographic use cases or use cases requiring strong random numbers
Theodore Ts'o writes:
> On Tue, Jun 06, 2017 at 07:48:04PM +0200, Jason A. Donenfeld wrote:
>> This enables an important dmesg notification about when drivers have
>> used the crng without it being seeded first. Prior, these errors would
>> occur silently, and so there hasn't been
On Thu, Jun 8, 2017 at 10:19 AM, Theodore Ts'o wrote:
> At the very least we probably should do a logical "uniq" on the output
> (e.g., if we have complained about the previous callsite, don't whinge
> about it again).
That seems okay to me.
On Tue, Jun 6, 2017 at 1:48 PM, Jason A. Donenfeld wrote:
> This enables an important dmesg notification about when drivers have
> used the crng without it being seeded first. Prior, these errors would
> occur silently, and so there hasn't been a great way of diagnosing these
>
On Tue, Jun 06, 2017 at 07:48:04PM +0200, Jason A. Donenfeld wrote:
> This enables an important dmesg notification about when drivers have
> used the crng without it being seeded first. Prior, these errors would
> occur silently, and so there hasn't been a great way of diagnosing these
> types of
This enables an important dmesg notification about when drivers have
used the crng without it being seeded first. Prior, these errors would
occur silently, and so there hasn't been a great way of diagnosing these
types of bugs for obscure setups. By adding this as a config option, we
can leave it
10 matches
Mail list logo