December 1992 - cypherpunks-legacy

1993 RSA Data Security Conference
by Richard Childers 24 Dec '92

24 Dec '92

( I'm sitting here, waiting for Sequent to call back after a late-night systems crash ... may as well put the time to some good use ... )-: Looking for computer & communications products that have real public-key security built in ... maybe interested in enhancing your _own_ products with encryption and authentication technologies ... or just want to know what all the excitement is about ? RSA invites end users, developers and OEMs to attend the 1993 RSA Data Security Conference The only conference and expo devoted exclusively to public-key cryptography. Talk to colleagues, developers, potential customers and experts from the best and the brightest companies in the security business. Get the real story on licensing, standards, algorithm strength, and export restrictions. See the newest public-key products from the biggest vendors in the computer industry. Attend tutorials on secure application design and developing with RSA's cryptography toolkits, such as TIPEM and the new BSAFE 2.0. Find out how others in your line of business are using RSA technology to differentiate their products and improve their own internal security. The conference is being underwritten by RSA Data Security, Inc., and is free to all attendees and exhibitors. Interested ? Registration is extremely limited, and is first-come, first-served. Call RSA today and reserve your seat. 415/595-8782, ask for Conference Registration. Thursday January 14th : Conference Friday January 15th : Tutorials & Exposition Redwood Shores, California -- richard ===== -- richard childers rchilder(a)us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration "If Life is a drama, then, surely, the hardest parts go to the most skillful."

1 0

Re: Signing text messages...
by Doctor Zaphod 24 Dec '92

24 Dec '92

In Message Wed, 23 Dec 92 13:18:54 PST, uunet.uu.net!ghsvax!hal(a)netcomsv.netcom.com (Hal Finney) writes: >Or are you suggesting that someone else could create a bogus public >key claiming to mine, re-sign the message using that public key, and >then get people to think it was from me? Perhaps they could alter the message, use a bogus public key, and re-sign the message. >But no, I wouldn't, because people would (or should) know not to trust >a random public key to be from whom it claims. My posted key is >signed by Phil Zimmermann. This doesn't absolutely prove it is from >me, but I think it makes it worthwhile to post the key. I didn't realize you had included a signed key. Minus one point for research. Yes, people SHOULD know not to use a publicly posted key. But do they? >Anyway, the real reason I posted the key in this case was so that >people could check the cleartext signature to see if it had been >mangled by various mail gateways. That was the topic of discussion in >the message, so I wanted to make it easy for people to try checking >the signature. Then posting your public key was clearly the right thing to do. I have noticed; however, that people have posted their public key along with a signed message before [there was a discussion on mangled, signed plaintext] and thought I would mention this to anybody who thought they were using infallible methods or authentication. I must urge everybody not to accept any key from a source other then person to person [or using a fone call to exchange MD5 hashes] unless it is signed by smoebody you HAVE exchanged keys with in this way. I hope nobody sees a message with a public key attached to it and says, "Oh! There's a key I can add to my keyring", and abandons the entire key-exchange method. TTFN! nobody saw DrZaphod [AC/DC] / [DnA][HP] [drzaphod(a)ncselxsi.uucp] Technicolorized

1 0

Forwarded article.
by Russell Earl Whitaker 24 Dec '92

24 Dec '92

This article was forwarded to you by whitaker(a)demon.co.uk (Russell Earl Whitaker): --------------------------------- cut here ----------------------------- Newsgroups: demon.security From: twillis(a)pintu.demon.co.uk (Tom Willis) Path: eternity.demon.co.uk!demon!pintu.demon.co.uk!twillis Subject: Attempt at a signing policy Distribution: world Organization: DGA Ltd X-Mailer: Simple NEWS 1.90 (ka9q DIS 1.19) Lines: 122 Date: Tue, 15 Dec 1992 23:46:16 +0000 Message-ID: <724463176snz(a)pintu.demon.co.uk> Sender: usenet(a)demon.co.uk I would welcome any comments on the following, as a signing policy. What do you think? -----BEGIN PGP SIGNED MESSAGE----- This is my policy for signing keys ================================== (dated 12th December, 1992 1992-12-12) - --Type bits/keyID Date User ID - --pub 1024/6AD0D1 1992/10/24 Tom Willis <twillis(a)pintu.demon.co.uk> - -- Key fingerprint = 04 D7 B9 24 50 BE B2 30 BD 23 1A 98 B5 01 F1 46 - -- Tom Willis <GBR55N55@IBMMAIL> - -- Tom Willis - -- </G=WilliTL/S=Willis/PRMD=IBMMAIL/ADMD=IBMX400/C=GB/> - -- Tom Willis <100042.446(a)Compuserve.com> - -- Tom Willis - -- </CN=Tom Willis/OU=HQ/O=DGA+C=GB/@DGA@Notes> Introduction - ------------ It is my intention that you should be able to trust my signature on any key that you see. However, what you mean by trust and what I mean by it may differ. In overview, I will only sign keys that I have received directly from an individual that claims to own the key, and that I am confident does so. My confidence is based upon the policy I maintain for signing keys. Policy - ------ 1. I will only sign a key that I have received physically during a face-to-face meeting with the person claiming to own the key. 2. I will only sign a key once the claimed key-owner has proved to me that they possess the secret key corresponding to the public key that they have given me. 3. I will only sign a key/ID pair that I believe identifies the person claiming to own the key. 4. I do not claim to have verified that the name the person is using is actually their own legal name; I accept reasonable aliases/handles but require that I am confident that the person regularly uses the name given in public. 5. I do not claim to know that the key owner is trustworthy in signing keys, and is not an agent provocateur. The obvious ones: 6. I will not allow my secret key and password to fall into anyone else's hands. 7. If I find that my secret key has been compromised, I shall do my best to distribute a compromise certificate to anyone who has received a key with my signature. Notes on Policy - --------------- 1. I will accept keys presented on paper or electronically (e.g. on diskette), but the key must have been handed over during a personal meeting with the (claimed) key-owner. 2. To satisfy me that the claimed owner actually *does* possess the secret key, they must return to me a sequence of bytes (chosen by me) signed with their secret key and encrypted with my public key. For example, if I meet someone I do not know well, and we exchange keys, I will not sign their key until I have sent them a sequence of text bytes (e.g. an item in radix-64 form signed by my key), and they have returned the same item to me in a message that is signed and encrypted, and I have checked that my original `challenge' and the returned response are *identical*, and that the message signature agrees with their public key that I posssess. (Otherwise, the physical exchange could well prove nothing about the person involved except they possess the public key of the person they are claiming to be.) 3. My signature says that the key and the associated ID that I sign belong together, so far as I can tell. In order not to mislead you, I won't sign key/ID pairs that look wrong to me. For example, I wouldn't sign even my own father's key, if the ID said something like `President of the United States of America'; because he ain't (and I *know* that!). If my father's key also had a (secondary) ID on it that gave his name as I know it, I *would* sign that association, even if another ID is clearly garbage. 4. I would cheerfully sign a key/ID pair, even if I *knew* that the ID was not the real ID of the owner, if it is a reasonable ID. For example, if my Mother had a stage name, I would certainly sign her key with that ID; I would also sign her key with her maiden name. I wouldn't sign her key/ID where the ID wasn't one I had ever heard her use, though. Not even my Mother, much as I trust her otherwise! 5. My best friend, known since childhood, may be a gonzo when dealing with security; I have no objection to signing his key, but you should not assume that says anything about whether or not I would trust *his* signature myself! (It's OK, mate, just joking, I trust you *really*...) -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKyqRM6soIBpyatDRAQH96AP/RMa0+MENYZ2EZTHZFiS04mgA40A0ncL5 rpuRePDrhBjAqxN/K5xX9rWWKgxiQgo3OvsY93tjFUZ1mn4ESUEscf57rnXE26cL B/jEz+Kn4P4en8107ydl5VvZkkqMj3f3Vyfkuu5YN6KX2NIbpVzQgKSrV4Ah8vob F0GKx8DdsOs= =O2fB -----END PGP SIGNATURE----- -- Tom \/\/illis | 1. twillis(a)pintu.demon.co.uk | Have PGP 2.0 key DGA Ltd | 2. GBR55N55@IBMMAIL | ... will swap LONDON UK | 3. 100042.446(a)Compuserve.com | --------------------------------- cut here -----------------------------

1 0

Re: Signing ascii text
by wcs＠anchor.ho.att.com 24 Dec '92

24 Dec '92

The problem with signing whitespace-compressed canonicalized text isn't the loss of readability, since you can send the non-canonicalized version for humans. The problem is that sometimes the white space IS significant Project-Schedule 1992 1993 1994 Phase 1 X Phase 2 X Phase 3 X would acquire the same signature if you moved the Xs to different columns. If we're going to treat white space in text as significant, we made need to adopt a scheme such as MIME's =xx content-transfer-ncodings; Otherwise we need to declare by fiat that white space is not significant unless protected by an encoding. Bill Stewart

1 0

Interview with Tim May on WFMU
by dmandl＠shearson.com 24 Dec '92

24 Dec '92

For interested cypherpunks (or anyone else) in the NYC area, I'm going to be interviewing Tim May on my radio show this Saturday. The show's on WFMU (East Orange, NJ), 91.1 FM, from noon-3:00. Tim'll be on starting at 2 PM. --Dave.

1 0

Re: Signing ascii text
by John W Noerenberg 24 Dec '92

24 Dec '92

At 11:31 PM 12/22/92 -0400, Yanek Martinson wrote: >> (e.g., email messages, etc). Is there a convention for the end of line >> sequence that is to be used for the copy of the file that is run through >> the hash function? If there isn't, then the file hash will depend on the > >Canonical Text has a CR and LF at the end of each line. This is >documented in some RFC. All (most?) protocols used on internet such >as smtp, finger, etc, use this format. The possible justification >is that an extra linefeed or a carriage return is not as bad as a missing >one. Which RFC are you referring to? While it is true that 821, 822 (and other RFC's which are concerned with email messages) define the end of line as a CRLF, I'm not aware of an RFC which defines canonical text. The style of late has been to define a line "as described in rfc822" or some such. But I don't recall any rfc which defines canonical text spanning session-layer (or higher) protocols. Is there one? john noerenberg jwn2(a)qualcomm.com noerenberg.j (Applelink) =========================================================== Do not uselessly lament your luck that is giving way, your work that has failed, your life's plans that have all ended in despair. Like a man long prepared, like a man of courage, bid her farewell, the Alexandria that leaves you. -- "The God Abandons Anthony", Constantine Peter Cavafy [1911] ===========================================================

2 1

Re: Signing text messages...
by ghsvax!hal＠uunet.UU.NET 24 Dec '92

24 Dec '92

Dr. Zaphod writes: > By including your public key WITH your signed messages, aren't you inviting > people to intercept it, replace it with they're own public key, and re-sign > the message? If I didn't have a trusted copy of your public key already I > wouldn't be able to verify your signature. I'm not sure what attack you are proposing here. Are you suggesting that someone else could take credit for my (brilliant?) message by removing the PGP signature and substituting one of their own? But digital signatures can't stop other people from doing this. Or are you suggesting that someone else could create a bogus public key claiming to mine, re-sign the message using that public key, and then get people to think it was from me? Or, worse, they could create a whole new message saying "I am a turkey, signed Hal Finney", sign it with this bogus "Hal Finney" public key, and post it. Then I'd really have egg on my face, right? But no, I wouldn't, because people would (or should) know not to trust a random public key to be from whom it claims. My posted key is signed by Phil Zimmermann. This doesn't absolutely prove it is from me, but I think it makes it worthwhile to post the key. Anyway, the real reason I posted the key in this case was so that people could check the cleartext signature to see if it had been mangled by various mail gateways. That was the topic of discussion in the message, so I wanted to make it easy for people to try checking the signature. Hal 74076.1041(a)compuserve.com

1 0

Remailers
by edgar＠spectrx.Saigon.COM 24 Dec '92

24 Dec '92

I'd like to thank Eric Hughes and Mike Sherwood (who wrote privately) and Hal Finney (who responded here) to my requests for enhancements to Eric's remailer code. By the way, Hal, your signature did not match the associated plaintext: WARNING: Bad signature, doesn't match file contents! Bad signature from user "Hal Finney <74076.1041(a)compuserve.com>". Signature made 1992/12/19 21:43 GMT This is likely due to some trailing blanks in your plaintext. I've written to Branko to try to get PGP to remove trailing blanks if -t is active. First, I'm glad Eric agrees that anonymous posting to newsgroups is a good idea and is on his "to do" list. Until then, thanks to Hal for posting the info about the ucbvax gateway. I had that info at one time, before hearing about remailers, but discarded it since I thought I'd never use it. I'm sorry Eric doesn't agree that stripping the .sig is a good idea. I respectfully dissent. I've found that I can probably disable my own automatic .sig, so I suppose this isn't too urgent. Nevertheless, I would think it desirable to make remailers as easy to use as posible. Having to remember to disable the automatic .sig is certainly an inconvenience. Forgetting to do so could potentially be very embarrassing or even incriminating!! The pax remailer uses "--" or "__" as sig delimiters (according to their docs) & apparently this is satisfactory. I think this means that "----" would NOT be a delimiter, so it would be unlikely to be used by mistake. I wouldn't mind a more explicit delimiter, for example ::--Remailer cut HERE-- if Eric thinks "--" is too ambiguous or is likely to be used inadvertantly in the middle of a msg. Anyway I guess I can muddle through for the time being. I agree with Hal that the pax remailer can probably be the first in a chain to Eric remailers. Probably also the last in a chain of Anonymous returns. But I don't see how pax could be used in the middle of a chain. I would encourage Eric to correspond with the guy running the pax remailer: anon.admin(a)pax.tpa.com.au (a human) to see if you couldn't come up with a common remailer code with best features of both. Certainly it would be great to have an Eric-style remailer running in Australia!! -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

2 1

Re: Signing ascii text
by mark＠coombs.anu.edu.au 24 Dec '92

24 Dec '92

>Date: Wed, 23 Dec 92 11:02:31 PST >From: Eric Messick <eric(a)parallax.com> >It would canonicalize a file by >turning all sequences of white space into a single space and trimming >leading and trailing whitespace from the file before computing the >hash. If the message contained a table of figures formatted and seperated with spaces then that method would destroy the readability of the table. If the file was processed to change tabs to spaces, according to your .exrc settings, then the message would be cleared of any ambiguities from differing lengths of tabs. This is assuming none of the forwarding mail systems between parties replaces a sequence of spaces with a single tab. I personally havent seen such behaviour, nor would I expect it. It makes too many (bad) assumptions. Trailing spaces should of course be nulled as they serve little purpose. Mark mark(a)coombs.anu.edu.au

1 0

Re: Signing ascii text
by Eric Messick 24 Dec '92

24 Dec '92

I would like to argue for a weaker ascii text signature function in PGP in addition to the current one. It would canonicalize a file by turning all sequences of white space into a single space and trimming leading and trailing whitespace from the file before computing the hash. This clearly involves some major changes to the file, allowing many files to hash to the same value, but a human would presumably consider all of those files to have the same information content. The only case that I can think of where the information content of the message could be changed with the signature remaining valid is if information was contained in the pattern of whitespace in the file. This should make the signature robust to most of the changes that a mailer could make. I would not advocate extending this to any non-whitespace characters. -- eric messick eric(a)toad.com

1 0