December 2003 - cypherpunks-legacy

Moto Secure Clear digital?
by Wes Felter 17 Dec '03

17 Dec '03

I just got a second phone line, and decided that if I was going to get a 2-line phone it might as well be a good one, so I am considering a Motorola Secure Clear cordless 2-line phone with speakerphone. This will be quite an investment,so I was wondering whether the Secure Clear phones are digitally encrypted or merely scrambled using some analog method. Anybody know about this? How secure are these phones really? --Wes Wesley Felter wesf(a)unicycle.cs.tulane.edu I speak for no one. Trust no one. Cryptography is outlawed and only the outlaws care. When thinking is outlawed, maybe then somebody will care. When thinking is outlawed, only outlaws will be able to care. <sigh, depressing .sig>

3 2

Re: NYT on Insecure Phones
by cactus＠hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <199412040246.VAA25360(a)pipe3.pipeline.com>, John Young <jya(a)pipeline.com> wrote: > Cellular One of Washington-Baltimore, owned by SBC > Communications Inc., has sent its customers letters > notifying them that it would block the service beginning on > Thursday because it had compiled a huge backlog of phone > numbers used in New York that appeared to be fraudulent. It's worse than that! They will allow customers to use their service in NYC, I'm told by a customer of their's visiting this weekend, if they pay for the call with a credit card (IE, VISA, MC, etc) that they must *give* *an* *operator* *over* *the* *cellphone*. So to avoid their own exposure to fraud, they're requiring their customers to give credit card info over the cellphone. Thanks, guys. No pro-34s 'round here, nope. - -- Todd Masco | "Roam home to a dome, Where Georgian and Gothic once stood cactus(a)hks.net | Now chemical bonds alone guard our blond(e)s, cactus(a)bb.com | And even the plumbing looks good." - B Fuller - --- [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 iQBFAwUBLuFGUioZzwIn1bdtAQF98wGAiBKy9nk/SzN7Nb/8v/noLEZDJgRCZy71 pjyDqlAtjnnQ0KelgzqDPLr8LIXAo8Eq =+JzJ -----END PGP SIGNATURE-----

3 2

Interoperability, one-use remailer tickets
by Mike Ingle 17 Dec '03

17 Dec '03

The remailers need a one-time reply mechanism. This would enable many other things, including "persistent" anonymous entities, without using broadcast techniques. The current remailers encourage hit-and-run anonymity, like the recent burst of anonymous nastiness, and discourage conversational anonymity and persistent anonymous entities. Sending a one-way message is easy and fairly secure. Creating a reply ticket is not very secure. The ticket can be replayed through the net to trace the path taken, and since the text following the ticket it sent in clear, it is easy to trace. The ticket can also be decrypted by coercion or hacking of the remailer machines. In general, there is enough persistent information available to trace any reply ticket. This is a bad thing. A one-shot reply ticket would be designed so that, after the ticket was used or a set time had passed, the ticket was no longer valid and the information needed to trace the path, partially stored in the remailers, was gone. One way to do this: each remailer has a list of secret (symmetric) keys. Each secret may have an expiration date. By some method (problem discussed later) the user and the remailer establish a shared secret, adding it to the list, while the remailer does not find out who the user is. The reply ticket contains a series of nested hops, each encrypted with that remailer's secret plus all the others after it. When the ticket is used, the remailer decrypts one layer of the ticket to obtain the next hop. It then encrypts the message with that secret key. Now it forgets the secret key (poof!) and passes the message and remainder of the ticket on to the next remailer. The ticket is getting decrypted at each hop, and the message is getting encrypted. Thus there is nothing recognizable between hops, and the trail is burning up as the message propagates. At the terminal end, the recipient applies all of the secret keys in the proper order to decrypt the message. Of course, an additional end-to-end public-key encryption is also an option. The catch: how do we establish a shared secret with the remailer, without identifying ourselves to it? If the first remailer (the one the replyer sends the ticket to) is corrupt, and it knows who established the secret contained in the ticket, it knows the end-to-end path of the message. Solution 1: each remailer has a public key. To establish shared secrets with a series of remailers, you send a normally-chained and nested message, using each remailer's public key. Each remailer decrypts a layer, stores the secret contained for it, and passes the message on. The first few remailers may not get secrets; they are just there to anonymize the message. Problem: secret-establishing message is replayed, setting trail back up, then reply ticket is replayed. Solution: when a secret is used, it is one-way hashed, the hash stored, the secret forgotten. Secrets which have already been used will not be accepted the second time. When the used secrets list gets full, a new public/secret pair is generated and the old one is forgotten, preventing any more replays. Problem: remailers are coerced or hacked to decrypt a captured secret- establishing message, before the secret key is expired. Trail of a reply ticket can then be followed. Solution: no good one that I can think of. Solution 2: establish a shared secret by a simple, direct Diffie-Hellman exchange with the remailer. You send a public-piece in a message, remailer sends you a public-piece, both sides compute the secret. If the remailer is corrupt, it now knows who you are. This is a level-1 secret. Use the level-1 secret as a reply ticket to establish a secret with another remailer. Message goes through a remailer, to the target you want to establish a secret with. Target replies using the level-1 secret. This is a level-2 secret; two remailers have to be corrupt to trace this secret to you. If you want, use the level-2 secret for another exchange to create a level-3 secret, and so on until your comfort zone is reached. An automatic program sits around stockpiling secrets for you. Problem: high bandwidth. Does anyone know of a better way to establish a shared secret in an untraceable way? Both of these methods have their problems. Given a secure two-way messaging mechanism, persistent anonymous identities are established using a "pigeonhole service". This is a service, with a publicized address, that will accept public-key encrypted mail and store it in a "pigeonhole". The owner of the pigeonhole anonymously sends a request (with authentication) and a reply ticket. The pigeonhole service sends the owner his mail using the ticket. Anonymous users would need a client that could set up trails, create tickets, request mail from the pigeonhole, etc. One nice feature of the system is that non-anonymous users could talk to anonymous users without having a client. The anonymous message would be of the form: --- BEGIN REPLY TICKET (LEAVE AT HEAD OF REPLY) --- (Reply ticket ciphertext) --- END REPLY TICKET --- Message text The non-anonymous user could reply with any mail reader, send the message back to the remailer that sent it to him, and the message would be transported securely back to the anonymous user that sent it. For something complex like this, we need a language with a little more leverage than C provides. For this and other complex protocols, I've ported RSAREF 2.0 to Perl. The interface does not require you to recompile Perl. It uses a C daemon and pipes. It provides symmetric encryption, public-key encryption, digital signatures, hashing, DH exchange, and ASCII armor. The algorithms used are MD5, MD2, DES, DESX, triple-DES, RSA, and DH. It has a good (eval/die) exception handling mechanism, and a very thorough regression testing script. For reliability in a large remailer network, end-to-end reliability is better than point-to-point reliability. Messages should be m-of-n secret shared before transmission, and reassembled at the terminal end. For clientless reception, the terminal node remailer could do the reassembly and splitting of replies. Code for secret sharing is available, but most secret-sharing algorithms create shadows each the size of the message. This can be avoided: use an error correcting code to add enough information to the original so the message can be recreated with any m of n pieces. Break into pieces, encrypt each piece, and secret-share the key. Where can I get an error correction algorithm that can do this? You should be able to increase a file's size by 50% and then have any two of three pieces recreate it, for example. I want to add other algorithms to the Perl encryption package. The secret sharing, for one. A one-function call to gzip for compression. A blind signature if I could get patent permission (not from Chaum; how's Brands?) or perhaps just do it with a "research purposes only" disclaimer. Someone with Visual Basic experience could do a DOS/Windows VBX module to enable easy writing of PC clients for neat net-based servers written with the Perl encryption package. As Tim, Eric and others have pointed out, the problem of widespread, usable crypto is essentially the whole problem of interoperability across a network. Covering Unix for servers and Windows for clients would be a large step in the right direction. Mike

2 2

future entrapment
by alano＠teleport.com 17 Dec '03

17 Dec '03

>From: Mklprc(a)aol.com >Date: Sun, 4 Dec 1994 09:26:11 -0500 >To: scottr(a)hevanet.com >Cc: alano(a)teleport.com, brew(a)mtek.com, GERICKS971(a)aol.com, > 74710.3505(a)compuserve.com, furseor1(a)hr.house.gov >Subject: future entrapment > >Something to think about...(fwd) > >Thought you all might be interested in this excerpt from CPSR list regarding >copyrights on the Net and especially how police can use the Web to set up >stings. > >mp > > >------------------------------ > >Date: Thu, 1 Dec 1994 07:45:31 -0800 >From: Charlie Stross <charless(a)sco.com> (by way of marsha-w(a)uiuc.edu >To: cpsr-global(a)cpsr.org > >Philosophically, I see most journalists as being filters. Some of us >read press releases, strip out the propaganda, and supply the results >(with interpretation) to the public. Some of us go and try to nail >down the story by poking around and asking questions. But ultimately >we rely on sensory input at some level -- and all we do is rearrange >it, comment on it (by referring to prior input), and punt it out again >at our readers. This is fundamentally an editorial process, and there >will be more need for it -- not less -- as the information deluge >gathers momentum. > >There's a huge problem on the net: how does copyright apply to a reference? >For example: I can't stitch a Far Side cartoon into my WWW home page. But >I _can_ embed an <IMG SRC= ...> directive in my page, pointing to a Far >Side cartoon that is _legitimately_ stored somewhere else on the net. When >you look at my page you will see the cartoon ... and will have a bit of a >headache when you stop to think about the copyright implications. > >The precise question of what constitutes a copyright violation runs >into a wall of mud as soon as you start asking questions about sources >and hyperlinks. For example, here's the kind of havoc you can wreak by >classifying all embedded link dereferences as deliberate actions. >Suppose I am a cop in some redneck area, and I want to nail someone >who uses the net locally. I could run a _very_ neat entrapment sting >to nail people for posession of kiddie porn: > >* establish a local WWW server hosting some useful information >* configure the server to record the IP addresses of people who > access it, and cross-reference them to obtain geographical > locations as registered with NIC. Feed this into a GIS and > track local accesses. >* have a list of people who I want to nail. >* filter all HTTP requests through a script that > - checks the list of victims > - if a request for a file comes in from one of the > targets, munge the outgoing web page to include > a <IMG SRC= ...> tag pointing to a foreign site > carrying images deemed pornographic in my jurisdiction > - ring the console bell > >As soon as someone on the hit list downloads a file, you have prima >facie evidence that they are probably in posession of some kiddie porn. >Instant search warrant time ... > >(And in case you were wondering, this is just a technology twist on top >of the recent Adult Action BBS case in Mississippi.) > >Basically, as far as I can see, conventional notions of copyright are >going to have to change -- because copying is no longer the only mechanism >for gaining posession of information. Our notions of intellectual property >may also have to change ... > > >-- Charlie > >(Who happens to write a column in Online World, and who can be found >most months in Computer Shopper and some months in PC PLUS -- all three >of them UK-based magazines unrelated to any US titles of the same name.) >------------------------------------------------------------------------- > > >++M++++I++++C++++H++++A++++E++++L++++++P+++++E+++++A+++++R+++++C+++++E++++ >| mklprc(a)aol.com | Knowledge for the pupil -er- people. | >| mklprc(a)teleport.com | Give them a light and they'll | >| "annoying Xists since 1966" | follow it anywhere! -- Firesign | >+++Y+O+U'D++P+A+Y++T+O++K+N+O+W++W+H+A+T++Y+O+U++R+E+A+L+L+Y++T+H+I+N+K+++ > > > | "Encryption ROT13s your mind." | alano(a)teleport.com | |"Would you rather be tortured by the government | Disclaimer: | |forces or the people's liberation army?" -mklprc | Ignore the man | | -- PGP 2.6.2 key available on request -- | behind the keyboard.|

1 0

NYT on Wireless Data Systems
by John Young 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Laurie Flynn writes today on wireless data systems by Ardis, Ram Mobile Data and the new Cellular Digital Data Packet. For email copy send blank message with subject: WIR_no - -----Key ID 34EE1095 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLuGxFYSb9hQ07hCVAQHPfwP/bubk1tJ+OXcYGsjpSsOwNIw9M3QBEBzj btC/Trus4qfFPhpzt5Kl84cuybF3i0iW5yUgwNKOMSKKWn40Z6pwm4dWGlUi71LW Qil3s8cPYNIiyd/gc15G5RZzw3UX/YLDDMukWawVblz5eJW0lwcasYoUb7jwju8m e4ny978LIm8= =7GE/ -----END PGP SIGNATURE-----

1 0

Re: ecash trial issues explained
by paul＠poboy.b17c.ingr.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Stefan Brands wrote: > I have not contributed to this discussion in any way afterwards. In light of > this, I most certainly felt unhappy with the subject of "Brands excluded from > digicash beta" someone decided to choose; the wording "excluded" implies > something (the deliberateness of the whole thing) which I certainly did not > intend to imply (and do not believe). I am at least partially responsible for this, and I apologize. It is not fair to imply either that Digicash intentionally excluded Brands or that Brands claimed that they had. It looks like everyone's concerns and complaints have been addressed. Thanks to the folks from Digicash for their work. - -Paul - -- Paul Robichaux, KD4JZG | Good software engineering doesn't reduce the perobich(a)ingr.com | amount of work you put into a product; it just Not speaking for Intergraph. | redistributes it differently. ### http://www.intergraph.com ### -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLuHynKfb4pLe9tolAQE/kAQAvrJ71y/jN4FMWO8aoAkhQjP1V/6kpork J74x85O3QvXRs1S6nsAyRGiAextT0GS7LHHyCVerh4/4Gwk6LgKk2TzaPJxp5oyU RUTFS16ghIWGzWmjkL/MXuinRxvaN4hogIqNJ/pARbdwW6Ncm/I4VBk+WSFEM2ha MA1UyViLFc4= =QewS -----END PGP SIGNATURE-----

1 0

Dec. 10th Bay Area Cypherpunks Meeting
by KT Kislitzin 17 Dec '03

17 Dec '03

ANNOUNCEMENT ============ This month's Bay Area Cypherpunks Meeting will be held this Saturday, December 10th, from 12 noon until 6 pm in Silicon Graphics Cafe Iris (same cypher time, same cypher channel...). The topic for this month's discussions is: Technical Cryptography We have three speakers planned. Susan Langford will speak on Cryptanalysis of DES and Other Block Cyphers. She will be speaking generally on the subject, and will discuss her work on Differential Linear Cryptanalysis of DES. Susan is working with Martin Hellman at Stanford University. Raph Levien will present ``The Security of Cypher Block Chaining'', a paper from Crypto '94 by Mihir Bellare, Joe Kilian, and Phillip Rogaway. Raph is working to infect all mail user agents with PGP. Eric Hughes will present ``Towards the Equivalence of Breaking the Diffie-Hellman Protocol and Computing Discrete Logarithms'', a paper from Crypto '94 by Ueli M. Maurer. Eric has been active in the Cypherpunks movement for several years now. Additional speakers are of course welcome. Discussions of implementations of crypto systems are welcome also. Please contact me (ktk(a)sgi.com or ktk(a)syzygy.com) asap if you are interested in speaking. Presentations need not be long. Suggestions for dinner are welcome. ----------------------------------------------------------------------------- DIRECTIONS: Silicon Graphics, Inc. Building 5 (SGI Cafeteria) 2025 North Shoreline Boulevard Mountain View, CA >From 101 take Shoreline East. This is towards Shoreline Amphitheatre. It's also "logical east", and points more north that east. (That is, it's east with respect to 101 North, which points west near the exit.) If you're coming in on 101 South, you'll cross over the bridge. Continue on Shoreline and go past a whole bunch of other SGI buildings. Turn right onto Steirlin Court at the big red metal sculpture. There will be even more SGI buildings surrounding you--take note of the building numbers. Go almost to the end of this street. Building 5 is on the right.

5 5

Timestamping
by Tony.Gurnick＠nzdairy.co.nz 17 Dec '03

17 Dec '03

Could the cypher punks automatic signing also be used as a distributed timestamping service? Where you send a hash/document to it and it timestamps and signs it, to the fact that this hash was in existsence at the specified time. Then it would forward your message on to another such service picked at random until the hash has been stamped the number of times you specified. If you collect a number of timestamps from around the world you could make a case for a document existsing at a certian time. You could also back & forward link in time to other documents that each timestamp services has stamped! Any comments???? T

1 0

Re: Censorship In Cyberspace 1/6
by rarachel＠photon.poly.edu 17 Dec '03

17 Dec '03

> >The Moderator: > >John Kennedy Taylor is the author of "Reclaiming the Mainstream: > ^^^^ > Shouldn't this be "Joan"? Yep, it should infact be Joan. I didn't take the time to go over this before posting it to the list. :-) I'm sure there are other errors.

1 0

Re: Timestamping
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <94120509115477(a)nzdairy.co.nz>, DNA <Tony.Gurnick(a)nzdairy.co.nz> wrote: >Could the cypher punks automatic signing >also be used as a distributed timestamping service? Absolutely. That was one of my financial motivations for writing the code, and why the "Gratis" is mentioned in the comment. As is, I don't think there's a market available for it yet... but having the code is a good hedge, as is the increased awareness that it's a possible use of digital signatures. - -- Todd Masco | "Roam home to a dome, Where Georgian and Gothic once stood cactus(a)hks.net | Now chemical bonds alone guard our blond(e)s, cactus(a)bb.com | And even the plumbing looks good." - B Fuller - --- [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 iQBFAwUBLuIp3ioZzwIn1bdtAQH2cQGAthnwkpw6QvfJspGfZ1Dkxu1Yh+x8Wikv RC8evXmgyQBbUpr3TA7k0GGFR8YWD6GV =A8+p -----END PGP SIGNATURE-----

2 1