response 25 of 49:

Aug 1 16:55 UTC 1996

And this isnt like Congress, where it is often impractical to
get the views of millions of constituents on specific issues.
Grex doesnt have that many members so opening !vote for a week
or two is reasonable particularly when issues of an organization's
political involvement are concerned.  It would be an act of
civic responsibility.


And of course, as long as the polls are open, they could also be 
asked if they want the wait que and the idle time zapper too.

response 27 of 49:

Aug 1 17:40 UTC 1996

But Ts, you would agree that the Board shouldnt presume that there
is sufficient agreement or support without polling the members first
right?  There may be one or two members who disagree with the consensus 
political stand and want at least to have it recorded officially that 
they voted against the issue.  I think this is fair.

response 29 of 49:

Aug 1 19:45 UTC 1996

Bear in mind that the page can as easily list the staff, Board memmber and
user prefix AND the 'seal' - AND, that the !vote program could be linked
in here and list how many OF how many agree with the seal..

You want to disagree? Don't vote.. You want to agree? vote - simple..

response 31 of 49:

Aug 1 22:25 UTC 1996

I think this is definitely something we should "support", at least so
far as including a "golden key" or other free publicity measures.  Given
our very limited budget, I'd don't think it would be sensible for us to
try to contribute money though.

The reason why this is important for Grex does not particularly have to
do with "encrypting" all data, or hiding anything at all.  The reason
why it's crucial for us, is because encryption technology is a
fundemental necessity to implementing reliable distributed computer
technology.  Right now, grex is fundementally "one computer", which
means it's easy for the various parts of the computer to decide if they
trust each other.  Essentially, the "uid" mechanism is sufficient proof
of someone's identity, and since it's kept by the kernel, it's "secure".
In a distributed computing environment, everything goes over the wire,
and there is no kernel that everyone can just trust.  The best method
anyone has come up with to deal with this kind of environment, is to
encrypt and transmit small "proofs of identity" to guarantee the
security and integrity of accompaning data.  All such practical schemes
require some form of secret key cryptography Even public key
cryptography needs this, because public key encryption is too slow to be
practical for large amounts of data.

The clipper chip (even the most recent proposal) is not a suitable basis
for the kind of distributed computer environment we'll need to work
towards.  The clipper chip, being hardware only, would be an expensive
investment for grex, assuming it were available at all for the obselete
machines we can afford.  On the face of it, the key escrow requirements
are completely incompatible with the need in most practical distributed
security systems (such as kerberos & PGP) to rapidly generate temporary
random secret keys.  25% of our users are foreign nationals, thus
further compounding the problem.  Furthermore, many of our users (for
whatever reason) barely even trust trust *us* (let alone the US
government), and many of the provisions in the bill of rights suggest
that authors of the constitution shared the same concern.

response 33 of 49:

Aug 2 02:16 UTC 1996

speaking of encryption, I wonder if it wouldnt be a good idea to
encrypt all mail files in the same manner (one-way) as the 
password file currently is.  This way noone could accuse the staff
of using root to read email and no legal authorities could ask staff
to do so.  This would remove any ethical delimnas if say the
guy accused of the centennial park bombing had a grexlogin and the
FBI came knocking with a search warrant.  There cant be much of an
argument if staff does not have the ablity to read email.

Of course it would require a change in policy because it would mean
if a password is lost, stasff could only retrieve the login for the user by
reaping it.  But a totally secure email would be worth it right?
Staff should want to set it up so they never have any opoportunity, 
under any circumstances, where they have to read or can read anyone's email.\

response 35 of 49:

Aug 2 04:59 UTC 1996

Mail that comes in & out goes through a number of staging areas: mqueue
/tmp (delivery) /usr/spool/mail mailbox (incoming) /tmp (receiving) mbox
(ucb mail, elm), Mail/ (pine, mh) Dealing with all of the software that
manages all of these areas is itself already a formidable problem.

There is little point in encrypting them, because the keys to encrypt &
decrypt would have to be kept online, & law enforcement would merely
need to obtain those keys as well.  If "we" didn't cooperate, they'd
certainly just seize more; or even throw us in jail for obstructing
justice.

Besides, which, *what* ethical dilemma? If the feds came in with a
search warrant, we are certainly legally obligated to cooperate.  This
system isn't intended to be a secure haven for illegal activities.  We
tell people that up front.  I also believe that if we were to happen
across clear and certain evidence that someone here had committed
criminal acts that resulted in harm or death to many human beings, it
would certainly be our moral and ethical responsibility to bring such
evidence to the proper authorities.  If we *happen* upon evidence of
criminal activity, there is a judgement call, but it is not at all hard
in the case of mass terrorism & murder.  In the case of a a lesser crime
and poor evidence, the call does get harder.  In the face of a search
warrant, unless there were something improper about the warrant, the
situation is legally quite clear.  *you* may have moral qualms about the
ability of the government to seize evidence for criminal proceedings,
but nobody on the board or staff does.  Our priorities would certainly
be to cooperate to the fullest with the gov't, to ensure they get the
information they seek, to see that the system continues operation (if
possible), and to protect the privacy of users not involved (to the
extent possible.)

response 37 of 49:

Aug 2 05:53 UTC 1996

Actually, kerouac was suggesting encrypting the mail in the same way the
password file is encrypted, which I think is supposed to be non-reversable.
If that were teh case, nobody would be able to read anybody else's mail, but
they wouldn't be able to read their own either.

response 39 of 49:

Aug 2 20:47 UTC 1996

One-way encryptoin of email might work if there was a secondary
passwordf file for e-mial access, so that a user's mail could only
be de-encrypted by thtat user's typing in his/her seocndary password
er...secondary password.

This way one's email wouldnt be readable even at the root level 
without the password for tht specific user.
Because the de-encryption routine woudl be specific to that passwored for that
login.

response 41 of 49:

Aug 2 22:48 UTC 1996

One-way "encryption" is nonsense.  The closest equivalent is a secure
hash, but that's no good for storing data, because it's designed to be
not readily invertible.  While that would save on disk storage costs,
it's doubtful many users would find it useful, except perhaps for high
volume mailing lists, and spamming attacks.  The closest technical
equivalent to what Mister Wallner describes would seem to be public key
technology, such as PGP.

Passwords aren't public key technology.  The only thing you can do with
a password, is to turn it into a relatively weak key, that is, a binary
number of perhaps 64 or 128 bits, but probably only really containing
30-60 bits of "information".  Typically, a secure hash function is used
to perform this conversion.  However derived, the resulting key is only
useful for secret key (symmetrical) encryption, not public key
encryption, and even then, the more secure systems go to extra lengths
to hide data encrypted with this relatively weak key.  Systems like
kerberos which only use symmetrical encryption, can use the key
straight.  Systems like PGP have to go to extra special lengths.  W/
PGP, for instance, the pass phrase is typically used to encrypt the
private key ring.  If the bad guy steals your private key ring, it's
still a bad thing, but it's not the kiss of death because he still has
to guess your pass phrase.

Now, let's see how we might implement this on grex.  The public key part
is simple.  We keep a file, that anyone that can read, that has
everyone's public key.  When mail comes in, our mail environment, which
is maintained by a battery of paid professionals, fetches the key,
encrypts the mail, & delivers it.  Now the bad part.  We can't expect
people to remember 2048 bit private keys.  So, of necessity, we would
*have* to store those keys on grex also.  We could (and should!) encrypt
each under a pass phrase, but they still represent the same security
risk as the current /etc/shadow file.  So, our mail environment,
fortunately maintained by a battery of paid professionals, will have to
fetch that private key, decrypt it using the user's phass phrase, & then
decrypt the user's mail.  So far, so good, other than the difficulty of
finding professionals Mister Wallner will trust not to put trap doors
in, and of then paying these professionals off the money that Mister
Wallner has been so kind to donate to grex.  (And we will ignore ITAR
and other such regulations, simply for the sake of simplicity.)

And now, for the moment of truth.  Mr. Big Tough Blue Suit pays us a
visit.  It seems somebody blew up 80 people, and accidentally left a
paper copy of an e-mail message from grex, that lists all the people who
made the bomb.  Of course we'd all want to cooperate with the FBI as
fully as possible in this serious matter.  Besides, if we didn't, the
FBI will throw us all in jail to rot, and hire a bunch of spooks from
NSA, so it wouldn't slow things down much if we didn't cooperate.  Now,
the NSA has mammouth computing machines, and special algorithms, so they
might find it simplest to just guess every password on the system.  We
certainly can't do that, so we'd probably have to do something like put
a trap door into whatever software decrypts the private key, and store
the plaintext private key, the next time the bad guy logs in.  Mr. Big
Tough Blue Suit probably won't like hearing that, so he'll just order
wire taps on every one of our phones, as well as the ISP connection, and
just record *everything* in the meanwhile, without telling us (Mr. Tax
Payer already pays for a *lot* of tape, so this is nothing,
comparatively speaking.) He'll probably also execute search warrants on
the contents of the private key store - and because it's being used to
encrypt real user data, not just for authentication purposes, we can't
contest that warrant.  (If it *is* used for *just* authentication
purposes, I understand there is some legal case history that we might be
able to use to contest such a warrant.)

Now, depending on how stupid the bad guy is, there is some chance he'll
keep on using the same e-mail account on grex, and thus neatly package
himself up for sacrifice by Mr. Big.  There's actually a fair chance of
this - I mean, how stupid do you have to be to use a public access Unix
system run by a bunch of weird part-time volunteers to plan a bombing?
Failing that, the bad guy might well use other accounts, or his friends
might.  We'd probably also ask Mr. Big for any other "interesting"
information from the e-mail scrap, such as dates, timestamps, etc., and
we'd dig through our traditional logs for the same information to see if
we can find the bad guys associates.  There's no guarantee here, but
between what we'd do, and what Mr. Big could do, if the bad guy makes
any more mistakes, there's a fair chance we'd find him.

Now, what has the use of private key technology bought us? Absolutely
nothing.  We had to more thoroughly compromise the privacy of *every*
user on grex, in pursuit of the madman, than we might have had to
otherwise.  We also had to buy a lot of extremely scarce programmer
talent, using our already slim resources, that we could have better
spent almost anywhere else.  Our pain was great, our gain was naught, so
logic says this change is out.

The simplest and fairest answer we can give people who need absolutely
private communications, is *don't use grex*.  In terms of military
security, grex ain't it, and never will be.  The main game here is
public shared communications, and e-mail is merely a helpful adjunct to
that end.  We expect e-mail to be secure against ordinary persons, and
suitable for ordinary ends.  But if you want to blow people up, or
exchange stolen computer software, or even if you merely want to store
secrets of considerable but honest commercial value, grex is just not
the place to be.

response 43 of 49:

Aug 3 17:18 UTC 1996

well I certainly dont use grex for email usually (unless my .forward file
gets screwed up and I have to respond to someone from here directly), so
its not any big deal to me.  I'm just sensitive to privacy issues, which
is why I dont buy the arguments of the FBI director who says that
exporting encryption programs that they cannot defeat is evil and a
national security threat.  I dont even think the government should be 
legally requiring that users give the keys to such encryption programs
to third-parties.  Therefore I dont agree with the Clinton Administration's
compromise.  That said, since I have nothing to hide, I would probably
be willing to do so voluntarily. 

I feel it should be my decision so I side with those who are lined up
against this idea.

response 45 of 49:

Aug 4 00:47 UTC 1996

I think this is a good cause for Grex to support.  I'd think it would take
a board vote to approve this though.

response 47 of 49:

Aug 4 07:33 UTC 1996

re #27 .. kerouac, this item is how grex polls the current crop of logins.

response 49 of 49:

Aug 18 21:13 UTC 1996

Stop those silly suits, they're taking my life!