serpente has quit [Remote host closed the connection]
zorz has joined #opencrux
zorz has quit [Quit: leaving]
farkuhar has joined #opencrux
<farkuhar> qutebrowser inside dwm or sway? https://prairieturtle.ca/crux/misc/crux.nu.png Wow, that triggers memories from about 5 years ago. It takes so long to compile qtwebengine, I can't be bothered to install more than one bloated browser from contrib.
<SiFuh__> farkuhar: qutebrowser is qugly
SiFuh_ has quit [Remote host closed the connection]
SiFuh_ has joined #opencrux
<SiFuh__> SiFuh_: farkuhar is here
SiFuh__ is now known as SiFuh
<SiFuh> dlcusa: I tried to download my rc from another machine and the URL was wrong. Strange. I updated the rc and decided to just shove the rc archive into the directory for now for core/rc
<farkuhar> Speaking of rc ... in my latest bash script all the commands that dealt with /dev/urandom are commented out, with a note that kernels newer than 5.6 don't need any such help to generate entropy. But darfo is still trying to implement the suggestion from stenur's FS#1921.
<SiFuh> farkuhar: Yours? Or you copied from me?
<SiFuh> I left a huge bloody note explaining why it was commented out
<SiFuh> I even explained it multiple times in #crux-social
<farkuhar> SiFuh: Probably copied from you, then. I was simply referring to the most recent version in my forked tools/rc repo.
<SiFuh> https://dpaste.com/59NUPTVDW.txt <-- Here is the one from my C version
<SiFuh> I don't know where my rc shell scripts are anymore. lost interest when I discovered rc in binary is way faster
<SiFuh> No that's an old one
<farkuhar> Well, somebody should reply to darfo in #crux and let him know why micro-managing /dev/urandom isn't really necessary with modern kernels.
<SiFuh> I was moving stuff around a few weeks back and removed the wrong versions so thought... fuck it, I don't care farkuhar has taken it over. I will stick to rc.c version
<SiFuh> I left CRUX. Hmm, maybe still in CRUX on the NFS server. Let me check.
<farkuhar> `zgrep RNG /proc/config.gz` returns only one driver that I didn't activate for my current kernel (CONFIG_CRYPTO_USER_API_RNG_CAVP). Every other random-number generator option is either a module or built-in.
<SiFuh_> Done
<SiFuh> Congratulations!
<farkuhar> shell script instead of binary rc is not the biggest bottleneck in my startup, anyway. There's a noticeable delay when running `/etc/rc.d/sysklogd start`, thanks to some poorly-chosen flags for /sbin/start-stop-daemon. I have to re-read the man-page to find the right flags.
<farkuhar> SiFuh: thanks for sharing your expertise where darfo and others are likely to benefit from it.
<SiFuh> RNG (software) was introduced around kernel version 1X by the way. Hardware based around 3X but wasn't fully implemented until 4X and is now the standard in 5X
<SiFuh> farkuhar: I really doubt I will ever go back to a shell based rc script for the main rc anymore. rc.* are shell based, because they are user editable. But the rc itself, is stock and can be tweaked before compilation. But in general, users don't really need to edit rc itself.
<farkuhar> It's probably easier to steer darfo away from the /dev/urandom manipulations, than to convince him to abandon qutebrowser under sway. The latter choice is more a matter of taste, not guided so much by technical considerations.
<SiFuh> /dev/urandom is a perfect example of how deprecated the CRUX dev team really is. Rather a maintainer add colours than actually look into the underlying principles of how it should be run. They had so much time between 3.5, 3.7 and 3.8 to stay updated and they are still pushing old broken software.
<SiFuh> They spend so much of their time talking shit, and building ports, they never look into the deep runnings of CRUX itself.
serpente has joined #opencrux
serpente has left #opencrux [#opencrux]
serpente has joined #opencrux
<SiFuh> farkuhar: serpente tried to join but slipped over on the way in.
<farkuhar> You know what else would be easy to fix? The hard-coded http scheme that git.crux.nu is using to load assets from the main crux site. Maybe other browsers silently upgrade http to https, but darfo's qutebrowser doesn't.
<SiFuh> No idea
<SiFuh> farkuhar: let me know if darfo replies.
<ukky> We should not rely on Linux kernel to initialize random seed upon every boot. Random seed has to be saved upon shutdown/reboot and that seed has to be used to initialize RNG seen upon system start.
<SiFuh> ukky: Well could always write in a fail safe possible check cat /proc/sys/kernel/random/<something>
<ukky> SiFuh: We just have to consult the size reported in /proc/sys/kernel/random/poolsize, and save the same amount of random data on a non-volatile partition.
<SiFuh> ukky: I would suggest /proc/sys/kernel/random/entropy_avail
<SiFuh> We could implement if < 256 then seed that crap with software. Else, do nothing.
<ukky> /proc/sys/kernel/random/entropy_avail is not important when we save $(cat /proc/sys/kernel/random/poolsize) bytes from /dev/urandom onto non-volatile storage.
<SiFuh> So you are saying what is 'avail' is of no relevance?
<ukky> /dev/urandom should stall until all 256 bytes are generated
<ukky> dd if=/dev/urandom bs=$(cat /proc/sys/kernel/random/poolsize) count=1 <=== does not care about entropy_avail
<SiFuh> ukky: If the results of /proc/sys/kernel/random/entropy_avail is 0 then the hardware section didn't do anything and there will be no cryptographic errr something. On modern systems it should be between 256 and 4096 bits.
<SiFuh> no cryptography available from hardware*
<ukky> Entropy might starve only when you need a lot of random numbers, fast. And especially from /dev/random. From /dev/urandom, you should not get in trouble saving 256 bytes.
<SiFuh> I fail to see your point. I understand hardware starving for sure. But if less than 256 then it's dead. So < 256.
<ukky> When reading /dev/urandom, I never had to know what is the current state of /proc/sys/kernel/random/entropy_avail. I just read, lets say, 10 TiB of random data from /dev/urandom, that's it.
<SiFuh> But /dev/urandom, still exists. It's not not neccessary for seeding unless you are running ancient hardware which CRUX shouldn't support or no kernel options configured for it.
<SiFuh> If you want to find out if hardware is starving you use /proc/sys/kernel/random/entropy_avail. Not poolsize. Poolsize shows you what you have which could be interpreted as the same as entroopy_avail
<ukky> No. poolsize is the size of random seed you have to write into /dev/urandom upon system boot.
<SiFuh> CRNG populates /dev/urandom right?
<ukky> What is CRNG?
<SiFuh> Cryptographically Secure Pseudorandom Number Generator (CRNG)
<ukky> I only know terns TRNG and PRNG
<ukky> s/terns/terms/
<SiFuh> Hold on, let me think. I need to get this right
<SiFuh> From my understanding the 5X kernel uses this: Hardware RNG > Entropy Pool > CRNG Seeding > CRNG Output > /dev/urandom and getrandom(). The entropy pool snatches data from Hardware RNG + Noise (Environmental) + CPU execution based on timing variations during execution.
<SiFuh> If you have no RNG in your kernel, /dev/urandom is still active based on other things. So if there are certain steps missed (eg no RNG) it still creates it from other sources.
<SiFuh> But, I could be very wrong...
<ukky> So, basically, Linux kernel 5.x+ has to generate good RNG seed upon every boot. And, basically, every boot of the same system migt generate the same RNG seed.
<SiFuh> No because background noise and CPU execution based on timing variations changes.
<ukky> The second method, saving and restoring RNG seed, would generate more random seed, on the same system.
<SiFuh> Fortunately it uses a variety of methods to create a soup kitchen in India during rushing hour whilst the world cup is going on. ;-)
<SiFuh> rush*
<ukky> I would not rely just on Linux to generate random seed.
<SiFuh> But the software version from 1X is from the Linux Kernel.
<SiFuh> As far as I know, they introduced hardware entropy to add an extra layer based on your hardware.
<ukky> What I mean, I would not rely on Linux without help of saved random seed somewhere in /var/lib/
<ukky> My hardware does not change upon every boot. So, RNG seed will be different on different systems, but might be the same on the same PC every boot.
<SiFuh> So you are referring to this on shutdown where they can build a new random see from the previous? /bin/dd if=/dev/urandom of=/var/lib/urandom/seed
<ukky> SiFuh: exactly. It is very simple, but more random, compared to just relying on kernel ability to create a new seed.
<SiFuh> Hmm, but the hardware always produces a different result even if the hardware never changes
<ukky> RNG seed is very problematic on the embedded devices, as those are using the same boot image. Thus, on the first boot you might get the same PRNG sequence.
<SiFuh> But hardware RNG is reliant on thermal noise, clock-drift and quantum level effects
<SiFuh> It is never the same twice
<SiFuh> Even voltage fluctuations change it's result and the temperature
<ukky> Theoretically, on different hardware, you get different sequence.
<ukky> You need hardware True RNG to get really random data upon every query.
<SiFuh> And if not 256 and is less then it failed, so it falls back to the kernel software version.
<SiFuh> Ahh the goal to get true randomness in a world that is never random ;-)
<ukky> i don't think I ever had True RNG, or hardware RNG.
<SiFuh> Well I don't think copying an old seed and utilizing it again to create a new seed is truely random either.
<ukky> Anyway, I just wanted to add my two cents on RNG seed subject.
<SiFuh> Good talk. You stretched my synaptic nerves. I actually enjoyed it
<SiFuh> But as far as I know in Linux Hardware based RNG is the best.
<SiFuh> I know OpenBSD has a similar way of doing it
<ukky> When you save 'seed' it will _not_ be used 'as-is' upon next boot. Kernel will use it for creation of derived RNG seed, combining 'old' RNG data with 'new' RNG data.
<SiFuh> ukky: Isn't that what I said?
<SiFuh> Well I don't think copying an old seed and ----> utilizing it again to create a new seed <---- is truely random either.
<ukky> No. You sad that it is not a good idea to use 'old' seed.
<ukky> I say: 'It is a good idea to use old seed'
<ukky> Thus, we have opposite opinions.
<SiFuh> utilizing means the kernel takes it to generate a new one.
<ukky> Yes. But you say this is not good.
<SiFuh> I said it is not truely random... I think.
<SiFuh> Besides it had to come from somewhere.
<ukky> You probably don't understand what is truely random.
<SiFuh> There is no such thing
<SiFuh> You can't do random in a universe that isn't random. So humans create the closest thing to random
<ukky> I had to follow this spec when testing HW RNG at work: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-90b.pdf
<SiFuh> If it was so simple to create something random we'd not need most of what we do to try and create it.
<SiFuh> ukky: 2018!
<ukky> SiFuh: Is 2018 your preferred year?
<SiFuh> No that document was from then
<SiFuh> I touches, ever so slightly the hardware RNG as background noise but it never talks about hardware that have RNG built into their CPUs
<SiFuh> An entropy source that uses dedicated hardware or uses a physical
<SiFuh> experiment (noisy diode(s), oscillators, event sampling like
<SiFuh> radioactive decay, etc.)
<ukky> My test were done sometime in 2020. So, after the paper was published.
<SiFuh> Noise sources can be divided into two categories: Physical noise sources use dedicated hardware to generate randomness; whereas Non-physical noise sources use system data (such as output of Application Programming Interface (API) functions, Random Access Memory (RAM) data or system time) or human input (e.g., mouse movements) to generate randomness.
<SiFuh> It is quite out-dated actually
<SiFuh> It talks about mouse movements. I remember those days. Generate an SSH key and you had to type random keys and move the mouse around
<SiFuh> ukky: The update looks like a Power Point Presentation
<SiFuh> Alright, I'm out. Got crap to do. And I will be sporadically here until July I think.
zorz has joined #opencrux