- cypherpunks-legacy - lists.cpunks.org

Re: Secret PGP Keys
by edgar＠spectrx.saigon.com 28 Dec '92

28 Dec '92

In response to Anton Sherwoods Dec 22 posting: Here's a lame question from a beginner who hasn't even downloaded PGP: Am I supposed to memorize my private key, lest cops beat down the door while I'm out? You would find it difficult to memorize your PGP secret key. It's 384-1024 bits assigned by PGP when it generates a key pair. There's not even any provision for manually entering your secret key. It's only useful in electronic form, on your disk. Which is not to say it may be useful to store it on a floppy at some location removed from the computer in some situations. However, PGP has added something called a "pass phrase" which you can assign to your secret key when you generate a key pair. The pass phrase is optional, but strongly advised. Since you make it up, it should be easy to memorize, so *don't* write it down or store it anywhere where unfriendly forces could find it. PGP uses the pass phrase you assign to encrypt the stored version of the secret key it generates for you. The pass phrase is therefore required (and is prompted for) before the secret key can be used to either decrypt incoming mail or sign outgoing mail. This is your defense against the cops beating down the door. They will find the (encrypted) secret key on your disk. The pass phrase is in your head and you have a right to remain silent; use it. There might be some situation where a judge could order you to give up the pass phrase: you are granted immunity from criminal prosecution (but you don't want to incriminate your friends) or in a civil discovery action. In this case, just claim to have forgotten the pass phrase in the stress of the situation. Stick to that; no-one can prove otherwise. -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

Miron's Remailer
by edgar＠spectrx.saigon.com 28 Dec '92

28 Dec '92

-----BEGIN PGP SIGNED MESSAGE----- I tried Miron Cuperman's remailer, which requires encrypted input. I noted happily that my automatic signature did not echo back, because it was not part of the encrypted text. I was going to ask how this effected ARA, but Miron has already recognized this problem and proposed a solution. Except for messages to be posted to newsgroups or sent to lists, message bodies are likely to be encrypted with the public key of the recipient. Certainly anyone sending or posting an ARA should also post an "anonymous" public key for the body of the reply. (An anonymous public key is just a key with some nom de plume in the User ID field). Another topic: signed plaintext. Miron's signed plaintext failed the signature check here. This is probably because my editor eliminates trailing blanks. Someone here pointed out that a trailing blank in a blank line may be introduced by an ASCII upload. Until PGP is fixed to eliminate trailing blanks in text, I may have another solution. The editor on this WAFFLE system has an ability to UPLOAD files using (for example) ZMODEM. I have modified the Telix SLT file I use so I have a choice of ASCII or Zmodem upload. Proof of pudding is in eating. Check the signature on this upload, which contains several blank lines. I will be checking with you when I get the echo back. -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKzi5VN4nNf3ah8DHAQH+dAP/eD8opIrO19Led9SwNDIX6LOiZqlmpOZV jX/30PJ50/1n8BlYowvDaDcPSp6R0JNggYcOg17G88MrpYHq0ODxw0w/wXd+1MHS Twhu2HUy03tJFmbOOX+kVlk2N2RFGag3063QV6SaweVMLg9DEMyPDHiSbeCTxFR7 RapDSiNV/w4= =imWV -----END PGP SIGNATURE----- -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

Re: Signing ASCII text
by edgar＠spectrx.saigon.com 28 Dec '92

28 Dec '92

I was able to verify Hal Finney's signed plaintext message posted here on Dec 23 with a good signature. Hal says he prepared the original plaintext with no trailing blanks. The editor I use removes trailing blanks whenever it saves text to disk. So there could have been trailing blanks in the plaintext I received (which would have spoiled the signature match) put there by ASCII uploading (of blank lines) or otherwise and I wouldn't know it. I can't really fault mailers that remove trailing blanks; they are trying to avoid consuming bandwidth with null information. I think the answer is a change to PGP to remove trailing blanks anytime -t is active. I have written to Branko to suggest this, but his response was somewhat lukewarm. Perhaps he would change his mind if he received the same suggestion from several individual PGP users. -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

Re: Destroying Data
by rsteiger＠denver.cba.du.edu 24 Dec '92

24 Dec '92

> Consider also the technique used in the Norton Utilities > program "Diskwipe" which takes a /g switch which "Follows > certain government rules for wiping". I can't find the manual > but I think it specifies how many repetitions are used and > different values to write in each. The Norton Utilities Wipedisk /g does three passes writing 1's and then 0's, it follows this with the hex 'FF'. This shoud pretty much remove any residual traces of the data previously held on the disk.

1 0

significance of spaces
by yanek＠novavax.nova.edu 24 Dec '92

24 Dec '92

> of view to MD5 the same, but he noted that this isn't a problem in > practice because humans don't get much information out of the presense of > multiple spaces versus one space. This is true for most text, like this message. But sometimes people send messages where spacing is VERY important: This is especially true of tables such as this one: Name Yes No Smith X Jones X Brown X Xyzzy X If the signature algorithm disregarded spaces, the X's could be moved from one column to the other without affecting the signature. I know that this information COULD have been represented as: Smith Yes Jones No Brown No Xyzzy Yes But sometimes people use the other format. Another solution is to surround all significant spaces with some other character, such as the vertical bar: |Name | Yes | No | |Smith | X | | |Jones | | X | |Brown | | X | |Xyzzy | X | | If this were done, an X could not be moved without affecting the signature even if tabs/spaces were insignificant. The point is that if whitespace is made insignificant, the users must be educated about it, and trained to use one of the two last formats instead of the first one. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek(a)novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819

1 0

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

24 Dec '92

I wrote: >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. mark(a)coombs.anu.edu.au resopnded: > If the message contained a table of figures formatted and seperated with > spaces then that method would destroy the readability of the table. The important part here is that the collapsing of whitespace would only affect the message digest, not the text as seen by the user. Two texts which read the same, but differ in whitespace, would have the same signature. If you recieved both files, you could see the difference in spacing, yet the same signature would be valid for both files. The main vulnerability is that a message whose meaning is partially encoded it its whitespace (like an ascii graphic, map, or chart) could have its meaning altered, without affecting the validity of the signature. Clearly one would not want to use this signature method on such texts. It would be a good feature for the signature algorithm to warn the user if it detects a pattern of whitespace that might convey information. I am not sure how to detect this reliably, though. -- eric messick eric(a)toad.com

3 2

Re: Signing ascii text
by pmetzger＠shearson.com 24 Dec '92

24 Dec '92

> From: mark(a)coombs.anu.edu.au (Mark) > > >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. The notion was NOT that the text would be altered in transmition, but that the signature would be computed on canonicalized text. No one was proposing hacking tabs, only that a version of the text with hacked tabs be used to compute the checksum as by hacking the tabs we will have an easy to produce canonical format. The concern Eric presented was that this would allow two files containing substantially different content from a computer's point of view to MD5 the same, but he noted that this isn't a problem in practice because humans don't get much information out of the presense of multiple spaces versus one space. Perry

1 0

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

24 Dec '92

Yipes. I got a whole bunch of (advance) requests for tapes of the interview, so I'm posting this to the group to make things a bit easier for myself... I'll be more than happy to send copies to anyone for the cost of postage and the blank tape. I'll also be sending a copy to Tim, so if it's easier, you can try to get him to dupe it for you. Of course, being a worrywart, I'll hold off until Monday to confirm that the thing went off without a hitch. I'll post to the group then and let you know. --Dave.

1 0

holiday travel: sign some keys!
by Marc Horowitz 24 Dec '92

24 Dec '92

With the holidays coming up, and many of us traveling to see friends and relatives, we all have a great chance to sign keys of people who aren't in our normal circle of contact. In our web of trust, we need as many long strands as we can get. I recommend that all of you write down your MD5 hashes, and, if you are willing, post your general itinerary if you are traveling so people can get in touch with you, and your key signing policy. It only takes a five minute meeting (unless there's good chinese food conveniently nearby :-) to exchange hashes, then you can email your keyring once you get back home. I'll start. I'll be visiting friends in the Alexandria, VA area saturday and sunday (12/19-12/20), but I won't be reachable via phone easily so if you'll be in that area during that time, email me before noon saturday with contact information. From sunday 12/20 to wednesday 12/23 (I may stay later), I'll be in northern New Jersey (Wayne, to be exact) at my parents' house, phone 201-694-3152. I only sign keys I can verify out-of-band, either in person or by phone with someone I know. So far, all the keys I've signed are people I've known for awhile and see often, so it was easy. I guess I'll make up a new rule: show me a driver's license and another piece of ID (sort of like what you need to cash a check), and I'll trust that you're you. The harder to fake the better; I suppose passports rank high on that list. Maybe I'm crazy for posting all this info saying when I'm going to be out of town, but I think it's worth it in the interest of getting some more connections established (and I've been accused of being crazy many times before, anyway). Marc

3 2

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