Am Samstag, 17. Juni 2017, 05:45:57 CEST schrieb Lee Duncan:
Hi Lee,
> In your testing, how long might a process have to wait? Are we talking
> seconds? Longer? What about timeouts?
>
In current kernels (starting with 4.8) this timeout should clear within a few
seconds after boot.
In older
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.
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
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 Tue, Jun 06, 2017 at 03:44:17PM +0200, Corentin Labbe wrote:
> The crypto engine could actually only enqueue hash and ablkcipher request.
> This patch permit it to enqueue skcipher requets by adding all necessary
> functions.
> The only problem is that ablkcipher and skcipher id are the same,
Hi Ard,
On Fri, Jun 16, 2017 at 01:17:43PM +0200, Ard Biesheuvel wrote:
> The generic AES driver uses 16 lookup tables of 1 KB each, and has
> encryption and decryption routines that are fully unrolled. Given how
> the dependencies between this code and other drivers are declared in
> Kconfig
On Fri, May 12, 2017 at 01:49:52PM +0530, PrasannaKumar Muralidharan wrote:
>
> I leave it to Herbert to decide whether to accept this patch in
> current form or not.
I think the correct fix would be for the TPM subsystem to signal that
it is ready and then register the tpm-rng device.
Thanks,
On Sun, Jun 18, 2017 at 9:12 PM, Herbert Xu wrote:
> On Fri, May 12, 2017 at 01:49:52PM +0530, PrasannaKumar Muralidharan wrote:
> > I leave it to Herbert to decide whether to accept this patch in
> > current form or not.
>
> I think the correct fix would be for the TPM subsystem to signal that
>
On Mon, Jun 12, 2017 at 11:56:54PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang
>
> Document the bindings used by MediaTek MT7622 SoC hardware random number
> generator.
>
> Signed-off-by: Sean Wang
> ---
>
On Tue, Jun 13, 2017 at 07:49:04PM -0700, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> The Devicetree Specification has superseded the ePAPR as the
> base specification for bindings. Update files in Documentation
> to reference the new document.
>
> Some files
11 matches
Mail list logo