Linux RNG paper

[markus reichelt]

* "Travis H." <solinym at gmail.com> wrote:

> 1) In the paper, he mentions that the state file could be altered
> by an attacker, and then he'd know the state when it first came up. 
> Of course, if he could do that, he could simply install a trojan in
> the OS itself, so this is not really that much of a concern.  If
> your hard drives might be altered by malicious parties, you should
> be using some kind of cryptographic integrity check on the contents
> before using them.  This often comes for free when encrypting the
> contents.

Agreed; but regarding unix systems, I know of none crypto
implementation that does integrity checking. Not just de/encrypt the
data, but verify that the encrypted data has not been tampered with.

A however unlikely and far-fetched analogy would be someone altering
an encrypted root fs so that f.e. /etc/hosts.deny would decrypt
differently. Such things tend to stay unnoticed when not some kind of
IDS is used, for the very fact that all the common (more or less
skillfully crafted) crypto implementations simply fail to do
integrity checking; dm-crypt, loop-aes, mainline cryptoloop,
truecrypt, bestcrypt, CrossCrypt, ...

However, though preventing the unnoticed modification of an encrypted
device is undoubtedly a goal to strive for, this is not what those
crypto implementations try to achieve. They just work towards safely
and reliably de/encrypting one's data; some more, some less.

-- 
left blank, right bald
still, loop-aes is the way to go.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20060504/1320548b/attachment.pgp>