I need to generate 1024 pseudo-random bits from a 100 bytes string seed (only valid lowercase chars)

One thing I'm pretty sure would be secure enough would be to repeat this 100 bytes string 20 times and encrypt it (using itself as the key with AES for instance) and then return the first 1024 bits

Does that seems fine? Is there a more "standard" way to d that (some simple/secure key expansion algorithm)?

  • $\begingroup$ That did it (example of my first suggestion, but I'm still looking for some simple/secure key-expansion/derivation if there's any): W="asdfghjkl"; printf "\$W%.0s" {1..20} | openssl aes-256-cbc -pass "pass:$W" | base64 | tr a-z8 A-Z9 | tr -dc A-Z9 | head -c 81; echo $\endgroup$
    – Lem0n
    Commented Oct 19, 2017 at 15:38
  • 6
    $\begingroup$ You're misusing the word entropy. You want a pseudo-random 1024-bit string, not 1024 bits of entropy. $\endgroup$ Commented Oct 19, 2017 at 17:03
  • $\begingroup$ You are right. I tried to explain better what I want on a disclaimer, but I edited the question to make it more clear. Thanks $\endgroup$
    – Lem0n
    Commented Oct 19, 2017 at 18:03
  • $\begingroup$ hashes or aes make ok PRNGs. SHAKE could give you the right output length up-front. $\endgroup$
    – dandavis
    Commented Oct 26, 2017 at 2:50
  • $\begingroup$ Question, Why do you need 1024 bits? If this is for some sort of encryption key it should be either 256 bits (AES, elliptic curves) or 2048+ bits (RSA, Diffie-Hellman, etc). A 1024 bit key should almost definitely not be used in 2017. $\endgroup$
    – rmalayter
    Commented Oct 27, 2017 at 13:27

1 Answer 1


You should use a well-vetted implementation of a well-researched key derivation function that can output at least 1024 bits.

HKDF-SHA-256 is the standard and secure choice these days, although constructions based on SHA-3 and Blake2 are also in use.

If the characters you’re hashing are created by a human, use a specialized and intentionally slow password-based key derivation function like scrypt or Argon2 instead.

  • $\begingroup$ I'm no expert, but do KDFs have an internal width of 100 bytes? Or would you just be wasting most of them with a piddly 20 bytes width? $\endgroup$
    – Paul Uszak
    Commented Oct 27, 2017 at 22:00
  • $\begingroup$ HKDF first compresses the input to 256 bits and then expands it via multiple invocations against that 256 bits plus a counter. It is of course possible to use a counter plus the whole raw 100 bytes input instead, but this is pointless in practice (256 bits of state is enough for any conceivable purpose). blog.cr.yp.to/20140205-entropy.html $\endgroup$
    – rmalayter
    Commented Oct 27, 2017 at 22:04
  • $\begingroup$ So your solution would not use all of the OPs 100 bytes of entropy. Methinks entropy extraction techniques are warranted... $\endgroup$
    – Paul Uszak
    Commented Oct 28, 2017 at 1:10
  • $\begingroup$ @PaulUszak anything more than 256 bits of entropy is completely pointless; see the DJB article I linked. And what do you think HKDF is if not an “entropy extractor”? The two steps in HKDF are literally called “extract” and then “expand” in the RFC. $\endgroup$
    – rmalayter
    Commented Oct 28, 2017 at 3:25
  • $\begingroup$ Suggest you look up entropy extraction wrt TRNGs for the difference. You haven't answered the OPs question. $\endgroup$
    – Paul Uszak
    Commented Oct 28, 2017 at 11:39

Your Answer

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

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