Lots of cryptography algorithms rely on pseudorandom number generators. Sometimes, given a plaintext, you need to generate a pseudorandom number from it. What are some fast algorithms that do so?

I've seen one that uses SHA256 and other that uses AES, but I couldn't find any literature about them or some implementation that I can use. They should be fast because processors nowadays have hardware support for them.

on page 8 of this paper: dl.acm.org/doi/10.1145/2808425.2808431 it says

enter image description here

  • 2
    $\begingroup$ The title and body of the question do not seem to match. $\endgroup$
    – Maeher
    Aug 20, 2021 at 10:58
  • 1
    $\begingroup$ @Maeher aren't pseudorandom number generators used for sampling from the uniform distribution? $\endgroup$ Aug 20, 2021 at 13:36
  • 1
    $\begingroup$ I think that you're going to have to expand upon "Sometimes, given a plaintext, you need to generate a pseudorandom number from it." A plain text is an unencrypted messaged with semantic content. What's the pseudorandom number for? $\endgroup$
    – Paul Uszak
    Aug 20, 2021 at 18:23
  • 2
    $\begingroup$ please edit your question to make it clear and self contained $\endgroup$
    – kodlu
    Aug 20, 2021 at 22:04
  • 2
    $\begingroup$ Hmm, there are 2 close votes, and then a bounty was added (so no one can vote to close anymore). Adding a bounty instead of fixing the problems ... this doesn't make anyone want to help you. $\endgroup$
    – tylo
    Aug 22, 2021 at 17:45

2 Answers 2


Converting an arbitrary message into a pseudo random number is essentially computing a cryptographic hash.

So this question seems to be asking what is the fastest secure cryptographic hash?

It is unclear what are the security requirements you have for this hash, some algorithms are very simple and have are not cryptographically secure but still provide useful digest when there is no adversary. e.g CRC can be very fast.

Other algorithms will provide pre-image and second pre image resistance but not collision resistance, e.g MD5 or SHA1

Some algorithms are considered today to be generally secure and provide also collision resistance and are often modeled as a pseudo random function. E.g SHA-3.

Here are some benchmarks comparing cryptographic primitives https://www.cryptopp.com/benchmarks.html And a different comparison(different setup and different metric): https://medium.com/logos-network/benchmarking-hash-and-signature-algorithms-6079735ce05

The latter chose blake2 as the fastest hash function and it is considered secure for any purpose requiring a secure hash function, even though it isn't as widely used the standardized SHA2 or SHA3 families.(Note Blake2 has several variants). enter image description here

The first link has MD5 pretty fast at 6.8 cpu cycles / byte which is very very fast. And still secure for many purposes but some would be uncomfortable using a "Broken" Hash function.

For most puprposes you don't need the fastest hash algorithm, you need a plenty fast enough hash, and a good implementation of anything standard should be fast enough. No one was ever fired for choosing SHA-3.


Warning: I'm a newbie

TL;DR. The fastest pre-shared key encryption algorithm, contains the fastest CSPRNG (it just adds that it XORs input against it). You may want to only modify one such that it ignores the input (e.g. doesn't XOR against the input because we don't want to encrypt).

Assuming you ask about cryptographically secure PRNGs:

  • If you want practically unlimited cycle, then pick fastest pre-shared encryption algorithm. I think it is their fundamental design goal: find fastest seeded CSPRNG, then XOR cleartext against it. After all, perfect secrecy comes when clear text is XORed against some uniformly distributed data (i.e. the one-time pad). Pre-shared encryption algorithm simply aim to generate this pad using a seeded method (seed being the key, and CSPRNG's state being the nonce).

  • If you're OK with a limited cycle, then you need to modify the fastest pre-shared encryption algorithm to make it do less work (e.g. smaller block size).

  • Ignore hashing functions for this purpose, as they are designed to solve a bigger problem: compression, which makes them a lot slower.

    Compression means that input could be much larger than output, yet the hashing function is supposed to make sure that every bit of the input is represented in every bit of the output. This forces the function to work a lot harder to ensure such dependency.

    I even think that, if one could magically use a secure hashing function, to, somehow, walk back to its input, then an $n$ bit string of that hash would beat the best lossy data compression for an $n$ bits output.

    On the other hand, a pre-shared encryption algorithm doesn't face this harder challenge, as output is guaranteed to be at least as large as the input.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.