On 06/06/2018 09:12 PM, openssl-users-request@xxxxxxxxxxx digestributed: > Date: Wed, 6 Jun 2018 16:12:59 +0000 > From: Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx> > >> Hence my solution of using a hardware TRNG shared over the >> network with devices that lack the ability to have one added >> locally. > > Yes, I think that's a good approach. It reduces the attack surface, > since the client device can connect to the entropy-gathering device > with considerable assurance (it can be configured with a pinned CA > or PSK, etc), and at startup can use some entropy saved from the > previous run. An attacker in a privileged position could try active > attacks like a DoS against the connection to the entropy server, but > a (more dangerous) passive attack looks very difficult. Speaking of attack scenarios, I refreshed my info after this discussion and wondered how likely it is that someone (in a Linux world) would want to attack the entropy *sources* directly. A manipulated source's effect on applications (that read from /dev/random) would be somewhat limited due to the kernel folding in other sources as well (memento Linus' statement about RDRAND), and due to the fact that *many* consumers read from it (you cannot predict who gets which part of your manipulated entropy). For comparison, imagine someone attacking the kernel and manipulating the /dev/random driver so that it feeds predictable sequences to the targets (processes running executables "httpd", "gpg", etc.) but real pool data to all other consumers. Presto, a subverted system that still gets a clean bill of health from rngtest, ent, dieharder, or whatever other analyzer you care to try ... ... by which I mean to ask, since I read a quest for suitable entropy-distribution protocols between the lines here, maybe there is something to be said in favor of signed-at-source chunks of entropy being forwarded *through* the kernel unchanged, and leaving the trust-based selection of sources and final folding to the individual applications? > And it's practical for real-world data centers; implementation and > equipment costs are low. [has been trying to acquire a better *NTP* source than public unsigned servers in certain data centers for 8+ years] :-C Regards, -- Jochen Bern Systemingenieur www.binect.de www.facebook.de/binect
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
