December 2003 - cypherpunks-legacy

Re: Cryptography..
by Bill Stewart 17 Dec '03

17 Dec '03

At 03:03 AM 9/29/96 -0700, Erp <erp(a)digiforest.com> wrote: >What is the maximum encryption allowed to be created. With export >restrictions in mind, and without export restrictiosn in mind... >Thanks... By WORLD and US standards please... The laws of nature don't appear to provide any maximum strength, assuming you run out of atoms to store your data before you run out of capacity for your computer, and _you'll_ be out of cash long before that :-) For mathematically strong algorithms, you can make the work a cracker has to do be exponentially larger than the amount of work you have to do to decrypt, so you win. Different governments have different rules, and many have no rules. Bert-Jaap Koops has a summary that (last time I looked) was at http://cwis.kub.nl/~frw/CRI/projects/bjk/lawsurvy.htm about different governments' crypto use and export rules. For the US, you can export cryptography software if you get permission, and you can usually get permission if you're using up to 40-bit symmetric-key keys and 512-bit public keys, or if you're writing software that's strictly for banking. You usually can't get permission for stronger crypto than that, unless you're a registered international arms dealer and are only selling your crypto gear to Friends Of The Pentagon. There aren't any restrictions on the strength of crypto you can use for messages you're exporting, only on software you export. And there are somewhat bizarre interpretations of "export", including telling foreigners inside US borders if they're not US subjects. Domestically, there are no restrictions on crypto you can write and use inside the US, subject of course to the bizarre interpretations of "domestically" that accompany "export". # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> # You can get PGP software outside the US at ftp.ox.ac.uk/pub/crypto

1 0

GCHQ releases Venona files (from UK Telegraph)
by Sherry Mayo 17 Dec '03

17 Dec '03

Hi all, A couple of articles from the UK Daily Telegraph may be of interest. The earlier one "Codebreakers come clean" is about the upcoming congference on cold war intelligence & mentions the continued release of the NSA's Venona files (see http://www.nsa.gov:8080/docs/venona/venona.html) The article is at: http://www.telegraph.co.uk/et/access?ac=116192744309&pg=//96/9/29/wspy29.ht… The second is about the GCHQ (UK equivalent of NSA) releasing its own Venona files in response to the NSA release. http://www.telegraph.co.uk/et/access?ac=116192744309&pg=//96/9/30/ngch30.ht… These are being released into the public records office, but there is no indication that they will appear on the net for the time being. Sherry

1 0

A periodic alert regarding Tim May
by Bovine Remailer 17 Dec '03

17 Dec '03

Tim May styles his facial hair to look more like pubic hair.

1 0

crypto cd
by Remo Pini 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: cypherpunks(a)toad.com Date: Mon Sep 30 07:21:49 1996 Still looking for material... especially: sci.crypt archives (10.1994 until now... Mark Riordan???) sci.crypt.research archives (all) other releavant news groups has anybody anybody got anything? remo - ------< fate favors the prepared mind >------ Remo Pini rp(a)rpini.com PGP: http://www.rpini.com/crypto/crypto.html - ----< words are what reality is made of >---- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: http://www.rpini.com/crypto/crypto.html iQEVAwUBMk9Y7hFhy5sz+bTpAQHz3wf/VD175Mf8ShQ0drqvwH4m5Yf7N9iE0ZeG V5Nv80Um3ofnhZvFscgijgPf54+25a8ogWJcEB3k+SEROvkeQkA49QmEYPIlotYi 2U6+xb5bgjQ5NvRMe09o+3cBSd7y3HabWpNPBtCX4cLxKWm3DOw+xOa+CWf8Kmuu nuaFaJhKG1RYkr/3QNPFlDSbh7PPi1Rg7go0LdVMkQUzMgWizkAOJJlg0cl5ZdVE ZV6JdiQD6o9JBWKEOX1Y4mqxQ9tRRDagfADa3S8wPOpT3WxWKVgKgbjLtvUsXrgZ miokoDGNSs2Cxlw+wk9kxKAbRrsCfoEAAPygvCHEDp0WGxA445iRZA== =NT66 -----END PGP SIGNATURE-----

1 0

Looking for Codebreaker's by David Kahn
by Hendrik Reh 17 Dec '03

17 Dec '03

Im looking for Codebreakers by David Kahn !! Can anybody give me a hint where i can get this book thanx -- ,,,, Gruss, /'^'\ Hendrik ( o o ) -oOOO--(_)--OOOo------------------------------------------------ Hendrik Reh, Tel. : +49 0681 48362 .oooO WWW: http://fsinfo.cs.uni-sb.de/~garetjax/ ( ) Oooo. eMail: hereh(a)stud.uni-sb.de ---\ (----( )------------------------------------------------- \_) ) / (_/

1 0

Re: What about making re-mailers automatically chain?
by Greg Broiles 17 Dec '03

17 Dec '03

>Would it be a good idea to have a re-mailer "randomly" decide whether to >send the mail to the destination or to another re-mailer. No. The remailer user should be presumed to know what s/he wants. Some remailer users may want to optimize for speed and certainty of delivery and therefore use a short chain; other users may want to optimize for more difficult traceability, and consequently choose a long chain. Remailers shouldn't try to rewrite the user's (perhaps) deliberate balancing of these factors. Also, users may choose to use or not use certain remailers based upon their policies, the reputation of the operators, the legal rules affecting the operators, and so forth. These choices should also be left to the user and not overridden by third parties. > If all >re-mailers performed this way, not even the sender would know the path. I don't see why this is useful. As things work now, only the sender knows the path, assuming chaining and nesting encryption. How does taking away the sender's knowledge add security? Adding hops to the chain requires that remailers keep track of other remailers; a robust way of doing this would require that they also keep track of reliability, because deciding to add a downed (or unreliable) remailer to a chain would be harmful. To prevent an active and hostile eavesdropper from adding itself as a remailer eligible to receive extra hops (and then dropping or logging the traffic), this remailer status information should be provided by a trusted source in a secure manner. All of this (adding remailer status tracking based on frequent updates of digitally signed information from a trusted third party) can be done, but it's a pain in the ass to code, and it doesn't add anything that users can't get for themselves. (Users who want long difficult-to-trace chains can already generate them. They can also let software generate random chains at the source.) It also may degrade performance for users who value speed and reliability over untraceability. So I suggest that it's not very useful. The best way to implement this would be to modify remailers to use "Anon-To: random" or "Random-To: xxx(a)yyy.zzz" header commands, such that users who desired the random hop behavior could get it, but users who didn't want it wouldn't get it unexpectedly. (Isn't some remailer doing this already? I've lost track.) -- Greg Broiles | "We pretend to be their friends, gbroiles(a)netbox.com | but they fuck with our heads." http://www.io.com/~gbroiles | |

1 0

Re: Making Remailers Widespread [REMAILERS]
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:37 AM 9/29/96 EDT, you wrote: >How about: maintain a list of trusted blocking-list sites (comparable to the >list of remailers used for chaining) and when it comes the time to update the >local copy of the blocking list, ask a random one on the list; if it's down, >ask another random one on the list. There may even be more than one list. :-) Getting more complex, but it might be workable. >> sender-blocking list ... >With most ISP's it's trivial to forge one's From: header in SMTP. >Switching to another dime-a-dozen throwaway account is also trivial. >Just admit that you can't block senders, and don't pretend that you >can - false pretenses destroy one's credibility. You obviously can't source-block a determined spammer, but you can slow down some spam attacks, especially if they're one individual using his/her regular account. It's no panacaea, but it helps. Also, if you source-block based on patterns anywhere in the header, you can catch less capable email forgers. >I think I see a way to accomplish this without too much trouble. >When an e-mail is directed at u@c4.c3.c2...c1, the code that checks >for blocking will search for the following records in the blocking list: >u@c4.c3.c2...c1 (exact match) >*@c4.c3.c2...c1 (replace user by *) >u@*.c3.c2...c1 (replace leftmost .-separated piece of domain by *) >*@*.c3.c2...c1 (both) >and repeat until there are only 2 components left in the domain name. That'd work. It's clunky, but there's no avoiding clunkiness for this sort of thing, and it does preserve privacy. >Now, the question is, who would be allowed to add records containing >'*' to the blocking list using the cookie protocol? I suggest that it be >one of the contacts listed in Internic's database. postmaster@domain is (ostensibly) guaranteed to exist. The Internic database is an interesting alternative, but for this I suspect postmaster is good enough. There's also the problem that for many domains, where smallcompany.com is virtual on an ISP, the Internic database will generally list someone at the ISP, who probably has no interest in the issue, rather than someone responsible for making decisions about smallcompany.com >Thus a blocking record for cypherpunks(a)toad.com could be added by >anyone listed in toad.com's Internic entry. There's no need for any >Remailer Cabal [tinc] to maintain blocking lists. For destination blocking, I agree that users should be able to block their own stuff as automagically as possible. For source blocking, most of the need is for spams and abusers that have been tracked down (or identify themselves in their postings), and that takes human thought. In particular, spammers are unlikely to block themselves from the remailers (:-), but forgers may try to block legitimate users. >One other suggestion: instead of storing one bit of information (the >address is on the list or not), why not have several flag bits. >E.g., the blocking list could contain records similar to: >hash - e.g. 160-bit SHA >flags - e.g. reserve 32 bits Interesting. I suspect the state of the art would be to collect the bits with a disclaimer that there isn't any code to interpret them :-), but it does let you build a blocking database that's usable as capabilities grow. Any suggestions for flags besides block/allow one-way, block/allow two-way, and max-size? I'm thinking of doing a remailer that instead of sending you a message, it sends you a retrieval cookie and lets you send it back to collect the message; blocking that would be another flag. The other kind of blocking that needs adding is blocking by words in message bodies - the spammer that caused me to shut down my remailer and not bring it back up was posting hate messages with somebody else's name and email signed at the bottom. It only took one or two to generate a flood of flames to the victim, and my current remailer couldn't block any followups. Also, since the spammer wasn't generating the flames himself, his spam slipped under the remailer's spam counter, just as hipcrime's did. This sort of blocking also lets you block things like the hipcrime spam and MAKE MONEY FAST. But it's a much more sensitive problem - anybody who can add things to the body-checking list can start doing real censorship, and it's probably best to leave that to individual operators to block, or at least to turn on by hand rather than default. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> # You can get PGP software outside the US at ftp.ox.ac.uk/pub/crypto

2 2

the key of DES
by yjkim＠ssrnet.snu.ac.kr 17 Dec '03

17 Dec '03

Hello, all ! With given a unknown DES system with 64 bits plaintext p, ciphertext c, can there be MORE THAN ONE keys ? If so, How is the probability (big or small)? Sincerely, - Yoonejong =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Yoonjeong Kim Email: yjkim(a)ssrnet.snu.ac.kr Department of Computer Engineering Phone: +82-2-875-7726 (office) Seoul National University +82-2-872-9801 (home) Seoul 151-742 Korea Fax: +82-2-875-7726 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

3 2

(Firewalls) Where is that Snake Oil FAQ again?
by Adam Shostack 17 Dec '03

17 Dec '03

This may of course, just be a troll. ----- Forwarded message from Anonymous ----- >From firewalls-owner(a)GreatCircle.COM Sun Sep 29 21:27:09 1996 Date: Mon, 30 Sep 1996 02:37:26 +0200 (MET DST) Message-Id: <199609300037.CAA20690(a)basement.replay.com> Subject: New Release - Software OTP Encryption. Content-Type: TEXT/PLAIN; charset=US-ASCII To: firewalls(a)GreatCircle.COM From: nobody(a)REPLAY.COM (Anonymous) Organization: Replay and Company UnLimited XComm: Replay may or may not approve of the content of this posting XComm: Report misuse of this automated service to <abuse(a)replay.com> Sender: firewalls-owner(a)GreatCircle.COM Precedence: bulk I apologize for this intrusion into your affairs. Please forgive but we do have important information that will be of interest to Internet users. Would you like to secure your hard disk files against compromise by Internet Interlopers? Would you like to communicate over Internet in absolute privacy? We can provide you with the tools necessary to do those two things in an absolute sense. Briefly, we have developed the first software sourced OTP, which is provably as good as any hardware sourced OTP that can possibly be be generated. Most experts thought that this could not be done, but we have done it, and can prove it. Our prices are: - $95.00 for a complete dual user system, the full package for two users, but your communications are limited to that single user - - $95.00 for a complete Elita unlimited usage system - that is you can protect your internal files, and communicate with anyone else that has an Elita system, or more comprehensive Ultima system below. - $195.00 for a complete Ultima Internet/intranets system, this allows user to protect their own files - communicate with anyone that has an Ultima, or an Elita, system - to form hierarchal work groups that provide the same protection - and to customize their system variables to achieve the maximum entropy. We are also going to open up the whole company for outside participation - it is going to a completely open Internet Distributive Company, we believe the first one of its kind. Anyone is welcome to participate in the venture. All marketing is to be done on an lucrative MLM basis, program development will be done on a royalty/commission on adjusted gross income basis. Everyone that participates will share in the rewards. System testing will also be handle in a similar manner, and system engineering will be handled on a fee for services and participation basis. If you can perform, you can win big, really big. If you just try to perform, you will still win. This is an important opportunity for you, take advantage of it at this most opportune time, To order, call us at 817-691- 1081, or write to us at 2629 Plaza Parkway, Suite B-20, Wichita Falls, Texas, or order through Internet or e-mail us at: ipgsales(a)netprivacy.com. For more details, visit our web site at: http://www.netprivacy.com Our apologies again, but we believe it to be important. Appreciatively, Don Wood, IPG "None can be so true to your secret as yourself." - Sa'Di ----- End of forwarded message from Anonymous ----- -- "It is seldom that liberty of any kind is lost all at once." -Hume

1 0

An ITAR moment
by Simon Spero 17 Dec '03

17 Dec '03

I'm currently sitting in a computer lab at the ICM in Warsaw, at a workshop on caching in the web. I wanted to log back home to check my email, so I asked if they had telnet or something. "Actually, we're disabling rlogin and telnet on our machines - can you use ssh?". Simon --- Cause maybe (maybe) | In my mind I'm going to Carolina you're gonna be the one that saves me | - back in Chapel Hill May 16th. And after all | Email address remains unchanged You're my firewall - | ........First in Usenet.........

1 0