New answers tagged

2

The answer is simple. AES is in itself a pseudorandom function, so an output from a single block encryption will produce 128-bits of pseudorandom numbers. Now to use AES to generate longer sequences, you will have to use a block-cipher mode that lets you do the same. Here is a small list of a few very popular modes ment for PRNGs: Counter(CTR): Counter ...


2

Would it be useful for companies who need to keep their data safe? Not exactly. The One-Time-Pad is extremely inconvenient. If your client has to encrypt a piece of plaintext that's 4GB large, then they will not only have to generate 4GB of random data, they also will have to share that pad with the receivers of that message, making it a total of 8GB of ...


1

Short answer: Yes. If the PRNG is cryptographically secure and it generates a certain chunk of bits at a time, then any subset of the chunk generated by the PRNG should be just as "random" as the full chunk, but this would depend on the specific implementation of the CSPRNG. For certainty, I would refer to the full documentation of the API you're using. If ...


2

Yes. Although the bit values are not identical per se (even given the same seed) you should use any of the 192 bits to form a 128 bit key - as long as you don't reuse any bits of course. If the 128 bits are not secure, then the 192 bits should also not be secure. AES keys consist of bits that are entirely random and thus unrelated, so generating a 192 bit ...


0

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 ...


0

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 ...


17

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 ...


1

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


4

The problem with CPU jitter is that it is difficult to pin down an accurate physical model of it that would allow you to calculate the entropy involved. Therefore entropy estimates have to largely be grounded on statistical testing, as in the document I linked in the comments. As you may know, statistical testing alone can only ever give you an upper bound ...


0

The NIST test suite for random numbers implements "short-term memory" machine learning algorithms. It needs to save and categorize all relevant data to be "long-term memory" machine learning. Paper: http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/SP800-22rev1a.pdf Suite: https://gerhardt.ch/random.php



Top 50 recent answers are included