Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The owner of the random.org service recommends that you do not use randomly generated numbers from their website in cryptographic keys. This makes sense, but it got me wondering. Is it possible to securely transfer random values in such a way that they are still viable for use in cryptography?

They can be trivially transferred with a physical cable, but what about when such an instance is impossible? For instance, when a true random number generator is physically separated from the client which needs random numbers, and both machines are in control by the same person.

Is this practical to do securely?

share|improve this question
7  
Remember that "random" is a process, not a product. If you generate data using a random generator and decide that it's going to be your key (or used to generate your key), then you should treat it as you would any other sensitive information. In particular, you can transmit it using any encryption system. – fkraiem Jan 30 at 8:29

Is it possible to securely transfer random values in such a way that they are still viable for use in cryptography?

Yes and this is done all the time.

If you use a TLS_RSA cipher suite, the client uses RSA to encrypt key material, i.e. random values, and transfer that securely to the server for key derivation.

The owner of the random.org service recommends that you do not use randomly generated numbers from their website for use in cryptographic keys.

The reason for this is not the security of transferring the random numbers (random.org is available through TLS), but the fact that you cannot be sure they are not storing or manipulating the numbers:

We should probably note that while fetching the numbers via secure HTTP would protect them from being observed while in transit, anyone genuinely concerned with security should not trust anyone else (including RANDOM.ORG) to generate their cryptographic keys.

So it is possible, but you would have to trust the one generating and sending the random numbers.

share|improve this answer

Simply encrypt the random data as you would any other data you transfer over an untrusted channel.

share|improve this answer

It rather depends on how you define "secure".

Is your attacker only capable of evesdropping or are they capable of a MITM? do your parties have any pre-arranged crypto keys?

If the attacker is only capable of evesdropping then the recipiant can send the sender their public key and the sender can use that public key and use it to encrypt stuff and send it to the recipiant. The fact it's random data isn't really any different from any other data.

Similarly if the parties have pre-agreed keys then they can use them to encrypt the random data.

However the system is only as secure as the encryption method used to send the random data. So sending a one-time pad this way would be fairly pointless.

If you are not trying to establish a shared secret you are probablly better off using the data received through the encrypted network channel as one of several sources of seed data for a CSPRNG.

share|improve this answer

I'm making the assumption that your system just needs to be feed with random data, not with the exact data produced by the random generator.

I would transmit it in plain and then combine it with some private key and use a good hash function:

  • You don't really need to recover the data sent by the random generator, so encryption is at most, as good as hashing.
  • Less complexity, since your random generator can be just a dummy machine spitting random, it doesn't have to support encryption.
  • The full system requires some private key, that's for granted (as shown in every other answer), but this way only one system knows about the private key.
  • Ok, with the exception of asymmetric encryption, but usually encryption is faster than decryption (for this type) and then, how is that different from receiving the random data (in plain) and then encrypting it (apart from being slower)?.
  • Furthermore, you can combine both approaches if you have resources (you can use encryption and then a hash).
  • Finally, you have just one person to control both machines. This way this person can focus on just one machine and be responsible of changing the private key once in a while.

However, I would prefer to use encryption to transmit it than explaining this to my employer.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.