[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
noiz ... and more SKRONK
> Also, /etc/noiz is an attractive target
> on multi-user machines....
Right. But you notice I made it mode 660, owner root, group kmem, to
parallel the /dev/*mem devices. You have the same vulnerabilities as
always on a multi-user system, even if you put /dev/noise in the kernel
or run a TCP daemon. Another parallel is the randseed.bin file in
From an information theory point of view, I don't know how to describe
the kind of shared-entropy that this pool exhibits. Making the source
of the entropy hidden to the users by crunching on the way out with MD5
adds something to the data -- it's not true entropy, but it's some kind
of effective entropy, from the point of view of the users. Unless MD5
has weaknesses that I assume it doesn't, it's not really possible for users
to know where their spaces of possible random values overlap, so they
don't know how to exploit it.
A final note -- I should have put /etc/noiz somewhere in the
/var filesystem. Perhaps /var/adm/noiz.
But one can edit the Makefile to do that, and no other software
has to actually know where it is, since its access is totally
encapsulated by noizinit, noizstir, and noizout. The location of
these in /usr/local/bin/ is what needs to be standardized, so I
hope that's good enough for most users.
Oh, I meant to thank everyone for the great discussion and
constructive criticism of SKRONK and "encrypt tcp connections" hacks.
Especially Perry -- your enumeration of projects was good.
Based on that, and what I know of the others, the priority of
protocols I'd like to support with skronk are
0. my own hack, to get it going
1. Matt's ESM
2. Kerberized connections (kerb4 or kerb5 or both?)
3. Perhaps the SSL from Netscape
Thus SKRONK becomes what I wanted it to be: a way for sites to
advertize the availability of enhanced services (via the skronk map UDP
daemon) and a way to painlessly integrate crypto with existing code.
(The last aspect always draws user interface problems -- if it's so
transparent, how do you know if you're encrypted? Right now I have the
client end scribble to stderr when it skronks.)