December 2003 - cypherpunks-legacy

Re: Problem in draft FIPS `CRYPTOGRAPHIC SERVICE CALLS'
by p.v.mcmahon.rea0803＠oasis.icl.co.uk 17 Dec '03

17 Dec '03

> Have you been following the IETF's GSS-API work? Yes - and implemented a GSS-API mechanism. The relationship between GSS-API and a general crypto interface is contentious - as the interfaces to "export" a key for a remote principal (cf ExportKey and PubExportKey in the draft FIPS) resemble the GSS-API context initiation interface (cf gss_init_sec_context in RFC 1509), but have more assumptions about the possible KM (key management) protocols than GSS-API - or at least only make explicit provision for X9.17, D-H, and RSA. GSS-API has been implemented over Kerberos, DASS, KryptoKnight, DCE1.1, SESAME, and possibly others I haven't heard of. Also, discussions for an extension of GSS-API to layer over PEM/PGP were kicked off at the last IETF to enable mail-enabled applications to be linked in to easily consume authentication and key management services. Hence GSS-API is somewhat proven to be KM-mechanism-independent. There is a potential relationship between this export/import class of interface and the IPSEC packet format (now - or soon to be? - documented), and ongoing IETF IPSEC WG discussions re KM. Specifically, it would be helpful for fast implementations (in both senses) if as much of the processing of IP security could potentially be handed off to hardware-implemented routines via common KM-mechanism-independent and algorithm-independent interfaces (which, based on the NIST proposal primitives, would be [Pub]ExportKey/[Pub]ImportKey, Encipher/Decipher, and GenerateDAC/VerifyDAC). If the right interfaces are standardised in h/w crypto, perhaps little other than negotiation and SAID handling need usually be in software. Piers

1 0

Reailers: To Log or Not to Log?
by nobody＠kaiwan.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Tim May pondered: > And even that last remailer may be able to claim ignorance (and win in > court) if he can show that what he mailed was unreadable to him, i.e., > encrypted to the recipient. (This is another reason I favor a goal of > "everyone a remailer.") The only problem I see with the "everyone a remailer" concept is that, in the presence of traffic analysis, a locally generated message will show up as an imbalance between incoming and outgoing messages, will it not? > With canonical remailers, and no logging, earlier remailers should be > safe. That brings up an interesting point -- does the very act of logging remailing activity, specifically the recording of sources and destinations of forwarded messages perhaps open the operator up to INCREASED liability? IOW, if the remailer is being used in the furtherance of a "crime", the presence of a log which records the details of such traffic might be used as an argument that the operator "should have known" that suspicious, possibly illegal, activity was going on and possibly being considerd CRIMINALLY NEGLIGENT for not stopping it. Has he/she torpedoed any possibility of a "Sgt. Schultz" ("I know nuuuuthing!") defense by gathering detailed evidence and then not acting on it? Perhaps "Don't ask, don't tell" is a better policy... Also, I suspect that if increased activity on a remailer is useful in thwarting traffic analysis, then foreswearing the keeping of logs should serve to INCREASE the throughput as users gain confidence that any "footprints" they might leave behind are promptly erased. -- Diogenes -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLkmVwORsd2rRFQ1JAQF8OAQAlQW2ft75QMkxxWR1FMBaz7ja7C+o1uuH aK4yEBfJ3uHIuzIPyfNbtat6hWF1JV8Ip1uAgVae/MSe/Eeu54uMnh9CgdtK+NW3 3LdO9qMH+4YazACh+VnFCdqJmenOxjRnqHlqcQlVrGW/oqiiWIyF3cLUPGYvsvMd SOysxBS3SDU= =u3TC -----END PGP SIGNATURE-----

2 1

MAIL: future free remailers
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Jonathon Rochkind wrote: > People often like to postulate on the list that eventually there > won't be any more of these philantropic free remailers, and people > will be charging small amounts for every remailed message, to make > some money off it. > I've thought of a pretty good reason why this might not ever happen. > [...] one's primary reason might be to ensure oneself anonymity. Interesting point... I guess that is a good reason why free anonymous remailers might not ever die out, but pay remailers may be able to offer enhanced features and services that would tend to attract the vast majority of customers (assuming such a service would be considered as valuable by enough people ;) I mean, it is easy enough to run a remailer from a school account or something like that, except you have little control: it may be forbidden (here at Rice for example), you may be told to shut it down (Netcom, U of Buffalo, U of Washington), you may have a disk quota (previous remailer I ran which stored messages, mixed and sent them at midnight) which would limit certain features, you may not be able to use "cron" or "at", you may not be able to turn off sendmail logging, you may not have the account for very long... you may want to offer usenet posting but can't, you may be subject to various denial of service attacks, you may want to name your remailer "nobody" but can't, you may want to alter sendmail config files, etc. And then maybe you'd like to experiment with something really different, like running an fsp daemon and letting people fsp files to you to be remailed. Or something of this nature, which may require leaving a program running all the time, listening to a port for connections. But maybe you can't do this either. On the other hand, if you owned your own machine and net connection, you are in a position to address all these concerns, and the people who are concerned enough to seriously use anonymous remailers may be willing to pay a postage fee. Karl Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLkrT9MSF/V8IjI8hAQFACgP/VrZDA5uSq3yHKqUeca8YVsFIkbesoCiF OQAnUWBMRFpgLK1azYZSJBkfdxllk1SPIsryM87jofQ0U7RAIqF/u9j9Cf9Me5DF v0oPFdmBYFAPICevsXJDgFed9ZD9i9Vee/OWJYM+XQlZCBeCXu4xNrKG8IjUFPo3 vwV99N/MpBI= =Y3r6 -----END PGP SIGNATURE----- -- Karl L. Barrus: klbarrus(a)owlnet.rice.edu 2.3: 5AD633; D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 2.6: 088C8F21; 97 73 9E 8B 98 3E DD B5 E8 97 64 7E 20 95 60 D9 "One man's mnemonic is another man's cryptography" - K. Cooper

1 0

Subject: Computer services in DTB was: Are Remailers Liable for What They Remail?
by Pat Farrell 17 Dec '03

17 Dec '03

Hal <hfinney(a)shell.portal.com> writes: > This is one of the things that worries me about the Digital Telephony > bill. In the various apologias and explanations from EFF, CyberWire > Dispatch, etc. about why EFF helped with this bill, it was mentioned that > online service providers have been removed from its coverage because they > are not "common carriers". It only applies, they say, to common carriers > like phone companies. > Obviously I haven't read the text of the bill (probably no one has ;-) but > this certainly raises the question of whether pursuing common carrier > status would cause electronic service providers to fall under the wiretap > require- ments of the bill. I was looking thru the text of an early markup of the bill today, and it includes information service providers. I'll go out to my car and get the page and cite. At today's congressional hearing, they did NOT provide text of the bill. EFF sold out, and I'd love to know why. Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0

RE: Crime Bill FAILED to pass
by Pat Farrell 17 Dec '03

17 Dec '03

jim(a)bilbo.suite.com (Jim Miller) writes: > Hurray!!! Yes, that is good news. And at the same time Digital Telophony looks like a lock to pass. Bummer. Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

3 2

Is there a more recent text of Digital Telephone bill available /
by die＠pig.jjm.com 17 Dec '03

17 Dec '03

Is there a current text of the Digital Telephone bill somewhere on the Internet ? Yes, I have the one John Gilmore mailed to the list but that one was only a draft as of approximately August 1 and there have been reports of changes .... Dave Emery

2 1

Cypherpunks munges sigs.
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I am very glad to say that someone is checking the sigs on these messages. Mine have not been checking out. When I send him a signed message directly there is no problem. Would some of you please check this sig on this and tell me if there is any problem. Many thanks. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLksZVFVkk3dax7hlAQEd/wP+I+vjScGW3fgrRuCZXlK837F9UHdeLyFO PFCm6+QstQY38tnfsvsPhAGKuzQ9/Ewn8n4hBsbjBMT6/mEYkTDzcGWNDlstG3qU HwgXY6UuazRwOJKPGy8edXdUfIlhf7R/zaUcyapz9obdD++G1cdPMK4vKu2khqp1 SbTyQ5rna2Q= =Ekir -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.3 key available by finger or server. "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0

Re: IDEA vs DES
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 02:09 1994/08/11 -0400, Jeremiah A Blatz wrote: .... >PowerPC integer performance is rather impressive, i.e. faster than >Pentium by a bit. One craveat, tho, Apple says "No!" to programming in >assembly, and I doubt that IBM is all this happy about it either. My >guess is that MacOS is approaching the Unix "distribute source, 'cause >you're gonna have to do lots of re-compiles" type of thing. Just a >guess, though. Anyway, there is one assembly interpreter out for >PowerMacs, I don't know about the IBM PowerPCs, though. The PowerPC floating point is even more impressive. The fmadd instruction can do "a <- b*c+d" every other clock or 30 per microsecond on the low end Power Mac. If we store 24 bits of a multiple precision number in successive elements of an arrary then the inner loop of a multiply is a routine such as: void m8(float * a, float * b, double * p) {p[0] = a[0]*b[0]; p[1] = a[0]*b[1] + a[1]*b[0]; p[2] = a[0]*b[2] + a[1]*b[1] + a[2]*b[0]; p[3] = a[0]*b[3] + a[1]*b[2] + a[2]*b[1] + a[3]*b[0]; p[4] = a[0]*b[4] + a[1]*b[3] + a[2]*b[2] + a[3]*b[1] + a[4]*b[0]; p[5] = a[0]*b[5] + a[1]*b[4] + a[2]*b[3] + a[3]*b[2] + a[4]*b[1] + a[5]*b[0]; .... p[13] = a[6]*b[7] + a[7]*b[6]; p[14] = a[7]*b[7];} The overhead consisting of loads and stores can largely be hidden since the 601 can issue both a floating point and fixed point instruction in a single clock. 1000 bit numbers can thus be multiplied in (1000/24)^2 (1/30,000,000MHz) = 59 microseconds. The outer loop is also significant but I would expect that it can be done in under 100 microseconds. Modular exponentiation of 1000 bit numbers should take about 2*(1000/24)^3 (1/30,000,000MHz) = 2.5 ms without outer loop overhead. The MPW compiler from Apple doesn't compile this code well and I may have to write it in Assembler. The documentation that comes with MPW does not discourage assembler and MPW (from Apple) includes a great assembler! In another context I wrote some C code that compiles some optimized 601 machine code (to move pixels fast) and executes it. You don't need no stinking assembler.

2 1

Re: Direct Satellite phone service
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 14:58 1994/08/09 -0700, Lyman Hazelton wrote: .... >in the mission (telephone) data portion of the IRIDIUM system. If a >subscriber wants to use their own crypto-system on top of the basic >communication service provided by the system, that is up to them. On the >other hand, if no encryption is provided by the subscriber, anyone can >listen into their conversations. .... Does IRIDIUM provide digital or analog channels?

1 0

Re: RemailerNet
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Actually, the odds are better than this, .8^5, about 0.33. You will be >compromised "only" 1/3 of the time. > >But if you are sending regular messages to another party, then traffic >analysis will quickly show that you are communicating, because even if >the boys at Langley are really dumb, you won't make send more than >two or three messages without having all the cherries lining up. > >You will be protected if you have encrypted your messages, but using >a remailer network offers little additional protection. > >-- >Jim Dixon I am not sure I see why you think that the "cherries" will line up. If one has the two honest remailers in the chain, then the only information the TLA has is that you sent a message, and the other person received one of the N messages in the labyrinth. N is the number of messages sent which could have been the received message (this is proportional to the number of messages in being reordered). It all depends on how big N is. Given the current traffic load, I suspect you are correct. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLksoL1Vkk3dax7hlAQFf2wP9EqXHQxpYZXs09oTR84CYKKZ0NFdv/rbj 6X7CpP1luGC41LDNZ0jaKJHlsNA8akULf6Q79mZ53lKqrUOREDQp5lz8j3LKU0G9 EXmvM1P10c9dAcTvrWPei+TyzZgc2PzM1By57u5hAomCoiuGHjSJEpWNJa8qGwYc CO3a7/0SyaI= =AeYf -----END PGP SIGNATURE----- -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.3 key available by finger or server. "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche

1 0