From: Travis H. [mailto:[EMAIL PROTECTED]
On 5/4/06, markus reichelt [EMAIL PROTECTED] wrote:
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
I think an encrypted file system with builtin integrity is somewhat
interesting however the threat model is a bit broken if you are going
to boot off a potentially tampered with disk.
I mean the attacker doesnt have to tamper with the proposed
encrypted+MACed data, he just tampers with the boot
On Thu, May 04, 2006 at 01:44:48PM -0500, Travis H. wrote:
I guess perhaps the reason they don't do integrity checking is that it
involves redundant data, so the encrypted volume would be smaller, or
the block offsets don't line up, and perhaps that's trickier to handle
than a 1:1
* Travis H. [EMAIL PROTECTED] 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
On Thu, 04 May 2006 18:14:09 +0200, markus reichelt [EMAIL PROTECTED]
wrote:
* Travis H. [EMAIL PROTECTED] 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
On Thu, 04 May 2006 18:14:09 +0200, markus reichelt [EMAIL PROTECTED]
wrote:
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.
There's also
Had a bit of time waiting for a file to download, and just read the paper
that's been sitting on my desktop. The analysis of the weakness is new,
but sadly many of the problems werre already known, and several previously
discussed on this list!
The forward secrecy problem was identified circa
| Min-entropy of a probability distribution is
|
| -lg ( P[max] ),
|
| minus the base-two log of the maximum probability.
|
| The nice thing about min-entropy in the PRNG world is that it leads to
| a really clean relationship between how many bits of entropy we need
| to seed the PRNG, and
: Thursday, March 23, 2006 9:56 AM
To: Heyman, Michael
Cc: cryptography@metzdowd.com; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Linux RNG paper
I have examined the LRNG paper and have a few comments.
CC'd to the authors so mind the followups.
1) In the paper, he mentions that the state
I have examined the LRNG paper and have a few comments.
CC'd to the authors so mind the followups.
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
On Thu, Mar 23, 2006 at 01:55:30AM -0600, Travis H. wrote:
It's annoying that the random number generator code calls the
unpredictable stuff entropy. It's unpredictability that we're
concerned with, and Shannon entropy is just an upper bound on the
predictability. Unpredictability cannot be
From: David Malone [EMAIL PROTECTED]
Sent: Mar 23, 2006 3:43 PM
To: Travis H. [EMAIL PROTECTED]
Cc: Heyman, Michael [EMAIL PROTECTED], cryptography@metzdowd.com, [EMAIL
PROTECTED], [EMAIL PROTECTED]
Subject: Re: Linux RNG paper
...
One metric might be guessability (mean number of guesses
On 3/21/06, [EMAIL PROTECTED] (Heyman, Michael) wrote:
Gutterman, Pinkas, and Reinman have produced a nice as-built-specification and
analysis of the Linux
random number generator.
From http://eprint.iacr.org/2006/086.pdf:
...
” Since randomness is often consumed in a multi-user environment,
On Wed, Mar 22, 2006 at 02:31:37PM -0800, Bill Frantz wrote:
One of my pet peeves: The idea that the user is the proper atom of
protection in an OS.
My threat model includes different programs run by one (human) user. If
a Trojan, running as part of my userID, can learn something about the
14 matches
Mail list logo
