Difference between revisions of "Talk:Random number generation"

From ArchWiki
Jump to: navigation, search
m (on the bashing of /dev/urandom: closing, old and un-related here. Securely_wipe_disk has an appropriate warning)
m (random vs urandom in this page: ops, double paste)
 
(8 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== <s>on the bashing of /dev/urandom </s>==
+
== <s>random vs urandom in this page</s> ==
{{Note|This section was moved from [[Talk:Dm-crypt_with_LUKS]].}}
 
  
I don't take an opinion on whether old overwritten data can be read.
+
Looking at the discussion under [[Talk:Dm-crypt/Device encryption#Encryption options for LUKS mode example]], and notably [http://www.2uo.de/myths-about-urandom/ Myths about /dev/urandom], I believe the warning in this page (about not using urandom for long-term cryptographic keys) should be lessened and expanded: when random is absolutely necessary, and why urandom is enough for the most use-cases, even for master keys.
 +
I think it should go beyond the three unexplained links Indigo added at the end of the sentence, but I'd like to wait for wiki maintainers' opinion, as the nuances in this page could be critical for users. <span style="color:red">— [[User:Dinghy|Dinghy]] ([[User_talk:Dinghy|Talk]])</span> 01:24, 11 December 2015 (UTC)
  
However, there is an unrelated reason to fill a LUKS partition from {{ic|/dev/urandom}} before LUKS-initializing it (and after checking for bad blocks if you wanted to do that).
+
:I'd be in favor of at least adding external references to the Warning, can you post a draft of how you'd reword it? — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:27, 12 December 2015 (UTC)
  
It makes it harder for people trying to read your disk and find out what's on it. If you filled it with zeroes, for example, then they would be able to tell which portions of the partition had been written to since you initialized it.
+
::I agree the links should be prepended with another sentence. They mainly cater for alternating opinions to let the reader make up own mind. The warning may also be softened or phrased more relative at least. A suitable reference to use in it may be [[w:RdRand#Reception]]. Yet, situation has changed in many aspects (e.g. more widespread application usage for random seeds, more virtual machines of different sorts, kernel changes at the same time) since the warning was added. Happy if someone can suggest an alternate wording for that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:23, 1 March 2017 (UTC)
  
compare gentoo docs, http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS#Filling_the_disk_with_random_data --[[User:Idupree|Idupree]] 22:45, 3 March 2010 (EST)
+
:::Ok, I've attempted to rework this with [https://wiki.archlinux.org/index.php?title=Random_number_generation&type=revision&diff=472969&oldid=432940]. For one of the references Dinghy referred to, I used "highly informative but (unfortunately) also containing fallacies" as description. Not happy with that, but this was the only way to include it because we cannot discuss it in the article. For the matter of completeness, I want to point to one of the problems I see with it: AFAIK the kernel never claimed to provide a CSPRNG (a term which is used all over in it), not before 4.8 and not later. Discussing such leads far off-track though, therefore the description - maybe someone has a better phrasing for it. Closing. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:31, 5 April 2017 (UTC)
  
:Agreed, {{ic|/dev/urandom}} should be used to clear partitions, at least as default in the examples. If anyone wants to zero the partitions instead of using random data, they are free to do so. --[[User:Montschok|Montschok]] 20:53, 11 August 2010 (EDT)
+
== <s>references for an update</s> ==
 +
Re above talk, I'd like to also add a little to the urandom section to account for kernel 4.8 changes.
 +
Leaving the references here I'd like to work in sometime soon, if noone is faster:
 +
:* [https://lkml.org/lkml/2016/7/25/43 kernel 4.8 changes], in particular [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e192be9d9a30555aae2ca1dc3aad37cba484cd4a]
 +
:* [http://www.chronox.de/lrng/doc/lrng.pdf urandom update paper] (likely a see also)
 +
:* [http://www.chronox.de/crypto-API/index.html Kernel crypto doc] see also
 +
Also, without wanting to make the article a programming reference, the more widely pushed getent() should perhaps get a further mention.  
 +
--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:23, 1 March 2017 (UTC)
  
== <s>Links with content</s> ==
+
:Done. crypto api link goes too far for this article. Closing. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:07, 5 April 2017 (UTC)
This is to provide some links which may be useful, if this page is going to be expanded.
 
 
 
Proposals to renew the linux /dev/random:  
 
http://www.phoronix.com/scan.php?page=news_item&px=MTI5NzY leading to http://lkml.indiana.edu/hypermail/linux/kernel/1302.1/00479.html
 
and an article on /dev/random robustness (current; June 2013): 
 
http://eprint.iacr.org/2013/338
 
 
 
--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:12, 25 August 2013 (UTC)
 
 
 
:Very interesting, we could add them to the See also section as a start, right? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:38, 28 August 2013 (UTC)
 
::Ok, fine. I added them. Maybe the LKML one can be put more into context sometime later. closing this. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:58, 28 August 2013 (UTC)
 

Latest revision as of 18:31, 5 April 2017

random vs urandom in this page

Looking at the discussion under Talk:Dm-crypt/Device encryption#Encryption options for LUKS mode example, and notably Myths about /dev/urandom, I believe the warning in this page (about not using urandom for long-term cryptographic keys) should be lessened and expanded: when random is absolutely necessary, and why urandom is enough for the most use-cases, even for master keys. I think it should go beyond the three unexplained links Indigo added at the end of the sentence, but I'd like to wait for wiki maintainers' opinion, as the nuances in this page could be critical for users. Dinghy (Talk) 01:24, 11 December 2015 (UTC)

I'd be in favor of at least adding external references to the Warning, can you post a draft of how you'd reword it? — Kynikos (talk) 06:27, 12 December 2015 (UTC)
I agree the links should be prepended with another sentence. They mainly cater for alternating opinions to let the reader make up own mind. The warning may also be softened or phrased more relative at least. A suitable reference to use in it may be w:RdRand#Reception. Yet, situation has changed in many aspects (e.g. more widespread application usage for random seeds, more virtual machines of different sorts, kernel changes at the same time) since the warning was added. Happy if someone can suggest an alternate wording for that. --Indigo (talk) 12:23, 1 March 2017 (UTC)
Ok, I've attempted to rework this with [1]. For one of the references Dinghy referred to, I used "highly informative but (unfortunately) also containing fallacies" as description. Not happy with that, but this was the only way to include it because we cannot discuss it in the article. For the matter of completeness, I want to point to one of the problems I see with it: AFAIK the kernel never claimed to provide a CSPRNG (a term which is used all over in it), not before 4.8 and not later. Discussing such leads far off-track though, therefore the description - maybe someone has a better phrasing for it. Closing. --Indigo (talk) 18:31, 5 April 2017 (UTC)

references for an update

Re above talk, I'd like to also add a little to the urandom section to account for kernel 4.8 changes. Leaving the references here I'd like to work in sometime soon, if noone is faster:

Also, without wanting to make the article a programming reference, the more widely pushed getent() should perhaps get a further mention. --Indigo (talk) 12:23, 1 March 2017 (UTC)

Done. crypto api link goes too far for this article. Closing. --Indigo (talk) 18:07, 5 April 2017 (UTC)