0
$\begingroup$

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)?

$\endgroup$
  • $\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 Oct 19 '17 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$ – CodesInChaos Oct 19 '17 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 Oct 19 '17 at 18:03
  • $\begingroup$ hashes or aes make ok PRNGs. SHAKE could give you the right output length up-front. $\endgroup$ – dandavis Oct 26 '17 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 Oct 27 '17 at 13:27
1
$\begingroup$

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.

$\endgroup$
  • $\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 Oct 27 '17 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 Oct 27 '17 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 Oct 28 '17 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 Oct 28 '17 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 Oct 28 '17 at 11:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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