December 2003 - cypherpunks-legacy

Re: FCC Sets Comment Date for Internet Phone Call Rulemaking (fwd)
by Mutant Rob 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Henry Huang wrote: > ------- Start of forwarded message ------- > From: "Neal J. Friedman" <njf(a)commlaw.com>[..] > > The FCC has acted with astonishing speed in setting a date for comments > the ACTA petition to regulate telephone calls via the Internet. It is > uncommon for rule making petitions to sit for weeks, months, even years > without action. ACTA filed its petition on March 6th and two days [..] Odd that I have yet to see this in any business news. Has it made the WSJ, NYT, Bloomberg or TWP? Also odd that the FCC could try to regulate it. Not much they can do if someone outside the US uses IPhone or the like. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMUDveCoZzwIn1bdtAQHRkQF/U9Ypd5hAkoY86fF8e4pW9HLtVVvrRTVz GqxrRoq12MRtfQZqtD5q0u7VY6gJgR3Y =T64o -----END PGP SIGNATURE-----

1 0

CRIMINAL LAW SEMINAR
by AFDA2＠aol.com 17 Dec '03

17 Dec '03

On Friday, April 19, 1996, the Association Of Federal Defense Attorneys (AFDA) will present a one-day seminar, "The Key Fundamentals of Federal Sentencing." The seminar will be held at the Los Angeles Airport Marriott Hotel, from 9:00 am to 4:30 pm. Fee: $125 for AFDA members; $175 for non-members. Handout materials will include case law outlines and the sentencing guidelines. This seminar is specially designed for state court attorneys who handle occasional federal cases, for new federal defense attorneys, and for those who want a primer on the mechanics of the federal guidelines. For the experienced federal practitioner, AFDA will present its Third Annual Seminar, "Federal Sentencing Updates & Strategies," in the fall of 1996. For more information, click the Reply button and send a brief email requesting a fax-flyer. Remember to include your fax number. The Association's email address is: AFDA2(a)AOL.com

1 0

Re: Paint Your Own Scarlet Letter (Was: Edited Edupage, 29 Feb 1996)
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: lmccarth(a)cs.umass.edu >I couldn't resist the temptation. I rushed out and rated my home page >as evil incarnate, at least according to the SafeSurf rating system. No >innocent rugrats are gonna be learning anything about my work in crypto and >symbolic computation on the web ! I have noticed that they ask for one's URL on the page in question. This information gathering brings to mind the question of if they plan on also keeping some sort of database. While private rating efforst are not directly wrongful, given the circumstances involved they may be attempting to mandate some such (either directly or through lawsuits) via governmental pathways. >It's, uh, interesting to note that "homosexual themes" gets a whole >separate category from "heterosexual themes". :[ Quite. (Incidentally, that the CyberAngels are associated with SafeSurf, which has this distinction in their material also, gives the lie to many of the CyberAngels' claims). I am currently in the process of writing a response to this proposal, and will post the initial version to cypherpunks. >Here's the reply I received after filling out the SafeSurf web form. It looks >as though anyone can use the code below by sticking it in their HTML as >directed: They supposedly have the code in question copyrighted. I suspect that such an attempt will not be valid without changes to copyright laws, but I am not a lawyer. (It does not appear to me, at least, to have any degree of true and original creativity involved). -Allen

1 0

Vexatious Litigants (was: SurfWatch)
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 2:38 AM 3/8/96, Bill Frantz wrote: >At 6:59 PM 3/7/96 -0800, Timothy C. May wrote: >>If SurfWatch can be sued for a "bad review," then Siskel and Ebert had >>better find a new line of work. > >As long as a reviewer corrects errors, as SurfWatch seems to be willing to >do, I think they are relativly suit-proof. If they don't, well - anyone >can be sued for anything. I'll let the lawyers comment on the possibility >of success. OK, OK, I did not stick enough qualifiers in my "If SurfWatch can be sued" point. I should have said, in gory detail, "If SurfWatch can be successfully sued and found liable," etc. It is true that "anyone can be sued for anything" in these BS. I can sue Bill for writing the post he wrote. However, such a suit would definitely never reach trial. My point was that "opinions" (such as movie reviews) are not "tortable" (don't know the legal name), unless specific inaccuracies can be demonstrated, and even then it is hard. Siskel and Ebert have undoubtedly destroyed the box office prospects of many a movie with their "thumbs down" diss of death, but I know of no successful (or even adjudicated) lawsuits on this basis. One of the few cases of a reviewer being successfully sued involved the Bose Corporation, maker of the once-trendy Bose 901 speakers. It seems that around 1970 or so, at the height of popularity of the 901s, one of the stereo mags, or maybe it was "Consumer Reports," ran a review of the 901s and (correctly) criticized them as being not worth the high price (and maybe a comment that Bose's "direct-reflecting" snake oil was just that). Bose sued, and the case dragged on for many years. I think Bose eventually won. Too bad. Opinions are opinions, and a free society has no business suppressing opinions by use of torts. (Another related area is the use of torts to halt public comment on controversial development plans. These are called "SLAPP" suits--"Strategic Lawsuits Against Public Participation." For example, where AT&T sues "the Cypherpunks" to shut them up about their anti-Clipper feelings. Some judges are awarding large damages to the groups hit with the SLAPP suits.) So, while it is technically true that "anyone can sue anyone else," having the case get to trial is a different thing. And the law actually means what it says, in some cases. The First Amendment, for example, will stop Bill from successfully suing me because he dislikes my use of the word "tortable." If he files some number of these frivolous suits, he may find himself on a list of "vexatious litigants" (one of my favorite phrases of all time!). --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: Switchboard
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 10:05 PM 3/6/96 -0800, Steven Weller wrote: >Check out www.switchboard.com. From the blurb: > >find people ... I checked them out and the couldn't find my record. Since I have a listed telephone number, I can only assume that their records do not include GTE local service records or some other equally huge gap. ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

Switchboard
by stevenw＠best.com 17 Dec '03

17 Dec '03

Check out www.switchboard.com. From the blurb: find people Find friends, colleagues, and old roommates for free. Any time, nationwide. Look up over 90 million names and get fast response to addresses, phone numbers, and personalized updates. Even send email to registered users. find businesses Find over 10 million businesses across the U.S.A. for free. Whether or not they're on the web. Day or night with immediate results. Is this the same data that was supposed to go on that Lotus CD-ROM? Is this publicly available info? ------------------------------------------------------------------------- Steven Weller | "The Internet, of course, is more | than just a place to find pictures | of people having sex with dogs." stevenw(a)best.com | -- Time Magazine, 3 July 1995

1 0

TCP/IP Stego (was CU-SeeMe)
by Ben Holiday 17 Dec '03

17 Dec '03

It seems to me that it would be possible to squeeze one bit of subliminal data into each tcp packet if you were willing to sacrifice a few cpu cycles in the process: A tcp header contains quite a bit of useful information.. but most of it wouldnt be easily manipulated (by me) to get a bit. You cant very well alternate the port number you are using, or change the packet sequence numbers. However, the tcp protocol forces each tcp header to contain a 'checksum' field.. which is (more or less) the sum of all the octets in the packet. This is used as error correction for the protocol. It shouldn't be too difficult to force TCP to fiddle with the data in the packet a bit to force the checksum to be a particular sort of thing (i.e. even or odd number) .. 0 for even and 1 for odd would get us our one bit of data per packet. I may be wrong, but im pretty certain that you could hack your client (an ftp client would be a good choice since it can easily be made to receive vast numbers of packets without attracting attention) and leave the basic tcp/ip stack untouched. If your client figured out what sort of packet needed to be sent to get the right bit before passing it to the tcp stack then voila you have a subliminal channel. Of course there are alot of other ways to go about it, im sure.. Benji

1 0

Re: Steganography idea: CU-SeeMe
by Bill Stewart 17 Dec '03

17 Dec '03

At 08:28 AM 3/6/96 +0000, Ed Carp <erc(a)dal1820.computek.net> wrote: >On Wed, 6 Mar 1996, Nelson Minar wrote: >> So here's one idea I've had as a place to hide a channel: network >> video, in particular CU-SeeMe video streams. CU-SeeMe is a lowtech > >I think it likely that people will be sending GIFs and JPEGs to each >other far more often than video. Video is far more an "uncommon >communications channel" than is a uuencoded picture. The Quickcam videocameras are $100; they're the next toy to buy after you've got the Soundblaster, CDRom, and 100MB Zip drive. The Macintosh folks will buy them first (:-), but pretty soon they'll be very common, especially for business LAN users to have desktop video. The problem is that, unlike GIFs, CU-SeeMe and other low-bit-rate video compression schemes are _very_ lossy. You can't just put the stego bits in the raw image before running the compression, because they'll get lost, and if you try to fit them in to the compressed image, you've got to do it very carefully or they'll really drastically affect the image. I don't know CU-SeeMe's compression algorithm, but imagine putting bits into a run-length-encoded file: if you put them in the run-length, you'll change the lengths of the runs a lot. If you put them in the color, you'll get lots of streaks of random-looking noise. Either way, it's quite noticeable. So you've got to work very carefully with the algorithm. The other problem with CU-SeeMe is dropped frames, which someone mentioned. That's easier; any email system, especially a stego type, has to deal with lost message. So try to fit your messages into single CUSM frames, and build some tracking or ack messages or maybe message numbering, so you can detect lossage and request retransmits. It can be as complex as X.25-over-stego-over-CU-SeeMe, or as simple as "Message 14 of 32, RSVP". (If you _do_ implement X.25-over-stego-over-CU-SeeMe, you've got a fine April 1 RFC :-) #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 pager 408-787-1281 #

1 0

Re: Square pegs in round holes, matchmaking, corporate mailservers
by Bill Stewart 17 Dec '03

17 Dec '03

At 08:01 PM 3/5/96 -0500, "A. Padgett Peterson P.E. Information Security" <PADGETT(a)hobbes.orl.mmc.com> wrote: [>>Dimitris Tsapakidis <dimitrt(a)dcs.rhbnc.ac.uk> wrote:] > >Bob must find out whether Alice has declared (commited) her interest > >in him, if and only if he has declared (commited) his interest in her. > >Before he does so, he can at most know that a girl is interested in him. > >Another description: Bob and Alice can have a date if they both commit > >to each other. If only one commits, nobody will ever find out about it. > >- T is the trusted third party. > > Well if we *must* use D-H that is a way, but why do that ? Instead of > using a binary assymetric key, why not a triple ? (Just because I do not > know of any does not mean that one does not exist). > > Consider a function such that Alice has a key such that given a message M, > when encrypted by Alice may be manipulated by T such that Bob can decrypt > it. Similarly, Bob has a key that when manipulated by T' can be read by > Alice. Assymetric but not binary. The advantage here is that while "T" > is trusted by both, he/she/it/other is not able to read either message, > rather acts as a catalyst. Oh, that would work fine. Let a, b, and t be Alice, Bob, and Trent's secret DH keys, and g and p be the generator and prime (all math below is mod p.) If Bob wants to talk to Alice, he sends Trent B = g**b, marked "For Alice", optionally anonymously. Trent calculates X = B**t == g**bt, and sends it to Alice. Alice calculates K = X**a == g**bat, calculates H = Hash(K) and posts it anonymously, or sends it to Trent to post or mail to Bob. If Alice wants to talk to Bob, she calculates A = g**a mod p, sends it to Trent, optionally anonymously, marked "For Bob". Trent calculates Y = A**t == g**at , and sends it to Bob. Bob calculates K' = Y**b == g**abt, calculates H' = Hash(K') and notices that it's the same as the H he pulled off the net earlier. Bob says "Oh, wow! Alice wants to talk to me!", encrypts some lame drivel of a message M with key K'==K, and mails it to Alice if he knows her address or posts it with Subject: H', which Alice receives. Comments: 1) If Alice doesn't also want to talk to Bob, or Bob doesn't want to talk to Alice, they don't both come up with H == H', so they only know that _some_ shy person wanted to talk to them but not who it is. 2) Why does Alice reply to the anonymous message? Maybe just because she's free that evening, or maybe because it included a note with it that made her think the sender is a Nice Guy. 3) Under this method, Alice, Carol, Eve, and Greta can get together and notice that they've all gotten mail with keys X; they don't know who X is, but they know he's interested in all of them and he's probably a trolling loser :-) So they all dump him. However, even though they know Bob's public key B, they don't know t, so they can't tell from g**bt mod p that it's Bob, so they can't send him email saying "Get lost, loser" without revealing their identity. So Trent is providing anonymity, and needs to be trusted. Without Trent, you could do a two-way version of the protocol - if Bob wants to talk to Alice, he posts Hash(A**b), and vice versa, but Alice can go evaluate Hash(B**a), Hash(C**a), Hash(D**a), etc., for everyone in the phone book, and find out that it was Bob. 4) If Bob wants to reduce the level of trust he needs to have in Trent, he can create a bunch of keys b1, b2, b3, ...., bk in addition to b, and use a different one for each note. If I remember correctly, he can often calculate the inverse of b, b1,... (??????) So he sends Trent B1=g**b1, Trent sends Alice X1=B1**t == g**b1t, Alice calculates K1=X1**a == g**b1at, H1=Hash(g**b1at), and posts/sends. Since she's also interested in Bob, she does the same with key a, so Trent gives Bob K'g**bat. Bob calculates Z = K'**binv == g**at(b*binv) mod p == g**at, and then calculates Hash(Z**b1), Hash(Z**b2), Hash(Z**b3)..., and notices that H1 = Hash(X**b1) and says "Oh, it's Alice!" On the other hand, this doesn't appear to work if Alice is also using multiple identities. 5) If Trent is a really trustable guy, he can offer meeting services for people who have unusual tastes, such as liking (Exon) and Duct Tape and Political Party Z and (for bipartite variants) suppliers and consumers of various substances. So he could broker a list of (Exon)fans, as long as the activity is not criminal enough to lead to subpoenas or warrants for his transactions (if he keeps them) or his key t (or t1, t2, t3... if he's running multiple lists.) Dimitris's approach of using Hash(message) could be used to exchange preference here as well. If Alice checks the message for Hash("Duct Tape"), she can decide that she and the unknown sender would be a great match, and if she hadn't thought to check Hash((Exon)) she wouldn't know that Bob enjoyed that also. So it's at least some privacy for low-popularity unusual activities :-) 6) Of course, Trent really could be a front for Blacknet :-) Or Trent's key could be stolen and published, embarassing all his customers. > As to why you would want such a curiosity, consider a corporation with 80,000 > mailboxes. It would be desirable for each person to be able to send E-Mail > to any other person but not desirable for each person to have to hold all > 80,000 keys. Given a triple (tertiary ?) function each individual would only > need their receive key and a "post office" transmit key. On sending a message, > it would be encrypted with a session key and the session key encrypted with the > post office key. The post office would have all 80,000 receive functions but > through the assymetic keying would only be able to convert the session key to something > each intended recipient could decode but not be able to decode the message > itself. > This would meet both criteria (not key escrow but that is under "management") > D-H is wonderful but has difficulties with scalability. If such a function > existed (has anyone looked ?) it would solve the problem. Ah. The method I described above doesn't solve your problem; it just solves the original Shy-People's-Dating problem. If your only concern is scalability, and you don't mind doing the multiple-message handshaking Diffie-Hellman requires (<=SPD...), you can use either a signed-keypart Diffie-Hellman or just use PGP with the mailserver signing keys and keyserving. PGP approach: Bob has Public/private keys B/b, Alice A/a, Trent T/t, Sam S/s. Trent is the mail agent at Alice's company, T is well-known. Sam is the mail agent at Bob's company, S is well-known. "Well-known" means that all the mail servers know each other's pubkeys. If Alice and Bob both use the same postoffice, Sam==Trent, so it's simpler. Bob to Sam: Fetch Alice's Key Sam to Trent: Fetch Alice's Key Trent to Sam: A (signed by T) Sam verifies and caches A(signed by T), and already knows T. Sam to Bob: A (signed by T), T (signed by S). Bob verifies T's signature on A, S's on T. Bob to Sam: To: Alice(a)trent.aliceco.com, PGPEncrypted(Message,A) Bob either caches A, or caches T, or doesn't bother. Sam to Trent: (ditto) Trent to Alice: (ditto) Alice decodes the message. If she needs Bob's keys, she asks Sam to fetch them. So there's basically a key-fetching handshake, with Trent and Sam acting as CAs as well as keyservers, and then regular PGP. Clean, simple, and all your regular tools work, except of course that the keyservers use some database to store keys in instead of a big hulking PGP keyring. A Diffie-Hellman relative is a bit messier, because it's Diffie-Hellman. Assume that the modulus and generator p and g are agreed on (e.g. Photuris's.) Alice and Bob have their PGP public keys A, B. Trent and Sam have their PGP public keys T and S, well-known. Bob generates a random x, calculates X = g**x mod p. Bob to Sam: To: alice(a)trent.aliceco.com, X signed B. Sam to Trent: To: alice(a)trent.aliceco.com, X signed B, B signed S. Trent to Alice: To: alice, X signed B, B signed S, S signed T. Alice generates random y, calculates Y = g**y mod p, also K = X**y mod p. Alice to Trent: To: bob(a)sam.bobco.com, Y signed A Trent to Sam: To: bob(a)sam.bobco.com, Y signed A, A signed T Sam to Bob: To: bob, Y signed A, A signed T, T signed S Bob verifies Y, A, T, calculates K' = Y**x mod p == K. Bob to Sam: To: alice(a)trent.aliceco.com, Encrypted(Message,K). Sam to Trent: (ditto) Trent to Alice: (ditto) Alice decodes the message using K. To make things simpler, Bob might include Hash(K) or some other message identifier. In this case, the key-fetching handshake is piggybacked along with the DH key-exchange halves, and then Bob uses the jointly derived session key to send a conventionally-encrypted message (which he _could_ use PGP for...) #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 pager 408-787-1281 #

1 0

test
by uunet!in2.uu.net!newsfeed.internetmci.com!info.ucla.edu!ihnp4.ucsd.edu!pwa.acusd.edu!news＠warwick.com 17 Dec '03

17 Dec '03

1 0