From: "Attila T. Hun" <attila@hun.org>
Date: Tue, 14 Oct 1997 06:11:55 +0800
To: Tim May <cypherpunks@cyberpass.net>
Subject: Re: D-H Forward Secrecy for E-Mail?
In-Reply-To: <v03102801b066b3b308e0@[207.167.93.63]>
Message-ID: <19971013.173323.attila@hun.org>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

    great idea, Tim. [total previous text follows my comments]

    paraphrase of Tim's basic suggestion:

        ...to consider DH session keying in real time or the latency of 
        maybe IRC, etc (several seconds?) to be able to dispose of the 
        session keys which makes subpoenas signifantly more difficult.

    Netscape's default mail setting is to handshake the destination
    server.  eg through sendmail. it will not return until it gets it
    or times out --then it tells you to try later and there is no
    way to file it easily --in other words, a problem to avoid.

    I am presuming the DH keys would be a wrapper on an already 
    encrypted message, although target machine can re-encrypt to
    recipient on a secure machine.

    1)  sendmail could be modified to do yet another function (essentially 
        describe in b); or,

    2)  I would prefer to run yet another daemon on every machine at a 
        specific port with the usual 'who are you' identify sequences, 
        preferably even changing it to call back to lesson spoofing, 
        despite the fact additional logic is required to kill denial of 
        service attacks.

        all that would be required would be the n number months/years
        wait for IETF to agree on a port and the protocol...

        the rest of it is pretty stock at the daemon side. the inside
        is where the fun begins.  If the message is already encrypted,
        (was inside DH wrapper) it can be delivered; otherwise:

        a)  if the machine is secure, the email can be delivered to the
            user's box

        b)  if the machine is the usual, then the daemon needs to use
            a local secret key to encode to the local user's public
            key to maintain an encrypted message.

    complicated? not from my perspective v. some of the other nightmares.

    using sendmail would be the fastest route to enablement, but it 
    probably would be years before sendmails were updated and aan old
    sendmail could just accept the call and hang one or the other without
    a resolution.

    the more we are wired, the more feasible it becomes.

    it would be nice if the usual store and forward of sendmail could
    be utilized. I think it would be very difficult to use sendmail itself,
    but it should be possible to use an independent daemon to perform
    the same function.  there would just be multiple DH sessions --much 
    like the cp remailer network; the few times I used mixmaster a few
    years ago, I sent an encrypted packet.
 ______________________________________________________________________
 "attila" 1024/C20B6905/23 D0 FA 7F 6A 8F 60 66 BC AF AE 56 98 C0 D7 B0 

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
Comment: No safety this side of the grave. Never was; never will be

iQCVAwUBNEJmJL04kQrCC2kFAQFyPQQAmDaB819149GNqJF1SZqhs2rxCAHADnlx
fMBgmBOhJi/bKnKafcEhMDnTWL82GtA9lpeVP5IkW9aQH8DCdQpoKbhmQ2lQZCEy
PHUpbDyVGDxOg5sCp9kDYImF0h6qVEtSDynxUVgAWiApmfCGGx5NoL4aAxDwg8gg
aOrxTePVFRw=
=xmTi
-----END PGP SIGNATURE-----


on or about 971012:1016 
    Tim May <tcmay@got.net> was purported to have 
    expostulated to perpetuate an opinion:

+At 2:48 AM -0700 10/12/97, Adam Back wrote:

+>Once you acknowledge that it is more secure to have short lived
+>communication keys (which in my view it very clearly is), it should be
+...

+Just what are some of the issues with us getting D-H-type perfect
+forward secrecy with something like e-mail? I assume this must be
+possible, of course, as D-H is used in just these ways. (The Comsec
+3DES phone I have does this, of course.) (To repeat what has already
+been said, forward secrecy means some of the important keys are not
+kept or stored, and so a subpoena at some future time to produce the
+keys used in a communication is pointless. Cf. Schneier for more.)

+First and foremost as a requirement would be the need for a
+back-and-forth communication, in a real-time or nearly real-time mode.
+This rules out conventional e-mail with its long a variable latencies
+for delivery. (Not to mention diverse clients and their inability to
+respond automatically!)

+But IRC, chat rooms, Internet telephony, etc., are all common. With
+latencies of ~seconds, or even less.

+I picture conventional e-mail being replaced, for this application,
+with this kind of system. Maybe D-H forward secrecy systems already
+exist....

+Forward secrecy might be arrangable even with long-latency links...it
+seems to me. (Through a series of links, compute and store the D-H
+parameters, then use them with conventional e-mail for the "payload"
+message?)

+--Tim May


+The Feds have shown their hand: they want a ban on domestic
+cryptography
+---------:---------:---------:---------:---------:---------:---------:----
+Timothy C. May              | Crypto Anarchy: encryption, digital
+money, ComSec 3DES:   408-728-0152 | anonymous networks, digital
+pseudonyms, zero W.A.S.T.E.: Corralitos, CA  | knowledge, reputations,
+information markets, Higher Power: 2^2,976,221   | black markets,
+collapse of governments. "National borders aren't even speed bumps on
+the information superhighway."