On Tue, Apr 19, 2005 at 04:31:47AM +, David Wagner wrote:
> Theodore Ts'o wrote:
> >For one, /dev/urandom and /dev/random don't use the same pool
> >(anymore). They used to, a long time ago, but certainly as of the
> >writing of the paper this was no longer true. This invalidates the
> >enti
Theodore Ts'o <[EMAIL PROTECTED]> writes:
> With a properly set up set of init scripts, /dev/random is
> initialized with seed material for all but the initial boot
What about CD-ROM based distros (e.g., Knoppix), where every boot is
the initial boot?
> (and even that problem can be solved by ha
Theodore Ts'o wrote:
>For one, /dev/urandom and /dev/random don't use the same pool
>(anymore). They used to, a long time ago, but certainly as of the
>writing of the paper this was no longer true. This invalidates the
>entire last paragraph of Section 5.3.
Ok, you're right, this is a serious f
On Mon, Apr 18, 2005 at 09:40:37PM +, David Wagner wrote:
> Yes, that is a minor glitch, but I believe all their points remain
> valid nonetheless. My advice is to apply the appropriate s/MD5/SHA1/g
> substitution, and re-read the paper to see what you can get out of it.
>
> The problem is no
Matt Mackall wrote:
>On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
>> http://eprint.iacr.org/2005/029
>
>Unfortunately, this paper's analysis of /dev/random is so shallow that
>they don't even know what hash it's using. Almost all of section 5.3
>is wrong (and was when I read it in
[please reply to all when posting to lkml]
On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
> >First, a reminder that the design goal of /dev/random proper is
> >information-theoretic security. That is, it should be secure against
> >an attacker with infinite computational power.
>
Okay, I've merged several e-mails here for compactness...
>> I'm not sure which claim you're skeptical of. The claim that it's
>> a design goal, or the claim that it achieves it?
>
> Oops! Gosh, I was unclear, wasn't it? Sorry about that.
> I meant the latter claim.
>
> I certainly agree that i
Jean-Luc Cooke wrote:
>The part which suggests choosing an irreducible poly and a value "a" in the
>preprocessing stage ... last I checked the value for a and the poly need to
>be secret. How do you generate poly and a, Catch-22? Perhaps I'm missing
>something and someone can point it out.
I do
linux wrote:
>Thank you for pointing out the paper; Appendix A is particularly
>interesting. And the [BST03] reference looks *really* nice! I haven't
>finished it yet, but based on what I've read so far, I'd like to
>*strongly* recommnd that any would-be /dev/random hackers read it
>carefully. I
linux wrote:
>3) Fortuna's design doesn't actually *work*. The authors' analysis
> only works in the case that the entropy seeds are independent, but
> forgot to state the assumption. Some people reviewing the design
> don't notice the omission.
Ok, now I understand your objection. Yup, t
linux wrote:
>David Wagner wrote:
>>linux wrote:
>>> First, a reminder that the design goal of /dev/random proper is
>>> information-theoretic security. That is, it should be secure against
>>> an attacker with infinite computational power.
>
>> I am skeptical.
>> I have never seen any convincing
On Sat, Apr 16, 2005 at 05:16:22PM -, [EMAIL PROTECTED] wrote:
> > "How does the entropy estimator measure entropy of the event?" becomes a
> > crucial concern here. What if, by your leading example, there is 1/2 bit
> > of entropy in each event? Will the estimator even account for 1/2 bits?
On Sat, Apr 16, 2005 at 10:05:55AM -, [EMAIL PROTECTED] wrote:
> MErging e-mails, first from [EMAIL PROTECTED]:
> > You really ought to look at the _current_ implementation. There is no
> > SHA1 code in random.c.
>
> So I'm imagining the call to sha_transform() in 2.6.12-rc2's
> extract_buf()
> Yes I saw that the first time, just struck me as "why? why did I have to sit
> here and add a that to the litany of things to remember when it's so easy to
> just do it right?"
Huh? Why? Because it's faster and less code, that's why.
In what conceivable way is it NOT right?
On little-endian
> Correct me if I'm wrong here, but uniformity of the linear function isn't
> sufficent even if we implemented like this (right now it's more a+X than
> a X).
>
> The part which suggests choosing an irreducible poly and a value "a" in the
> preprocessing stage ... last I checked the value for a an
On Sat, Apr 16, 2005 at 10:05:55AM -, [EMAIL PROTECTED] wrote:
> Anyway, back to the long-suffering [EMAIL PROTECTED]:
;)
> >> something? Because it makes zero difference, and reduces the code
> >> size and execution time. Which is obviously a Good Thing.)
>
> > It just bugged me when I wa
On Sat, Apr 16, 2005 at 11:10:33AM -, [EMAIL PROTECTED] wrote:
> Thank you for pointing out the paper; Appendix A is particularly
> interesting. And the [BST03] reference looks *really* nice! I haven't
> finished it yet, but based on what I've read so far, I'd like to
> *strongly* recommnd th
>> /dev/urandom depends on the strength of the crypto primitives.
>> /dev/random does not. All it needs is a good uniform hash.
>
> That's not at all clear. I'll go farther: I think it is unlikely
> to be true.
>
> If you want to think about cryptographic primitives being arbitrarily
> broken,
>> First, a reminder that the design goal of /dev/random proper is
>> information-theoretic security. That is, it should be secure against
>> an attacker with infinite computational power.
> I am skeptical.
> I have never seen any convincing evidence for this claim,
> and I suspect that there are
MErging e-mails, first from [EMAIL PROTECTED]:
> You really ought to look at the _current_ implementation. There is no
> SHA1 code in random.c.
So I'm imagining the call to sha_transform() in 2.6.12-rc2's
extract_buf()? The SHA1 code has been moved to lib/sha1.c, so there's
no SHA1 code *lexical
linux wrote:
>/dev/urandom depends on the strength of the crypto primitives.
>/dev/random does not. All it needs is a good uniform hash.
That's not at all clear. I'll go farther: I think it is unlikely
to be true.
If you want to think about cryptographic primitives being arbitrarily
broken, I t
Theodore Ts'o wrote:
>With a properly set up set of init scripts, /dev/random is initialized
>with seed material for all but the initial boot [...]
I'm not so sure. Someone posted on this mailing list several months
ago examples of code in the kernel that looks like it could run before
those ini
Jean-Luc Cooke wrote:
>Info-theoretic randomness is a strong desire of some/many users, [..]
I don't know. Most of the time that I've seen users say they want
information-theoretic randomness, I've gotten the impression that those
users didn't really understand what information-theoretic randomn
>First, a reminder that the design goal of /dev/random proper is
>information-theoretic security. That is, it should be secure against
>an attacker with infinite computational power.
I am skeptical.
I have never seen any convincing evidence for this claim,
and I suspect that there are cases in wh
Matt Mackall wrote:
>While it may have some good properties, it lacks
>some that random.c has, particularly robustness in the face of failure
>of crypto primitives.
It's probably not a big deal, because I'm not worried about the
failure of standard crypto primitives, but--
Do you know of any ana
On Fri, Apr 15, 2005 at 12:22:25PM -0400, Jean-Luc Cooke wrote:
> And the argument that "random.c doesn't rely on the strength of crypto
> primitives" is kinda lame, though I see where you're coming from. random.c's
> entropy mixing and output depends on the (endian incorrect) SHA-1
> implementati
On Fri, Apr 15, 2005 at 03:38:01PM -, [EMAIL PROTECTED] wrote:
>
> First of all, people *on* the netowrk path can just *see* the packets.
> Or modify them. Or whatever.
> The point is to prevent hijacking by people *not* on the path.
Yes, you're correct of course. Of course, I'll note that
On Fri, Apr 15, 2005 at 04:50:36PM -, [EMAIL PROTECTED] wrote:
> (And as for the endianness of the SHA-1, are you trying to imply
> something? Because it makes zero difference, and reduces the code
> size and execution time. Which is obviously a Good Thing.)
It just bugged me when I was read
> And the argument that "random.c doesn't rely on the strength of crypto
> primitives" is kinda lame, though I see where you're coming from.
> random.c's entropy mixing and output depends on the (endian incorrect)
> SHA-1 implementation hard coded in that file to be pre-image resistant.
> If that f
On Fri, Apr 15, 2005 at 10:42:16AM -0400, Theodore Ts'o wrote:
> > Just to be clear, I don't remember it ever throwing entropy away, but
> > it hoards some for years, thereby making it effectively unavailable.
> > Any catastrophic reseeding solution has to hold back entropy for some
> > time.
>
>
> The ISN selection is there only to make it harder to accomplish TCP
> hijacking attacks from people who are on networking path between the
> source and destination. And you have to guess the ISI before the
> 3-way TCP handshake has been negotiated (or if you can stop the SYN
> packet in flight,
On Fri, Apr 15, 2005 at 01:34:17AM -, [EMAIL PROTECTED] wrote:
> (Speaking of which, perhaps it's time, in light of the breaking of MD5,
> to revisit the cut-down MD4 routine used in the TCP ISN selection?
> I haven't read the MD5 & SHA1 papers in enough detail to understand the
> flaw, but per
> What if someone accesses the seed file directly before the machine
> boots? Well, either (a) they have broken root already, or (b) have
> direct access to the disk. In either case, the attacker with such
> powers can just has easily trojan an executable or a kernel, and
> you've got far worse p
> Waiting for 256bits of entropy before outputting data is a good goal.
> Problem becomes how do you measure entropy in a reliable way? This had
> me lynched last time I asked it so I'll stop right there.
It's a problem. Also, with the current increase in wireless keyboards
and mice, that source
On Thu, Apr 14, 2005 at 02:15:38PM -, [EMAIL PROTECTED] wrote:
> I've heard a suggestion that something like /dev/urandom, but which blocks
> until it has received a minimum amount of seed material at least once,
> would be a nice thing. So boot-time crypto initialization can stall
> until it
Thanks for the post.
Waiting for 256bits of entropy before outputting data is a good goal. Problem
becomes how do you measure entropy in a reliable way? This had me lynched
last time I asked it so I'll stop right there.
Info-theoretic randomness is a strong desire of some/many users, and they t
Just to refersh everyone's memory as to the strengths and weaknesses
of Fortuna...
First, a reminder that the design goal of /dev/random proper is
information-theoretic security. That is, it should be secure against
an attacker with infinite computational power. If you want a weaker
guarantee, u
On Wed, Apr 13, 2005 at 08:26:47PM -0400, Jean-Luc Cooke wrote:
> On Wed, Apr 13, 2005 at 05:09:39PM -0700, Matt Mackall wrote:
> > On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote:
> > > Ahh. Thanks Herbert.
> > >
> > > Matt,
> > >
> > > Any insight on how to test syn cookies and
On Wed, Apr 13, 2005 at 05:09:39PM -0700, Matt Mackall wrote:
> On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote:
> > Ahh. Thanks Herbert.
> >
> > Matt,
> >
> > Any insight on how to test syn cookies and the other network stuff in
> > random.c? My patch is attached, but I havn't t
On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote:
> Ahh. Thanks Herbert.
>
> Matt,
>
> Any insight on how to test syn cookies and the other network stuff in
> random.c? My patch is attached, but I havn't tested that part yet.
For starters, this is not against anything like a curr
40 matches
Mail list logo
