4 ms·

(not an original though, but repeating here) Thought experiment: Suppose you had a computer that didn't have a good entropy source. You need this computer to h

(not an original though, but repeating here) Thought experiment: Suppose you had a computer that didn't have a good entropy source. You need this computer to have good entropy because it needs to connect to some service, and the connection needs to be cryptographically secured and resilient to replay attacks (ie attacks where an adversary, not necessarily the service, sends an old message in response to a fresh request). Suppose further that you had a separate service that exposes a camera feed of some lava lamps—perfect for fixing your entropy problem. How do you suppose you will connect to that camera feed?

DuckFeathers 4y ago
I'd connect to the camera feed service using a PRNG, get the true random, reconnect to the camera feed service using that true random. I don't care if someone is able to connect to the camera feed.
- maxbond 4y ago
  The adversary synchronizes their clock with yours, and hits the unsecured camera feed at the exact same time. (Alternatively they poll the camera source, possibly interpolating or doing some kind of fuzzy search in a much smaller space than your keyspace.) They recover the image you used to seed your CSPRNG and are able to recover the keys you use to connect to other services.
hinkley 4y ago
I needed an entropy source for an ssl connection from a VxWorks box before Intel added the RNG instructions. Boy was that a pain in the ass. I had previously thought the server provided the random data for the AES key. Turns out that’s not true for reasons that were obvious in hindsight but inconvenient for our network topology. Ended up having to feed every low entropy source we could get our hands on into the CSPRNG. And the whole time the vendor kept trying to offer their own binary arithmetic to cook down the inputs. No, let SHA1PRNG do its job. This is what secure hash algorithms were born to do
maxbond 4y ago
I am not a cryptographer. There's probably a fatal mistake in my post. (Do let me know if you've spotted it! I've found & fixed a couple but you know what that say, anyone can come up with a cryptosystem they can't break, and I can barely break a Caesar cipher.) You'll need to cheat somehow and give the service either entropy or a keypair out of band. You can't bootstrap your entropy from absolutely nothing via a remote service, unless you trust the adversary can't compromise the connection between the foo service & the camera service (which is equivalent to the foo service having a good local entropy source to begin with, it's just that part of your motherboard's bus extends over Ethernet to the camera service). The simplest way would be for the foo and camera services to have keypairs, which you exchange manually/out of band, & communicate with classic asymmetric key cryptography. (You could come up with a similar protocol using symmetric encryption as well, using something like AES-GCM combined with a challenge-response protocol. You could also bootstrap the foo service with entropy out of band & use Diffie-Hellman to establish a shared key rather than moving keys out of band. Probably the better option in practice since there's less coupling. [Actually this doesn't quite work because it doesn't achieve authentication.]) The important part is that it's both authenticated and encrypted. You need to encrypt it so that adversaries tapping your connection don't know what image you're using to seed your CSPRNG. But if you allow unauthenticated connections to your entropy service, they don't need to tap your connection, they'll just connect to the camera service at the same time & pull down the same image that you do. And if they can't get it perfectly at the same time, well, a known image of a lava lamp taken around the same time as a secret image of a lava lamp gives us a lot of information about the state of that lava lamp, and we could conduct a search to discover the secret image (we record the encrypted traffic, and we fiddle with the image, and attempt to decrypt the traffic. When we get valid data instead of gibberish, we've found the right image.) Let's say we've done all that. Great, we can actually lose the authentication requirement now. We can create an entropy service which does all of this song and dance, and seeds a CSPRNG. The entropy service accepts a public key, uses a CSPRNG to generate some entropy, encrypts it with the public key, and returns the result. Only the client is able to use their private key to retrieve the entropy. Because we've moved away from a camera system, past outputs are no longer correlated with future outputs, and concurrent requests always get different outputs. So we can leave this service unsecured. It's dependent services still need to be bootstrapped with a keypair out of band, however.
doomrobo 4y ago
To answer the questions in this thread: having a preshared key (PSK) doesn't save you. The problem remains replay attacks: even if you have a PSK, if you don't have a fresh session, then an adversary can replay old messages back to you. The only solution to the replay problem is to have the poor-entropy machine keep a strikelist of all the messages (or hashes thereof) it has ever received from the entropy service. Thus, when receiving a new message, it can make sure it's not a replay. Of course, this means that you've turned a stateless protocol into a stateful one, and require non-volatile storage on the device for a potentially long period of time. As far as I know, nobody actually does this.

DuckFeathers 4y ago

I'd connect to the camera feed service using a PRNG, get the true random, reconnect to the camera feed service using that true random. I don't care if someone is able to connect to the camera feed.

maxbond 4y ago
The adversary synchronizes their clock with yours, and hits the unsecured camera feed at the exact same time. (Alternatively they poll the camera source, possibly interpolating or doing some kind of fuzzy search in a much smaller space than your keyspace.) They recover the image you used to seed your CSPRNG and are able to recover the keys you use to connect to other services.

hinkley 4y ago

I needed an entropy source for an ssl connection from a VxWorks box before Intel added the RNG instructions. Boy was that a pain in the ass. I had previously thought the server provided the random data for the AES key. Turns out that’s not true for reasons that were obvious in hindsight but inconvenient for our network topology. Ended up having to feed every low entropy source we could get our hands on into the CSPRNG. And the whole time the vendor kept trying to offer their own binary arithmetic to cook down the inputs. No, let SHA1PRNG do its job. This is what secure hash algorithms were born to do

maxbond 4y ago

I am not a cryptographer. There's probably a fatal mistake in my post. (Do let me know if you've spotted it! I've found & fixed a couple but you know what that say, anyone can come up with a cryptosystem they can't break, and I can barely break a Caesar cipher.) You'll need to cheat somehow and give the service either entropy or a keypair out of band. You can't bootstrap your entropy from absolutely nothing via a remote service, unless you trust the adversary can't compromise the connection between the foo service & the camera service (which is equivalent to the foo service having a good local entropy source to begin with, it's just that part of your motherboard's bus extends over Ethernet to the camera service). The simplest way would be for the foo and camera services to have keypairs, which you exchange manually/out of band, & communicate with classic asymmetric key cryptography. (You could come up with a similar protocol using symmetric encryption as well, using something like AES-GCM combined with a challenge-response protocol. You could also bootstrap the foo service with entropy out of band & use Diffie-Hellman to establish a shared key rather than moving keys out of band. Probably the better option in practice since there's less coupling. [Actually this doesn't quite work because it doesn't achieve authentication.]) The important part is that it's both authenticated and encrypted. You need to encrypt it so that adversaries tapping your connection don't know what image you're using to seed your CSPRNG. But if you allow unauthenticated connections to your entropy service, they don't need to tap your connection, they'll just connect to the camera service at the same time & pull down the same image that you do. And if they can't get it perfectly at the same time, well, a known image of a lava lamp taken around the same time as a secret image of a lava lamp gives us a lot of information about the state of that lava lamp, and we could conduct a search to discover the secret image (we record the encrypted traffic, and we fiddle with the image, and attempt to decrypt the traffic. When we get valid data instead of gibberish, we've found the right image.) Let's say we've done all that. Great, we can actually lose the authentication requirement now. We can create an entropy service which does all of this song and dance, and seeds a CSPRNG. The entropy service accepts a public key, uses a CSPRNG to generate some entropy, encrypts it with the public key, and returns the result. Only the client is able to use their private key to retrieve the entropy. Because we've moved away from a camera system, past outputs are no longer correlated with future outputs, and concurrent requests always get different outputs. So we can leave this service unsecured. It's dependent services still need to be bootstrapped with a keypair out of band, however.

doomrobo 4y ago

To answer the questions in this thread: having a preshared key (PSK) doesn't save you. The problem remains replay attacks: even if you have a PSK, if you don't have a fresh session, then an adversary can replay old messages back to you. The only solution to the replay problem is to have the poor-entropy machine keep a strikelist of all the messages (or hashes thereof) it has ever received from the entropy service. Thus, when receiving a new message, it can make sure it's not a replay. Of course, this means that you've turned a stateless protocol into a stateful one, and require non-volatile storage on the device for a potentially long period of time. As far as I know, nobody actually does this.