2
$\begingroup$

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?

$\endgroup$
2
  • $\begingroup$ re the "fingerprint" section: Look up 'sidechannel attacks' and similar resources $\endgroup$ Commented Jan 16, 2014 at 2:51
  • $\begingroup$ 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. $\endgroup$
    – indiv
    Commented Jul 2, 2015 at 18:24

1 Answer 1

0
$\begingroup$

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.

$\endgroup$
2
  • $\begingroup$ 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. $\endgroup$ Commented Jan 18, 2014 at 0:14
  • $\begingroup$ You shouldn't be able to break it, the CPU doesn't "leave a pattern". $\endgroup$
    – Conrado
    Commented Jan 18, 2014 at 3:44

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.