Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:26
bram (bram@gawth.com)
Sat, 6 Feb 1999 16:07:05 -0800 (PST)
On Sat, 6 Feb 1999, David R. Conrad wrote:
> On Mon, 1 Feb 1999, bram wrote:
>
> > > For an online protocol, Alice and Bob both generate a random N-bit
> > > session key. They then exchange them (hey, they must have already
> > > had some method in mind to transfer the one). The N-bit session key
> > > they use is the XOR of the two keys they chose.
> > >
> > > As long as at least one of them had some decent entropy, they're fine.
> >
> > Hmm, yes, you're right. Of course, that does influence the protocol a bit,
> > but it reduces the problem to (at worst) one of occasional third-party
> > auditing.
>
> Forgive me if I'm being dense, but I can't quite see what the third party
> would occasionally be auditing, or why.
The third party would be verifying that the counterparties would be taking
proper measures to ensure they always had sufficient entropy around.
Auditing isn't necessary for many applications, but it's important for
some stuff we've been doing where I work.
> > It's also a good idea to send over some random bits to any counterparty
> > you establish a secure connection with, just for good measure.
>
> I always get a bit nervous whenever anyone talks about sending random bits
> around, but I suppose as long as the receiver yarrows them, it won't hurt.
>
> Still, I'm not entirely clear on how it will help. You must already have
> a secure channel to send the bits over, because if Eve sees them on the
> wire then they're useless. On the other hand, if you *do* already have a
> secure channel, what purpose do the random bits serve?
It doesn't make any difference for an already extant connection, it's for
the benefit of whatever future use either counterparty could have for
random numbers.
It's worth repeating that this is just a redundant measure, not the one
which really should be relied on, which is a local RNG.
> > I think it's a good idea for any CSPRNG to be able to say that it doesn't
> > have enough entropy at the moment. For example, /dev/random could be made
> > to encounter an I/O problem if the RNG has been unavailable for too long.
>
> Doesn't it already block if it doesn't think it has enough entropy in its
> pool? I thought the distinction between /dev/random and /dev/urandom was
> just that.
I did not know that.
-Bram
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:26