On Tue, Jun 06, 2017 at 05:56:20AM +0200, Jason A. Donenfeld wrote:
> Hey Ted,
>
> On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote:
> > Note that crypto_rng_reset() is called by big_key_init() in
> > security/keys/big_key.c as a late_initcall(). So if we are on a
> > system where the crng do
On Wed, 2017-06-07 at 18:26 +0100, Mark Rutland wrote:
> On Wed, Jun 07, 2017 at 01:00:25PM -0400, Daniel Micay wrote:
> > > On the better bootloaders, an initramfs segment can be loaded
> > > independently (and you can have as many as required), which makes
> > > an
> > > early_initramfs a more pa
On Wed, Jun 07, 2017 at 07:00:17AM +0200, Stephan Müller wrote:
> > On that same idea, one could add an early_initramfs handler for entropy
> > data.
>
> Any data that comes from outside during the boot process, be it some NVRAM
> location, the /var/lib...seed file for /dev/random or other approa
On Tue, Jun 06, 2017 at 01:03:19PM -0400, Theodore Ts'o wrote:
> The other approach is to find a way to have initialized "seed" entropy
> which we can count on at every boot. The problem is that this is very
> much dependent on how the bootloader works. It's easy to say "store
> it in the kernel"
On Wed, Jun 07, 2017 at 01:00:25PM -0400, Daniel Micay wrote:
> > On the better bootloaders, an initramfs segment can be loaded
> > independently (and you can have as many as required), which makes an
> > early_initramfs a more palatable vector to inject large amounts of
> > entropy into the next b
> On the better bootloaders, an initramfs segment can be loaded
> independently (and you can have as many as required), which makes an
> early_initramfs a more palatable vector to inject large amounts of
> entropy into the next boot than, say, modifying the kernel image
> directly at every boot/shu
On Wed, 07 Jun 2017, Stephan Müller wrote:
> Am Mittwoch, 7. Juni 2017, 00:19:10 CEST schrieb Henrique de Moraes Holschuh:
> > On that same idea, one could add an early_initramfs handler for entropy
> > data.
>
> Any data that comes from outside during the boot process, be it some NVRAM
> locatio
Am Mittwoch, 7. Juni 2017, 00:19:10 CEST schrieb Henrique de Moraes Holschuh:
Hi Henrique,
> On that same idea, one could add an early_initramfs handler for entropy
> data.
Any data that comes from outside during the boot process, be it some NVRAM
location, the /var/lib...seed file for /dev/ran
On Tue, Jun 06, 2017 at 07:19:10PM -0300, Henrique de Moraes Holschuh wrote:
> On that same idea, one could add an early_initramfs handler for entropy
> data.
>
> One could also ensure the kernel command line is used to feed some
> entropy for the CRNG init (for all I know, this is already being d
On Tue, 06 Jun 2017, Theodore Ts'o wrote:
> It might be possible, for example, to store a cryptographic key in a
> UEFI boot-services variable, where the key becomes inaccessible after
> the boot-time services terminate. But you also need either a reliable
> time-of-day clock, or a reliable counte
On Tue, Jun 6, 2017 at 7:57 PM, Stephan Müller wrote:
> Finally, I am very surprised that I get hardly any answers on patches to
> random.c let alone that any changes to random.c will be applied at all.
FWIW, this is my biggest concern too. You seem willing to work on this
difficult problem. I'm
Am Dienstag, 6. Juni 2017, 19:03:19 CEST schrieb Theodore Ts'o:
Hi Theodore,
> On Tue, Jun 06, 2017 at 02:34:43PM +0200, Jason A. Donenfeld wrote:
> > Yes, I agree whole-heartedly. A lot of people have proposals for
> > fixing the direct idea of entropy gathering, but for whatever reason,
> > Te
On Tue, Jun 6, 2017 at 7:26 PM, Eric Biggers wrote:
> I agree that the use of ECB mode in big_key is broken, and thanks for trying
> to
> fix it! I think using GCM is good, but please leave a very conspicuous
> comment
> where the nonce is being set to 0, noting that it's safe only because a un
On Tue, Jun 6, 2017 at 7:03 PM, Theodore Ts'o wrote:
> So it's not clear what you mean by Stephan's work.
I just meant that there's a guy out there who seems really motivated
to work on this stuff in detail, but hasn't seen too much love, AFAIK.
I'm sure there's an interesting technical discussio
Hi Jason,
On Tue, Jun 06, 2017 at 05:23:04PM +0200, Jason A. Donenfeld wrote:
> Hey again Eric,
>
> One thing led to another and I wound up just rewriting all the crypto
> in big_keys.c. I'll include this for v4:
>
> https://git.zx2c4.com/linux-dev/commit/?h=jd/rng-blocker&id=886ff283b9808aecb14
On Tue, Jun 06, 2017 at 02:34:43PM +0200, Jason A. Donenfeld wrote:
>
> Yes, I agree whole-heartedly. A lot of people have proposals for
> fixing the direct idea of entropy gathering, but for whatever reason,
> Ted hasn't merged stuff. I think Stephan (CCd) rewrote big critical
> sections of the
Hey again Eric,
One thing led to another and I wound up just rewriting all the crypto
in big_keys.c. I'll include this for v4:
https://git.zx2c4.com/linux-dev/commit/?h=jd/rng-blocker&id=886ff283b9808aecb14aa8e397da8496a9635aed
Not only was the use of crypto/rng inappropriate, but the decision t
Hi Eric,
On Tue, Jun 6, 2017 at 6:44 AM, Eric Biggers wrote:
> I don't think big_key even needs randomness at init time. The 'big_key_rng'
> could just be removed and big_key_gen_enckey() changed to call
> get_random_bytes(). (Or get_random_bytes_wait(), I guess; it's only reachable
> via the k
On Tue, Jun 06, 2017 at 05:56:20AM +0200, Jason A. Donenfeld wrote:
> Hey Ted,
>
> On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote:
> > Note that crypto_rng_reset() is called by big_key_init() in
> > security/keys/big_key.c as a late_initcall(). So if we are on a
> > system where the crng do
Hey Ted,
On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o wrote:
> Note that crypto_rng_reset() is called by big_key_init() in
> security/keys/big_key.c as a late_initcall(). So if we are on a
> system where the crng doesn't get initialized until during the system
> boot scripts, and big_key is com
On Tue, Jun 06, 2017 at 02:50:59AM +0200, Jason A. Donenfeld wrote:
> Otherwise, we might be seeding the RNG using bad randomness, which is
> dangerous.
>
> Cc: Herbert Xu
> Signed-off-by: Jason A. Donenfeld
> ---
> crypto/rng.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
>
Otherwise, we might be seeding the RNG using bad randomness, which is
dangerous.
Cc: Herbert Xu
Signed-off-by: Jason A. Donenfeld
---
crypto/rng.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/crypto/rng.c b/crypto/rng.c
index f46dac5288b9..e042437e64b4 100644
--- a/
22 matches
Mail list logo
