Not appreciating the hijacking of the back button until the cookie form is dismissed.
yeah, it's a pretty dark pattern.
Build a tiny CA for your homelab with a Raspberry Pi
51–56 of 56 posts
Re: Build a tiny CA for your homelab with a Raspberry Pi
#52[deleted]
Re: Build a tiny CA for your homelab with a Raspberry Pi
#53This being raspberry pi absolves you from needing to buy a separate hardware noise generator: it has plenty of GPIO. For example, one can obtain entropy by sampling random noise generated by reverse-biasing a junction in a cheap pn transistor. Here is an example: http://holdenc.altervista.org/avalanche/ . Bonus — maybe it will get you hooked on electrical engineering! Btw, some versions of raspberry pi already have h…
The Raspberry Pi 4 model B can also implement a FIPS-compliant entropy source in the form of CPU Jitter Random Number Generator (JEnt)! It is listed under certificate E21 within NIST’s Entropy Source Validation Program (ESV), so it could even be used in a cryptographic module.
ESV testing for JEnt uses an oversampling rate of 3, so even if you don’t want to use the precise setup described in the certificate (maybe a different version of OS, etc), the entropy rate from this will be more than adequate.
Re: Build a tiny CA for your homelab with a Raspberry Pi
#54I'm running smallstep CA in my homelab. While it's nicely done and clearly focuses to the containerized enterprise market, its defaults are very harsh. Take for example the maximum certificate duration. While from a production/security perspective short-lived certificates are great, you don't want to renew certs in your homelab every 24-48hrs. Also, many things just don't support ACME but still benefit from a valid c…
For what it's worth, I've had quite a bit of success using ACME for devices that don't natively support it by using a sidecar service. Basically, running the ACME flow on a Linux system and then having it programmatically update the cert/key for the service that needs it. Have done this for my NAS, printer, router, etc.
Downside is that you have to provide root/admin access to copy the key material and also to restart the services. A big no-no for me, even in my homelab.
Re: Build a tiny CA for your homelab with a Raspberry Pi
#55Earlier quoted context omitted.
Suitably similar RSA keys well compromise each other. https://www.infoq.com/news/2019/12/rsa-iot-vulnerability/ So bad randomness can let a remote attacker break them much more easily.
No one puts raw bit source directly into private key, they always whiten it via some method (often entropy pool setup using strong hash/encryption functions). That means that even if you "random inputs" are totally predictable, the random values which come out of whitener are completely distinct, and generated RSA keys have virtually zero chances of being similar.
That's arguing that you can just seen an RNG with the current time and use a PRNG as your randomness source - a whitener can't give you randomness out which isn't there to start with.
In the above, fairly extreme case, the risk should be obvious: if someone has a decent guess on what the uptime of your system is, and knows you're doing this, then the search space to crack certificates can be made accessibly small.
Like if you know see a certificate with a Valid From date of say, January 1, 2025 but you know the service definitely wasn't running on January 1, 2024, then by guessing what the PRNG is you've constrained your search space to 1704027600 through 1735650000. So the issue isn't whether the numbers you emit are distinct - it's that an adversary can make it suitably likely that they can produce colliding RSA keys themselves anyway (and remember, they get unlimited attempts at this - they only have to succeed once).
EDIT: And while you can certainly argue that they couldn't predict the exact noise environment of say, your server room, it's also not impossible to model which also might constrain the search space enough to accessible. It's not "haha! we know your every move" it's just making the problem space small enough to brute force.
Re: Build a tiny CA for your homelab with a Raspberry Pi
#56Earlier quoted context omitted.
>How does the disconnected audio input of any random PC or thinclient compare? That will give you RF noise, which isn't really random.
Electrical noise (including RF noise) is really random, as in it is impossible to predict exact value. It does have non-flat spectrum, meaning some values are more probable than others, but that only means you need to whiten it. (A rough analogy might be a 6-sided die labeled with 1,1,1,2,3,4 - yes, number 1 is much more likely to come out. No, this does not make it "not really random", and some trivial math can prod…
If we were dealing with pure cosmic background radiation, or inside a Faraday cage, sure.
What I'm referring to are things like radio broadcasts, 60 Hz hum from power lines, noise put out by switching power supplies, and that sort of thing.
Just having a bias, as in your example, would be still truly random. If you knew that every tenth roll you'd get a 3, it would no longer be random. When your random number generator can be influenced by the outside world, it's no longer suitable for cryptographic use.