- cypherpunks-legacy@lists.ogf.org

EMI shielding
by karn＠qualcomm.com 07 Apr '93

07 Apr '93

Apropos the recent discussion about TEMPEST shielding, there's an interesting product that might prove quite useful: CAPCON EMI suppressant tubing. A colleague got a shipment of it today. It's ordinary black rubber tubing that has been loaded with iron oxide. It comes in 26 sizes from .04" ID to 1.25" ID, and is claimed to have much better attenuation than ferrite beads, especially at UHF and microwave frequencies. You can shield entire cable lengths with it, or you can apply it in short segments (1" to 1') just like ferrite beads and get plenty of attenuation for less cost and weight (this stuff is *heavy*, and the 1/2" stuff cost several dollars per foot.) It's also available as sheeting in various thicknesses for lining cabinets, etc. I got the bright idea to test the absorptivity claims for this stuff by putting an 8" piece into a microwave oven. After 10 seconds, it was too hot to handle. I'd say it's doing just what it's supposed to do. Contact info: Capcon, Inc 147 W 25th St New York, NY 10001 212-243-6275 212-645-0185 (fax) Phil

1 0

Re: Real-time BBS Encryption??
by J. Michael Diehl 07 Apr '93

07 Apr '93

> Re: encrypting modem links > >I'm wondering if there is a way to do this with PCs? > Yes, with difficulty, and not transparently. > > >Is there a way to encrypt a remote users entire connection with > >the BBS, so that they would have to have a special term program to access > >the system? > > For PC's, replacing the terminal software is really the best way. > There is no effective abstraction of serial port hardware in the PC > world. The int 0x14 driver in the BIOS was rampantly defective, and > MSDOS does not provide a standard interface. Or, we could impliment an "external protocal" like zmodem. This would simply take keystrokes, buffer them, then encrypt/decrypt them. Make the source portable, and obtainable.

2 1

WB: public kiosks
by Karl Barrus 07 Apr '93

07 Apr '93

On the importance of anonymity (in regards to the whistleblower project): Last week, the Houston Chronicle ran two or three articles on how ill run the Nuclear Regulatory Commission is. Specifically, the article described how one or two people had their careers absolutely ruined by raising safety concerns at nuclear plants. In each case, the employees involved were terminated shortly after citing safety hazards (such as spills left uncleaned on table tops, etc.) Someone quoted in the article stated this behavior undoubtedly scares off other potential informers. Plus, I read an article in the Chronicle about how a NASA employee was fired for his political beliefs. Well, it is more complicated: the employee actively participated in some usenet group (talk.politics.china?), and had a store of back articles on his computer at work, which his superiors discovered. Shortly thereafter, he lost his job. I've been busy of late and could kick myself for not saving these papers, because real world incidents such as these strengthen our arguments for privacy and anonymity. Some people have such an irritating tendency to assume irresponsibility and abuse when a freedom becomes available - just read news.admin.policy. /-----------------------------------\ | Karl L. Barrus | | elee9sf(a)menudo.uh.edu | <- preferred address | barrus(a)tree.egr.uh.edu (NeXTMail) | \-----------------------------------/

1 0

Re: Real-time BBS Encryption??
by karn＠qualcomm.com 07 Apr '93

07 Apr '93

Actually, I think a much more powerful solution is to run TCP/IP over the serial link and to encrypt individual IP datagrams. This is the charter of the IETF "ip-security" working group, and there is already a prototype implementation of one approach working. Phil

1 0

Re: Real-time BBS Encryption??
by mark＠coombs.anu.edu.au 07 Apr '93

07 Apr '93

>What about a streams module that does encryption? Of course, it'd >require people to run a real OS instead of dos/system... You might want to look at the link.tar.Z program newsham(a)wiliki.eng.hawaii.edu wrote. THe server is currently unix based but it should be transportable. It uses pgp to swap des session key and happily talks away. There are still some bugs and when he has the time they will be taken care of. The client is written for an amiga at the moment, I havent had the opportunity to do the ibm port yet. Contact him at the above address. He is busy with studies but you might get some joy from emailing him. Hope this helps Mark mark(a)coombs.anu.edu.au

1 0

PGP: suggestions from the trench
by grady＠netcom.com 07 Apr '93

07 Apr '93

After carefully reading RSA.COM's FAQ (version 1.0 draft 1e [14 Sep 1992] by Paul Fahn; available via anonymous ftp from RSA.COM) I have some comments about the various PGP implementations. First of all: well done! These implementations and ports have taken a lot of unremunerated work from a lot of people. If you compare the number of people registering public keys on the PGP servers such as pgp-public-keys(a)toxicwaste.mit.edu to the number registering for the RIPEM versions licensed by RSA/PK partners, for example, found on rpub.cl.msu.edu, PGP enjoys an order of magnitude more popularity. So regardless of the outcome of legal, support, standards and interoperability issues, the PGP experiment has already been a tremendous success in letting us common folk learn about effective and convenient public key encryption. One of the great advantages of a popular application is the great number of fingers and eyes that can be used to detect and document problems to make PGP even a greater success. Here are the thoughts of one user: 1. PGP RSA bit lengths are too short. According to RSA's FAQ, the US Government (NSA) does not consider export licenses for RSA moduli used for privacy greater than 512 bits [section 2.23]. This may imply something about NSA's capability in attacking RSA systems with fewer than 512 bits of modulus; Ron Rivest, a co- inventor of RSA, estimates the cost of factoring a 512-bit modulus *today* at $8.2 million dollars (much less of course in the future) [section 2.8]. Although it is true that the time to generate a new RSA key goes as the order of 16 times the modulus length, this is only done once or a very few times. Encryption and signature verification time on the other hand goes only as the order of four time the modulus length [section 2.8]. And the faster computers of tomorrow will virtually eliminate this performance penalty compared to the vastly increased time required for a factoring attack on RSA moduli that increasing its size entails. Taking all these factors into consideration, I would suggest that the *minimum* size of the RSA modulus available for PGP is 1024 bits with a minimum ceiling of 2048 bits (or even more). If for performance reasons on certain platforms 1024 is deemed impossibly slow, then a lesser number of bits ought to be permitted *provided* that the security level for any key length under, say, 768 bits is clearly labeled "TOY GRADE". And because factoring security is a moving target with increases in computer speed and factoring methods, rather than the static (and rather melodramatic) labels of "commercial grade," military grade", and so on, the labels ought to be specific years that intelligent estimates (such as Ron Rivest's) that that size modulus will be factored by a determined opponent. For example, 512 bits should be labeled "1992", 768 bits labeled "2005", 1024 bits labeled "2020", and so on, using an estimate of about 15-20 bits a year of modulus degradation. This also supplies a clue as to selecting intelligent public key expirations given individual security goals. While this may seem too conservative, consider that many public moduli kept by a certifying authority may be attacked in parallel, similar to cracking a passwd file NOT using a salt. We must be *absolutely sure* that the theoretical basis of the encryption function is the paramount consideration in PGP. 2. The hash function generates too short a digest. In section 6.3 of the RSA FAQ, RSA recommends MD5 with its 128 bit digest when using 512 bit or shorter RSA keys. This is because they estimate the work factor of breaking a 128 bit digest is on the order of 2^64 operations or roughly equivalent today to factoring 512 bit numbers. If PGP increases the minimum recommended modulus size but does not simultaneously increase the hash digest size, then attacks such as "guessed plaintext," where guesses are made as to the IDEA key being encrypted under RSA are made compared to a trial RSA encryption, will become more and more attractive. The RSA FAQ recommends using the SHS (Secure Hash Standard) [available from csrc.nist.gov] which generates a 160 bit digest or a modified MD4 algorithm that produces a 256 bit digest. In any event, the 128 bit IDEA key to be encrypted under RSA ought to at the very least have a 64 or 128 bit random salt (that will later be discarded) appended before RSA encryption to thwart the "guessed plaintext" attack on RSA. According to the RSA FAQ, MD4 and MD5 are available for unrestricted use via RSA.COM or ftp.nisc.sri.com as rfc1320 (MD4) and rfc1321 (MD5). 3. Triply encrypted DES with CBC ought to be another "conventional encryption" option under PGP menus. RSA FAQ cites Campbell and Wiener's "Proof that DES is not a group" (Advances in Cryptology - Crypto '92 Springer-Verlag, New York 1993, To appear) that proves that DES with multiple encryption does indeed spread the encryption mapping over a broader space and thus presumably increases the work factor to direct cryptanalysis. IDEA, while attractive in speed, size and theory, has no such group-free proof and has not long withstood the public scrutiny that DES has endured. Three 56 bit keys could easily be derived from a single MD4 256 bit digest (with an additional 64 bits of Initializing Vector, to boot) to double the brute-force key guessing DES work factor to roughly 112 bits. A slightly non- standard version such as Outerbridge/Lau/Gillogly/Karn's newdes, which is provably at *least* as secure as plain DES, might be used in order to thwart dedicated DES hardware attacks. 4. Add a "enter random seed" option in addition to keystroke timing. It is suspected that the timing biases in keystroke timing is far more pronounced than rolls of an ordinary die, especially over the broad range of platforms that PGP has been ported to. A useful option to make user rest easier about the amount of bias in the random seeding for the search for the public-key RSA modulus and the generation of conventional (IDEA and triple-DES keys) would be to permit the direct data entry of fifty or sixty rolls of a die to further disperse the original seed. Given the difficulty of obtaining noisy diodes or sources counting radioactive decay, rolling dice is probably the easiest and comparatively least biased of ways of selecting random seeds [see Knuth v.2] *and* is under the direct personal control of the user. 5. Offer a "use strong primes" option in RSA key generation. While it is true that as it is said in the RSA FAQ [section 2.7] and the PGP documentation that "strong primes" may not now be necessary given the non-favoritism of ECM ("elliptic curve method") of factoring (Lenstra: Factoring integers with elliptic curves. Annals of Mathematics 126:649-673, 1987), there is only the one-time penalty of selecting "strong" primes in public key generation and, as the RSA FAQ suggests, future breakthroughs in factoring technique may very well once again favor the "strong" prime over the garden variety one. 6. Probably my most urgent recommendation: I use MacPGP 2.2 and it did not come with a) a source b) a digitally-signed archive or c) a pointer to send bug reports. Without these features it is very hard to make specific implementation bug reports or interface improvement suggestions. As the RSA FAQ says in section 2.6: "In practice, most successful attacks will likely be aimed at insecure implementations and at the key management stages of an RSA system." Please, please include the source to the Mac version (or upon request), or at least an object map so I can effectively disassemble and test portions of the code. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQCOAiumM0QAAAED+JPD8OULO2aXRvU2FDksMjJeGT96kGK5eJK1grkXuIHz+6pe jiedYOv72kBQoquycun191Ku4wsWVTz6ox/bpReBs5414OTPzQVJgWQzCW1N4BfV Wr4eEn3qnFsVLXXxk3oYGydIeJcmelSyuPSq/Oq7Q+eHkKgjqxDTjVMu8iEAEQEA AbABh7QuR3JhZHkgV2FyZCAgPGdyYWR5QG5ldGNvbS5jb20+ICAoNzA3KSA4MjYt NzcxNbABAw== =e3rN -----END PGP PUBLIC KEY BLOCK----- Comments appreciated. Grady Ward grady(a)netcom.com

2 1

well
by trump＠pluto.ee.cua.edu 07 Apr '93

07 Apr '93

if anyone comes up with a solution to the bbs encryption problem then get to me ... i plan on starting a Waffle based BBS that may have "sensitive" information on line in subs and in files... you all know the story... well if i could have this encryption feature i would be most happy... i have looked into this a bit but to my suprise it has comeup on the list... as for the problem of d distribution of the program the would encryp and decrypt via modem and bbs, i have that pretty much taken care of already... thanks Clovi /s ^ been bbsing for too long

1 0

April 10 meeting
by Eric Hughes 07 Apr '93

07 Apr '93

Last month at Cypherpunks West, we decided that meetings would be held monthly on the second Saturday. So, for any of you planning to be in the area any time, keep this in mind. The April meeting for Cypherpunks West will be April 10, 1993. There was some delay getting this announcement out because our normal meeting sponsor, John Gilmore, will be out of town. Mike Werner, also of Cygnus, will be sponsoring our meeting at the same location, so there's no need to change plans. Thanks, Mike! ANNOUNCEMENT Cypherpunks West April Meeting Saturday, April 10, 1993 12:00 noon - 6:00 pm PDT Cygnus Support Offices, Mt. View (directions follow) Contact Mike Werner for physicalities: mtw(a)cygnus.com, 415-903-1421. AGENDA Arthur Abraham on hash functions Mail services (works in progress) Secure phones (updates) Other stuff as announced If you have anything you want to talk about, send me mail: hughes(a)soda.berkeley.edu DIRECTIONS Cygnus Support 1937 Landings Drive Mt. View, CA 94043 +1 415 903 1400 switchboard +1 415 903 1418 John Gilmore (out of town, see note above) Take US 101 toward Mt. View. From San Francisco, it's about a 40-minute drive. Get off at the Rengstorff Ave/Amphitheatre Parkway exit. If you were heading south on 101, you curve around to the right, cross over the freeway, and get to a stoplight. If you were heading north on 101, you just come right off the exit to the stoplight. The light is the intersection of Amphitheatre and Charleston Rd. Take a right on Charleston; there's a right-turn-only lane. Follow Charleston for a short distance. You'll pass the Metaphor/Kaleida buildings on the right. At a clump of palm trees and a "Landmark Deli" sign, take a right into Landings Drive. At the end of the road, turn left into the complex with the big concrete "Landmark" sign. Follow the road past the deli til you are in front of the clock tower that rises out of one of the buildings, facing you. Enter through the doors immediately under the clock tower. They'll be open between noon and 1PM at least. (See below if you're late.) Once inside, take the stairs up, immediately to your right. At the top of the stairs, turn right past the treetops, and we'll be in 1937 on your left. The door is marked "Cygnus". If you are late and the door under the clock tower is locked, you can walk to the deli (which will be around the building on your left, as you face the door). Go through the gate in the fence to the right of the deli, and into the back lawns between the complex and the farm behind it. Walk forward and right around the buildings until you see a satellite dish in the lawn. Go up the stairs next to the dish, which are the back stairs into the Cygnus office space. We'll prop the door (or you can bang on it if we forget). Or, you can find the guard who's wandering around the complex, who knows there's a meeting happening and will let you in. They can be beeped at 965 5250, though you'll have trouble finding a phone. Don't forget to eat first, or bring food at noon! I recommend hitting the burrito place on Rengstorff (La Costen~a) at about 11:45. To get there, when you get off 101, take Rengstorff (toward the hills) rather than Amphitheatre (toward the bay). Follow it about ten blocks until the major intersection at Middlefield Road. La Costen~a is the store on your left at the corner. You can turn left into the narrow lane behind the store, which leads to a parking lot, and enter by the front door, which faces the intersection. To get to the meeting from there, just retrace your route on Rengstorff, go straight over the freeway, and turn right at the stoplight onto Charleston; see above. See you there! John Gilmore

1 0

Re: WB: public kiosks
by karn＠qualcomm.com 07 Apr '93

07 Apr '93

>Public kiosks are OK as a simple and moderately effective technique for >assuring anonymity, and they're ideal for a security-naive person who >is unable to verify the security of a more complex system. But for >my own use, I am much more confident in the security guarantee given by >encryption on a portable computer and anonymizing using Chaum-style >remailers... Indeed. By definition, a public kiosk is in a public area, with open access to all including the Bad Guy's agents and investigators. And tracking people's physical movements in public places is an art that investigators have had many years to refine and perfect. Many more than, say, factoring large RSA public keys... Phil

2 1

Re: PHRACK: Article from PHRACK 42 on encryption
by Perry E. Metzger 07 Apr '93

07 Apr '93

Douglas Mason says: > > > > >> Exposing factual errors and flaws in reasoning is left as an exercise > > >> for the reader. > > > >The flaws are big enough to drive a bakery truck through. Its trash. > > > maybe you should do a better writeup and publish it in PHRACK or 2600? > > I agree. Anyone can sit and say "Oh, that article is a piece of crap", but > these same people never put their "money where their mouth is" and write an > article of their own. > > I've written for both Phrack and 2600 and it sure as hell isn't hard to get > something submitted. If you think you can do better by all means write an > article and send it in. If trash is being published, why not try to correct > it? Because I lack an interest in doing so? Anyway, there is no need, as the PGP manual is very good and actually explains things properly. Lots of fine articles have already been written on all sorts of cryptography subjects. > If you have any problems with where to send it, I'll gladly forward you the > address. > > Otherwise, shut the hell up. Why should I? The article WAS crap. > If you don't like your goverment, vote. I'm an anarchist. You might as well say to an atheist "if you don't like Catholicism, start a schism." Perry

1 0