Re: [PATCH] random: add random_initialized command line param
On Tue 2015-06-23 23:47:33, Stephan Mueller wrote: > Am Dienstag, 23. Juni 2015, 22:44:11 schrieb Pavel Machek: > > Hi Pavel, > > > On Mon 2015-05-18 18:25:25, Stephan Mueller wrote: > > > Make the threshold at which the output entropy pools are considered to > > > be initialized configurable via a kernel command line option. The > > > current integer value of 128 bits is a good default value. However, some > > > user groups may want to use different values. For example, the SOGIS > > > group now requires 125 bits at least (BSI, the participant at that group > > > used to require 100 bits). NIST moved from 80 bits to 112 bits starting > > > with 2014. > > > > > > It is therefore to be expected that in the future, this threshold may > > > increase for different user groups. > > > > Speaking of random and kernel parameters... should we add random= > digits> parameter to pass entropy from bootloader to the kernel? > > Everybody can see that string. How do you think that way of providing entropy > is protected? Only local users, not remote attackers. And yes, we should probably "censor" the command line for this use. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add random_initialized command line param
Am Dienstag, 23. Juni 2015, 22:44:11 schrieb Pavel Machek: Hi Pavel, > On Mon 2015-05-18 18:25:25, Stephan Mueller wrote: > > Make the threshold at which the output entropy pools are considered to > > be initialized configurable via a kernel command line option. The > > current integer value of 128 bits is a good default value. However, some > > user groups may want to use different values. For example, the SOGIS > > group now requires 125 bits at least (BSI, the participant at that group > > used to require 100 bits). NIST moved from 80 bits to 112 bits starting > > with 2014. > > > > It is therefore to be expected that in the future, this threshold may > > increase for different user groups. > > Speaking of random and kernel parameters... should we add random= digits> parameter to pass entropy from bootloader to the kernel? Everybody can see that string. How do you think that way of providing entropy is protected? > u-boot-SPL does DRAM calibration, for example, and I guess that may > provide some rather hard to guess values... > > [I initialy misread parameter below as "random_initize=" and thought > it does exactly this...] > Pavel > > > + random_initialized= [KNL] Set the threshold in bits at which the > > + Linux random number generator considers an output > > + entropy pool initialized. > > + Format: (must be >= 112 and <= size of output > > + entropy pool in bits) > > + Default: 128 > > + -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add random_initialized command line param
On Mon 2015-05-18 18:25:25, Stephan Mueller wrote: > Make the threshold at which the output entropy pools are considered to > be initialized configurable via a kernel command line option. The > current integer value of 128 bits is a good default value. However, some > user groups may want to use different values. For example, the SOGIS > group now requires 125 bits at least (BSI, the participant at that group > used to require 100 bits). NIST moved from 80 bits to 112 bits starting > with 2014. > > It is therefore to be expected that in the future, this threshold may > increase for different user groups. Speaking of random and kernel parameters... should we add random= parameter to pass entropy from bootloader to the kernel? u-boot-SPL does DRAM calibration, for example, and I guess that may provide some rather hard to guess values... [I initialy misread parameter below as "random_initize=" and thought it does exactly this...] Pavel > + random_initialized= [KNL] Set the threshold in bits at which the > + Linux random number generator considers an output > + entropy pool initialized. > + Format: (must be >= 112 and <= size of output > +entropy pool in bits) > + Default: 128 > + -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add random_initialized command line param
Am Mittwoch, 20. Mai 2015, 11:06:42 schrieb Theodore Ts'o: Hi Theodore, As a side note to this discussion, may I ask why entropy_total is used for checking against the threshold value and not entropy_count? The reason for my question is the following: until a DRNG (in the worst case, nonblocking_pool is a DRNG) is fully seeded, partial seeds may be "eaten" up by the caller. For the discussion, let us assume the worst case that there is coming in one bit of entropy at a time. In between the addition of each bit of entropy, an attacker can access the DRNG (i.e. the SHA1 output of the nonblocking_pool). When only one bit of entropy is added to the nonblocking_pool, the attack complexity would be 1 bit. When an attacker would access the nonblocking_pool after each received bit, in the worst case, the attack complexity is not 2**128 but rather 256 (i.e. 1 bit for each individual attack between the addition of one new bit of entropy). So, the total attack complexity is the sum of the individual attack complexities (i.e. the complexity added after the previous attack is performed). When using the entropy_count variable which is affected by account() (i.e. it is decreased when a reader obtains data), the threshold is only reached when truly 128 unobserved bits are collected. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add random_initialized command line param
On Mon, May 18, 2015 at 6:58 PM, Herbert Xu wrote: > Stephan Mueller wrote: >> >> I hear more and more discussions about recommendations to use AES 256 and not >> AES 128. Or perhaps other ciphers with 256-bit keys. Salsa, ChaCha and several of the Caesar candidates support those. >> These kind of recommendations will eventually also affect the entropy >> requirements for noise sources. This is my motivation for the patch: allowing >> different user groups to set the minimum bar for the nonblocking pool to >> *higher* levels (the examples for 80 to 112 bits or 100 to 125 bits shall >> just >> show that there are active revisions of entropy requirements). > > Does anyone need to raise this from 128 today? If not then this > patch is pointless. There is an RFC for ChaCha in IETF protocols https://www.rfc-editor.org/rfc/rfc7539.txt That RFC is new, issued this month, so it will probably be a while before we need to worry about it. I do think finding a way to support changing the init requirement from 128 to 256 bits will be useful at some point. However, I doubt it is urgent since few protocols need it now. On the other hand, IPsec and TLS both include AES-256, I think. When we do do it, I see no reason to support anything other than 128 and 256, and I am not sure about retaining 128. Nor do I see any reason this should be a command-line option rather than just a compile-time constant. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
