- cypherpunks-legacy@lists.ogf.org

re: Keystone
by Tom.Jennings＠f111.n125.z1.FIDONET.ORG 22 Oct '92

22 Oct '92

re: PGP interface to email. I've completed my "RM" program. The PGP interface is single-keystroke, and includes optional pass-phrase management. I've released it with source under the copyleft agreement. It can be downloaded or filerequested from me if anyone's interested. (MSDOS and .MSG format only) --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings(a)f111.n125.z1.FIDONET.ORG

1 0

Keystone
by Eric Hughes 22 Oct '92

22 Oct '92

Re: adding D-H key exchange to PC software gnu(a)cygnus.com writes: >Given a working Unix implementation, it would be relatively easy to >add to the terminal program, if source code for any decent terminal >programs was available. But source code is not available. The trouble is that all the decent terminal programs for PC's are shareware or commercial (or were originally shareware and have become commercial). I too would like to know of any source-available PC terminal programs, but I suspect there are none because of the prevailing shareware culture. Re: getting an author to license D-H key exchange The reason this will not happen is not the bootstrapping problem (chicken/egg), but that there is no perceived value to an encrypted link. The sysop is already has access to everything on the dedicated machine and may even have a policy of scanning all messages. External hackers can't really get in because shell access isn't really done remotely. The only ones you are protecting against are people with a hard tap on the phone line itself. For most people, this is not a concern. Since there's no perceived value and since all the software would require license from RSADSI, it won't happen that way. Re: using a protocol layer avalon(a)coombs.anu.edu.au writes: >Rather than rewrite the terminal progs, why not rewrite the BIOS level >drivers and such ? (if its possible). That's not possible either. Most terminal programs write directly to the hardware. This is single-tasking, standardized hardware, remember, and the original BIOS interface for the serial port was totally unusable. Some communications programs use FOSSIL drivers, but many (if not most) terminal programs don't support it. (FOSSIL is a BIOS-level serial port interface description which could hooked into or rewritten to support a protocol.) Look, I wish all this stuff were in use. Everyone should encrypt all their communications links as a matter of policy. (That includes voice, and if you thought the PC terminal program bootstrapping was difficult ...) Let's move incrementally, though. If we can get people to at least encrypt all of their e-mail, that will be an excellent start. One incentive would be for the BBS operators to phase in a policy that they will accept no e-mail which is _not_ encrypted. Comments? Eric

1 0

Re: Keystone
by fnordbox!loydb＠cs.utexas.edu 22 Oct '92

22 Oct '92

:But the user interface problem can be solved. Just make a bunch of :.com files which do nothing but spawn pgp by invoking the correct :arguments. Very simple; a few lines of C is all. Even the PGPPATH :can be set before the spawn. It's an easy encapsulation. It will run :a bit slower for load time, but not appreciably. And you won't have :to recompile PGP from the distributed executables. That's a real good idea. I shoulda thunk of it myself. :-) Loyd *************************************************************************** * loydb(a)fnordbox.UUCP Once you pull the pin, * Loyd Blankenship * * GEnie: SJGAMES Mr. Grenade is no longer * PO Box 18957 * * Compu$erve: [73407,515] your friend! * Austin, TX 78760 * * cs.utexas.edu!dogface!fnordbox!loydb * 512/447-7866 * ***************************************************************************

1 0

terminal progs to do pgp...
by avalon＠coombs.anu.edu.au 22 Oct '92

22 Oct '92

Rather than rewrite the terminal progs, why not rewrite the BIOS level drivers and such ? (if its possible). At least this way, it would be one hack which would work on all terminal programs...you'd just need a way to turn it on/off which I'm sure wouldn't be that hard :-) cheers, darren

1 0

"Cypherpunks write code"
by whitaker＠eternity.demon.co.uk 22 Oct '92

22 Oct '92

Eric Hughes writes: > > Cypherpunks write code. > > This will mean someone who knows Procomm, Crosstalk, Qmodem, Telix, > etc. for the PC, someone who knows the various Mac, Amiga, Atari, and > other machines. This will mean someone to write nice pretty visual > interfaces for PGP to put all the PGP options on menus where they are > all visible. This will mean people to think about BBS/terminal > protocols. This will mean lots of individual contributions, no single > of which need be large, but whose sum will be. > > Eric > Count me in on the Procomm scripting. I *may* do something for Telix, too. Who knows? I may sell the scripts/interfaces on AMiX. ;-) Russell Earl Whitaker whitaker(a)eternity.demon.co.uk Communications Editor 71750.2413(a)compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available =======================

1 0

Put me on your mailing list!
by Campbell James A 21 Oct '92

21 Oct '92

Hey, I'd like to be on the mailing list for CYPHERPUNKS. My address is: ujacampbe(a)memstvx1.memst.edu If you need this too, here's my PGP 2.0 public key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirkL4AAAAEEANAomYnlPXopnms9RtU0ln9CiLJljssOeflC9A+QIDujXhPT yApbL6VPqSUSoFF/e72xTJixyrwBQhw5lAvfvQPEiGIFQQYxviF+Qg/+6/JVvLCj vnGVFl9kKTEYVeONxBNGiaXuSE0VMQLx47iP9AU+wYw62aXmTNtW1BUtX5BHAAUR tDBKYW1lcyBBLiBDYW1wYmVsbCA8dWphY2FtcGJlQG1lbXN0dngxLm1lbXN0LmVk dT4= =0rCj -----END PGP PUBLIC KEY BLOCK----- Thanks! James A. Campbell Memphis State University Memphis, Tennessee

1 0

TEMPEST, Eavesdropping
by Eric Hughes 21 Oct '92

21 Oct '92

>Their chief concern doesn't seem to be folks like us, but rather >concerns about vans parking outside high tech and defense contractors >and slurping up what they can [...] When banks start signing with private keys, then we get an even more interesting monitoring problem. >And someone asked about building Faraday cages. Don't even try! Sometimes it is cheaper to build a whole building to be tempest-spec than to buy all tempest-spec electronics. What I have heard about such stuff is solid copper walls and no windows. No exacly your classical Faraday cage; more like your classical Gaussian surface. :-> TEMPEST is an acronym. I don't remember for what. Eric

2 1

fast elliptical encryption
by Karl L. Barrus 21 Oct '92

21 Oct '92

In the winter NeXTWorld magazine, the article ("Tales from the Crypt") on page 94 mentions various topics of interest: public key encryption, export restrictions, the role of the NSA, etc. (It's just a one page article and doesn't go into much depth). Anyway, NeXTStep 3.0 is bundled with fast elliptical encryption for NeXTMail. As a result, 3.0 is export restricted. Does anybody know about the "fast elliptical encryption" public-key system? How different is it from good ol' RSA? Is it related to the elliptic-curve factoring algorithm (am I remembering this correctly - I don't know how elliptic curve factoring works, but I remember seeing a reference to it somewhere)? Just curious... /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

1 0

the acronym TEMPEST
by Karl L. Barrus 21 Oct '92

21 Oct '92

> TEMPEST is an acronym. I don't remember for what. > Eric TEMPEST = Transient ElectronMagnetic Pulse Emission STandard. Pretty cool sounding acronym :-) /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

1 0

another service
by Eric Hollander 21 Oct '92

21 Oct '92

I have thought of another service, like the depository, which might be useful to the user community: a time stamping notary service. This would have less security problems than the depository and would also be neccessary if RSA'ed documents are to replace contracts and other paper documents used in business. It would be easy to implement. A machine is set up with a hardware random number generator. This is used to generate a time-stamp key pair, perhaps every day or every hour. A user sends a document to this computer, which then signs it with the private half of the time-stamp key and then remails it to the user. Note that the document sent by the user is probably already encrypted and/or signed; sending it to the time-stamper does not compromise it in any way. The time stamper also keeps publishing the public half of its keys, to a wide enough audience that it would be impossible for any one person (or Agency) to modify all of them. Users could keep their own archives of them. After the time period has elapsed, the time-stamper should erase the private key corresponding to the time period. This is the only time that trust is involved and that the system might be compromised. If a private key were leaked, a time-stamp could be forged. This would allow users to keep dated, notarized documents in their files, so they could later prove that they had certain information at a certain time. Ideas? Thoughts? e

4 3