Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

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

Consider the following scenarios:

  • using OpenSSL to encrypt a file with Rijndael-256
  • using LUKS to encrypt a hard-drive that is used every day

Exactly when is entropy from /dev/random needed for a crypto process? Is it only needed for the key generation or is it also needed for the encryption process itself?

When the CPU is executing a crypto process (key generation or encryption) for a program, does the CPU cause some kind of pattern (like a fingerprint of the encrypted data) as it processes? Can this "processing pattern" then be used to break the encryption and see the plaintext?

share|improve this question
re the "fingerprint" section: Look up 'sidechannel attacks' and similar resources – figlesquidge Jan 16 '14 at 2:51
OpenSSL uses its own PRNG (or DRBG) to generate pseudo-random numbers. It only uses /dev/urandom or /dev/random to generate an unpredictable seed, and then never touches those devices again. – indiv Jul 2 '15 at 18:24
up vote 0 down vote accepted

This first scenario: it depends on the specific command, but it should need randomness when generating the key (or when deriving the key from a password, when generating the salt) and when generating the initialization vector for encryption.

The second scenario: when generating the master key, and when generating the salt used with the user's password to encrypt the master key. It does not need randomness for encryption, since there is no place to store initalization vectors. The algorithms usually try to compensate for this by using the index of the disk sector in the algorithm.

Also, I'm not sure if /dev/random is used; I think that at least OpenSSL uses /dev/urandom/.

For the second question, there are side channel attacks as mentioned. Depending on the implementation, it may be possible to retrieve keys by analyzing timings or energy consumption.

share|improve this answer
You got me wrong on sidechannel attacks. I mean, can you break encryption if you only have the encrypted (external) harddrive and a powered-off computer (clean RAM) that probably was used to encrypt that (external) harddrive? Does the CPU leave a pattern inside the ciphertext that can be exploited - the way the CPU processed the encryption process. – user3200534 Jan 18 '14 at 0:14
You shouldn't be able to break it, the CPU doesn't "leave a pattern". – Conrado PLG Jan 18 '14 at 3:44

Your Answer


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.