From: Jeff Gostin <jgostin@eternal.pha.pa.us>
Date: Sun, 18 Sep 94 01:50:15 PDT
To: cypherpunks@toad.com
Subject: Data Havens
Message-ID: <940918022220i9bjgostin@eternal.pha.pa.us>
MIME-Version: 1.0
Content-Type: text/plain


dfloyd@runner.utsa.edu (Douglas R. Floyd) writes:

> I know this may be getting off track on this list, but it may be worthwhile.
Nah, Data Havens are well within the "charter". :-)

> 1:  I am clueless about Perl, and not that great with C.
     This is your first, and foremost, problem. I'm not terribly familiar
with Perl, however, if it's half as anal-retentive as C is, make damn sure
you know your stuff, or at least have a trusted opinion on the subject (Hi
RS!! You know who you are!).

> 2:  One must have to "hide" behind a VERY TRUSTABLE remailer, one that
>     does not go down all the time, and one that accepts PGP encoded
>     mail.
Agreed.

> 3:  Would hiding behind one remailer or two be secure enough?  There
>     is a problem, unlike simple remailer chaining that people need to
>     be able to E-mail the script.
     Define your attacker. Who is this suppose to be "secure enough"
against? If it's Joe Avg. CompuGeek, yes, one should be "enough". If,
OTOH, the NSA is your intended foe, find 12. Then find 3 more. Then,
perhaps another 43. Then, MAYBE, you'll be "secure enough".

     You see, the problem with "secure enough" is that a good security
system, while not foolproof, makes the cost of attack substantially higher
than the cost of the information so gained. So, ask yourself: how much
"money" (IE: resources, time, and man-hours) is "too much" for the value
of the data and obscurity your DH will offer. Once you've determined this,
then, and ONLY THEN, have you determined how much security is "secure
enough" for your purposes.

> 4:  A need for verifing that the mail got to the DH successfully since
>     data errors do occur, and sometimes networks truncate mail packets.
>     (Compuserve is notorius about this, so is Fidonet).
     You'll pardon me for saying, but the hell with CI$, and to hell, even
quicker, with Fido. Anyone who's serious enough will find their way onto
Internet. Call me a purist, or a jackass, but the aforementioned are more
of a handicap than a help. I say drop 'em.

> 5:  A way of making verifing that the user is who (s)he claims to be.
>     (PGP, IDEA, or a passphrase)
     Well, the only real way to do this SECURELY is for human intervention
to decide which keys are accurate and which aren't. Barring that, try
taking advantage of the keyservers. When a packet comes in, snag a copy of
ALL the keys this person has (and, perhaps, a few that haven't, just for a
confounding factor), and use them one-by-one until a match is generated.
Then, discard all keys. If no match, trash the packet.

> 6:  Multiple security levels, so files cannot be retrived even if
>     one's PGP key is compromised (user settable)
Fair enough... multiple keys? How else?

> 7:  How will files be stored?  Will folders and directories actually
>     be made, or will they be all stored in one place with wierd names
>     (to prevent name collisions) and one file be the index?  Will there
>     be user names or UID's?
     How about just saving the files under sequencial names (0000000001,
0000000002, base 62 (A-Z, a-z, 0-9))? Then, use a PGP-encrypted 1024-bit
key to encrypt the index file.

> 8:  There will need to be a way to tell if the DH is up or not.
Pinging?

> 9:  How will PGP keys be stored and indexed?  One would not want
>     their files mailed in the clear.  (How would I mail files
>     if the user cannot use PGP?  have a user settable password,
>     and use crypt?)
See above. . .

> 10: How would people be able to trust a DH?. . . Perhaps a reputation
> based system?
     To borrow a phrase from X-Files: "Trust no one." (X-Files, btw, is a
very cool show. New season started yesterday. Friday, 9pm, FOX). The
problem is a chicken-egg paradox: If no one uses your DH, what kind of
reputation can it have, but, in order to get a reputation, one has to use
it. . . I dunno how to handle this.

> 11: How would a DH turn away files because the disk is full?
     Don't accept files when less than 5% of the drive is full. Send back
a confirmation code different from that of a successful transfer. Either
that, or trash the packet, adding a rather cryptic bounce message. The
exact wording and protocol will have to be established first, and only
known to people who use the DH.

> 12: Would integrating DigiDollars with a DH be a good idea?  (For
Positively not.

> I apologize for the length of this post, but there are a lot of questions
> and problems in making a stable, usable data haven.
Glad you asked. I'm not hardly a guru, but there's my $.02.

                                        --Jeff
--
======  ======    +----------------jgostin@eternal.pha.pa.us----------------+
  ==    ==        | The new, improved, environmentally safe, bigger, better,|
  ==    ==  -=    | faster, hypo-allergenic, AND politically correct .sig.  |
====    ======    | Now with a new fresh lemon scent!                       |
PGP Key Available +---------------------------------------------------------+