December 2003 - cypherpunks-legacy

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

Re: PLEASE REPLY!!
by uunet!in2.uu.net!munnari.OZ.AU!news.mel.connect.com.au!harbinger.cc.monash.edu.au!usenet＠warwick.com 17 Dec '03

17 Dec '03

david(a)emeraldis.com (David G. Cannon) wrote: >Did this message make it out to the "real" world?? Please reply to this message >if it did. Thankyou. > >*David* > Your message did make it David. Hi from Australia!! Jim / jaar1(a)student.monash.edu.au

1 0

No Subject
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Hi! There was a discussion on How to install phone extension sometimes ago. Is there any appropriate URL or Usenet or Newsgroup or Mailing List available? Please email directly to: Durian(a)alpha.c2.org Thank you.

1 0

Re: crypto ++ where?
by Bill Stewart 17 Dec '03

17 Dec '03

At 01:32 AM 3/7/96 -0500, you wrote: >How can I obtain crypto++, I seem to have deleted the email I had reguarding it. The Cypherpunks mailing list is archived on *.hks.net. You can read it with a news reader on nntp.hks.net, or check www.hks.net (which tends to run a few weeks behind since it's indexed monthly so the current partial-month isn't indexed yet.) #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 pager 408-787-1281 #

1 0

Re: FCC and Internet telephones
by Bill Stewart 17 Dec '03

17 Dec '03

At 06:16 PM 3/6/96 -0800, you wrote: > >Dost my ears deceive me? Is this true? >-------- INCLUDED MESSAGE > FCC Asked to Stop Net Phones True that some organization is asking the _government_ to stop their competition? I'm shocked! Why, next thing you know people will be asking the government to restrict imports of small cars, restrict who can run radio stations, ban the hemp industry, tax imported sugar, or limit campaign contributions to non-incumbents. ("Not possible", you say - "that would be Un-American!") Of course it's true. Will the FCC do what they want? Who knows; it's stupid enough that they just might, but it may end up like the Craig Shergold O'Hair Memorial Modem Tax with people writing them crank letters for years after they've decided not to. #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 pager 408-787-1281 #

1 0