User talk:Synchronicity

Random edits

Hi, I have a couple remarks regarding your updates re /dev/random:

• Special:diff/766198: No problem with the removal itself, but lease use Template:Remove in the future and wait a little, prior to removing entire subsections. Aside from the reason, the template can also be used to to list references, links and whatever is useful for someone else to perform the removal, if you don't do it yourself.
• Regarding Special:diff/766208: Have a look at ArchWiki:Contributing#The 3 fundamental rules and respect them in the future!

Ok? Frankly, I was tempted to undo your RNG edit purely on that basis, but instead took more time to read over it than I had planned for the wiki today. It's good quality, but I'm still contemplating if there is info lost given the general type of the article. Perhaps, the Mark Twain quote ;), or the warning that /dev/urandom is still not recommended for long-term cryptographic keys. What do you think about the latter (considering a user may generate the key in a virtual system, or whatever circumstances)?

--Indigo (talk) 23:06, 5 February 2023 (UTC)

Thanks for the feedback. Sorry for not splitting up my edit and announcing it on the talk page. There was very little information in the section previously that was still correct, though, so I think a rewrite was definitely needed! Keep in mind that there's a lot of outdated information, and plain misinformation, about the Linux RNG floating around in general, not just on the Arch Wiki, so it's probably inevitable that any effort to clean things up is going to be controversial to some extent.

I'm planning a few more updates to the page to make it clearer what is recommended in different situations, which should address some of your concerns.

Regarding the paragraph with the Mark Twain quote, it didn't make any sense to me. If you don't trust a system, you can't trust it with your secret key either, even if it was generated on another system. So I don't see what value that paragraph contributed to the article.

Regarding /dev/urandom "still not being recommended for long-term cryptographic keys", that isn't necessarily true. First, /dev/urandom and /dev/random are more similar than ever before, and on x86 systems (i.e., the only architecture officially supported by Arch Linux) there is no practical difference anymore, as explained in the article now. Most guidance to use /dev/random for cryptographic keys is outdated guidance from a time where /dev/urandom and /dev/random had vastly different semantics and people did not trust the cryptographic algorithms used.

Second, in practice, the fact that /dev/random (or equivalently getrandom()) blocks for initialization often makes it impractical to use. Of course, that's always quite frustrating, since blocking for initialization is the exact reason it can still be considered more secure than /dev/urandom! I suppose we could still write that /dev/random is "recommended", but whether that recommendation can actually be followed is another question.

Synchronicity (talk) 00:04, 6 February 2023 (UTC)

A detail I forgot about: the jitterentropy algorithm is enabled for /dev/random too, not just /dev/urandom. That means that /dev/urandom and /dev/random are now exactly the same on x86 (except for poll(), but that's not really relevant). As Arch Linux only supports x86, that means that /dev/urandom and /dev/random are now exactly the same on Arch Linux. According to the Arch Wiki guidelines, content that does not apply to Arch Linux is not allowed (https://wiki.archlinux.org/title/ArchWiki:Contributing#Non-Arch_users). So strictly speaking, the article should simply state that /dev/random and /dev/urandom are the same, and leave it at that! I think it's reasonable to bend that rule a bit in this case to briefly explain the difference, but let me know if you have any concerns. Synchronicity (talk) 01:33, 6 February 2023 (UTC)

Thanks for following above referred to guidance in the future and your considerate response.

It's clear the article needed a considerable rewrite due to the kernel's advancements and it's good you took the initiative/task. It was indeed a sore point on my personal to-do list (being one who argued to create the RNG article in the first place), at least since the kernel finally extended the refurbishment to /dev/random as well. We know the kernel-devs took a long time to commit to the current /dev/random design. That manifests itself also in the quirky Mark Twain quote; djb himself used it in 2014 to summarise his arguments pro/cons of hashing whatever/RDRAND into the entropy pool (to speed up random init back then). That said, if we take the modernised architecture (re jitterentropy), it is just a matter of definition of "the basket" (to control) when applying Twain's wisdom to this (far fetched) matter. I sure agree our focus on Arch-supported architecture/defaults makes it easier for the article. I also agree it best continues to give basic info regarding /dev/{urandom}}) semantics, IMO naming /proc/sys/kernel/random/ for a reference/example can't hurt too.

Sidenote: the gnupg article has no entropy reference left. I mention it, as it is one package that deviates from the random defaults (--no-random-seed-file option) somewhat.

Anyway, I used the Twain quote and related question as an example to exemplify the difficulty to assess what's relevant for such a general-purpose article on the one hand, and an all-encompassing complex edit on the other. Nice you take interest and more time to work on it. Should there be factual points left to discuss, we better do that in Talk:RNG.

You're welcome to close this item and purge it from your user talk page any time you want.

--Indigo (talk) 20:48, 7 February 2023 (UTC)