December 2003 - cypherpunks-legacy

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

17 Dec '03

I'm really feeling much better now :-). At 6:48 PM 7/30/96 -0400, Mark M. wrote: >On Tue, 30 Jul 1996, Bill Frantz wrote: >> The paranoid conclusion is that there is a significant weakness in RC4. > >An FPGA can break RC4 in a few hours. With several thousand of these, RC4 >could be broken in about a second. Besides, RC4 has been around for 9 years >and has not been successfully cryptanalyzed. The RC4 algorithm is extremely >simple and doesn't have any obvious weaknesses. IMHO, NSA's cryptanalysis is second to none. I have been assuming a weakness based on a classified cryptanalysis technique. They have certainly been thinking about "S-Box" cyphers since at least Lucifer and DES. But let's approach the question from a different angle. Consider the number of messages that need to be broken and the costs of machines to do it. How many encrypted messages do you think NSA wants to read? I have no idea either, but in the spirit of never depend on expert opinion when simple arithmetic will do, let's assume a world where major email packages use encryption as a matter of course. If we assume that the 30 million net users send one email/day, then that results in about 350/second. If I assume your "several thousand" is 2000, then we need a machine with 700,000 FPGA's. Given Matt Blaze et. al.'s estimate of $10/chip complete, that is $7 million. However if you take the NSA's estimate (in their response to Blaze et al) of $1000/chip, then you get $700 million. If we assume a machine designed to break *every* message, NSA's response makes more sense. From their response (reordered): >The factors not accounted for are: > > o Memory costs are not included. It needs to store all the messages it is attacking. > o When get [sic] to the very fast processing speed estimates, > machines can become Input/Output bound; so [sic] it cannot achieve > the estimated speed. It needs to get all those messages into the machine, the plaintext out, and distribute the data to the FPGAs. > o As more and more chips are added to a machine, two effects occur: > > o Interconnections increase and increase running time; > o Heat from the chips eventually limit [sic] the size of a > machine. Fast machines produce a lot of heat. > o R&D costs for the first machine, typically on the order of $10 > million. R&D costs for high-speed I/O, large memories, and efficient heat removal might be significant. > o Assuming every algorithm can be tested in same amount of time and > key length is the only difference. This is one of Blase et. al.'s simplifying assumptions. RC4 has a simple key setup and runs faster than DES. Brute forcing 40 bit Blowfish would be considerably harder. Probably about equal to 9 additional key bits harder. Now I have no problem with believing NSA would invest $7 million. However, $700 million makes me wonder. With FPGAs, there is a significant risk that people will change the crypto system and make the investment worthless. (Which, I guess, is why they prefer general purpose computers.) However, if they can get the equivalent of a few bits of key back by cryptanalysis, then they knock the costs down to entirely reasonable (for them) levels. ------------------------------------------------------------------------- Bill Frantz | Cave ab homine unius lebri | Periwinkle -- Consulting (408)356-8506 | [Beware the man of one | 16345 Englewood Ave. frantz(a)netcom.com | book] - Anonymous Latin | Los Gatos, CA 95032, USA

2 1

Aspol=ego
by nobody＠vegas.gateway.com 17 Dec '03

17 Dec '03

Jim Bell raved: <snip> >If anyone out there still doubts that the time for my "Assassination ^^ >Politics" idea will never come, I claim that it's later than you think. If anyone thinks _YOU_ thought of it first, they don't know history...

1 0

FPGAs and Heat (Re: Paranoid Musings)
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:05 AM 7/31/96, Bill Frantz wrote: >I'm really feeling much better now :-). I guess Ritalin really does work. >How many encrypted messages do you think NSA wants to read? I have no idea >either, but in the spirit of never depend on expert opinion when simple >arithmetic will do, let's assume a world where major email packages use >encryption as a matter of course. If we assume that the 30 million net >users send one email/day, then that results in about 350/second. If I >assume your "several thousand" is 2000, then we need a machine with 700,000 >FPGA's. Given Matt Blaze et. al.'s estimate of $10/chip complete, that is >$7 million. However if you take the NSA's estimate (in their response to >Blaze et al) of $1000/chip, then you get $700 million. I for one don't have any way of estimating how many messages they might want to read. But note some figures we've discussed here before: * NSA spent upwards of $100 M to build the "Harvest" machine in the late 50s and early 60s (you worked with Norm Hardy, Bill, so you undoubtedly know about this). Some of this machine's capacity was for cryptanalysis, some for voice analysis, and no doubt a lot for other things. But it says something about the kinds of money that will be spent. * Spysats routinely cost a billion dollars or more. (A single launch of the space shuttle costs at least $500 M, as I recall. Some shuttle launches have been to deploy SIGINT sats.) * The NSA was one of the main investors in several high tech companies, including Control Data Corporation and Cray Research. I conclude, roughly speaking, that spending $100 M on a specialized machine to break RC4 or any other modern cipher (that is breakable at the key lengths used) would not even give them pause. >If we assume a machine designed to break *every* message, NSA's response >makes more sense. From their response (reordered): I don't believe that even _they_ would plan for something like this, unless RC4 is a lot weaker than experts seem to think it is. [stuff elided] >> o As more and more chips are added to a machine, two effects occur: >> >> o Interconnections increase and increase running time; >> o Heat from the chips eventually limit [sic] the size of a >> machine. >Fast machines produce a lot of heat. But, as many have pointed out, this is not a realistic limit. The pieces of the solution could be scattered from one end of Fort Meade to another, and still not be affected much by communications costs and delays. Power density is thus not going to be a problem. (A calculation can be done on how long it will take before electricity costs exceed chip costs...I haven't done this for the crypto FPGAs, as so many things are unclear about what they might be, but for the 200 MHz Pentium (CPU alone, not a system) I get: 40 kilowatt-hours per year x $0.10 per KWH = $4 per year in electricity costs. Heat removal costs are comparable.) FPGAs and custom chips will not be much different. I conclude that the costs of building the chips and system will be orders of magnitude more expensive than the costs of running the chips with power, and that removing the heat is not an issue. (Spread out enough, simple heat removal a la office computers is fine. Leaving windows open is even cheaper ;-)) >Now I have no problem with believing NSA would invest $7 million. However, >$700 million makes me wonder. With FPGAs, there is a significant risk that >people will change the crypto system and make the investment worthless. >(Which, I guess, is why they prefer general purpose computers.) However, >if they can get the equivalent of a few bits of key back by cryptanalysis, >then they knock the costs down to entirely reasonable (for them) levels. An FPGA is field-programmable. (FPGA = Field Programmable Gate Arrays) The Xilynx and Altera lines of FPGAs could be reconfigured for other algorithms, surely. (I recall several preliminary designs discussed in various places.) This doesn't mean they've done it, only that they could buy millions of FPGAs for the cost of a single spysat or shuttle launch. So, it seems likely. --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, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

trust management workshop
by Matt Blaze 17 Dec '03

17 Dec '03

-------------------------------------------------------------------------- | DIMACS: Center for Discrete Mathematics & Theoretical Computer Science | | A National Science Foundation Science and Technology Center | -------------------------------------------------------------------------- DIMACS Workshop on Trust Management in Networks Dates: Sept. 30 - Oct. 2, 1996 Location: CORE Bldg., Rutgers University Busch Campus, Piscataway NJ Co-Chairs: Ernie Brickell, Bankers Trust, brickell(a)btec.com Joan Feigenbaum, AT&T Research, jf(a)research.att.com Dave Maher, AT&T Research, dpm(a)research.att.com Theme: The use of public-key cryptography on a mass-market scale requires sophisticated mechanisms for managing trust. For example, any application that receives a signed request for action is forced to answer the central question ``Is the key used to sign this request authorized to take this action?'' In certain applications, this question reduces to ``Does this key belong to this person?'' In others, the authorization question is considerably more complicated, and resolving it requires techniques for formulating security policies and security credentials, determining whether particular sets of credentials satisfy the relevant policies, and deferring trust to third parties. This workshop covers all aspects of the trust management problem. Relevant topics include but are not limited to: General approaches to trust management Languages, systems, and tools Certificates and public-key infrastructure Formal models and analysis Trust management in specific application domains, including but not limited to: Banking E-mail Internet commerce Licensing Medical information systems Mobile programs and ``code signing'' Revocation of cryptographic keys Confirmed speakers include: Butler Lampson, Microsoft Matt Blaze, AT&T Research Steve Kent, BBN Carl Ellison, Cybercash Contributed talks: If you would like to attend and give a talk, please email a one-page abstract (NOT A FULL PAPER) in ascii format to Joan Feigenbaum at jf(a)research.att.com by September 1, 1996. The Trust Management workshop will be informal, and there are currently no plans to publish proceedings. For more information: If you would like to attend but not give a talk, contact Joan Feigenbaum at jf(a)research.att.com any time before the beginning of the workshop. There is a small amount of support available for people who do not have other sources of travel funds. Information about local arrangements, travel, lodging and registration can be found at http://dimacs.rutgers.edu/Workshops/Management. Those without WWW access can contact Pat Pravato at 908-445-5929 or pravato(a)dimacs.rutgers.edu. This workshop is part of DIMACS Special Year on Networks. Information about the Special Year on Networks can be found at DIMACS WWW site: http://dimacs.rutgers.edu or by contacting the center. --------------------------------------------------------------------- The Special Year program is made possible by long term funding from the National Science Foundation, the New Jersey Commission on Science and Technology and DIMACS university and industry partners. DIMACS Center; Rutgers University; P.O. Box 1179; Piscataway, NJ 08855-1179 TEL: 908-445-5928 FAX: 908-445-5932 ** EMAIL: center(a)dimacs.rutgers.edu WWW: http://dimacs.rutgers.edu **TELNET: telnet info.rutgers.edu 90 DIMACS is a partnership of Rutgers University, Princeton University, AT&T Research, Bellcore, and Lucent - Bell Laboratories.

1 0

RE: A Libertine Question
by j ubois 17 Dec '03

17 Dec '03

Alan Horowitz wrote: I am a strong libertarian...{deletia}...damn well maintain public order and decorum. ***Or I will scream to my councilman for the cops to adjust your attitude with their billy club.*** Sounds consistent and rational to me.

2 1

FW: ANNOUNCEMENT: nym.alias.net enters beta testing (fwd)
by Mr. Brandon W. Wheaton 17 Dec '03

17 Dec '03

---------- From: William Knowles[SMTP:erehwon@c2.org] Sent: Tuesday, July 30, 1996 5:54 PM To: dc-stuff Subject: ANNOUNCEMENT: nym.alias.net enters beta testing (fwd) ---------- Forwarded message ---------- Date: Tue, 30 Jul 1996 19:40:36 -0400 (EDT) From: lcs Remailer Administrator <mix-admin(a)nym.alias.net> To: cypherpunks(a)toad.com, coderpunks(a)toad.com, remailer-operators(a)c2.org, mail2news(a)anon.lcs.mit.edu Subject: ANNOUNCEMENT: nym.alias.net enters beta testing Newsgroups: alt.privacy.anon-server -----BEGIN PGP SIGNED MESSAGE----- I'm pleased to announce that the nym.alias.net pseudonym server has now entered the beta-testing phase, and seems quite stable. Nym.alias.net offers several interesting features: * Public-Key encryption of all received mail. Once mail has gone through nym.alias.net, no one can read it except you--even if you have been sending your mail to a newsgroup and your reply-block and remailers become compromised. * Support for multiple, probabilistically-weighted, reply blocks. These can be used for redundancy or to foil traffic analysis with decoys. * Replay detection. This foils replay attacks, but can also be used for higher reliability if you send redundant copies of a message through different remailer chains. * An option to receive only fixed-length messages (by splitting up large messages and padding small ones with garbage). * An option to sign mail you send with the remailer's public key, so as to give some assurance of authenticity without having to publish your own PGP public key. * Support for finger [pending DNS approval]. You can choose to make your nym's PGP public key available to all who finger its E-mail address. Right now you can test this by fingering at 18.26.0.252. In addition, experimental nym.alias.net support for Premail is now available (in the form of a patch to premail 0.44). With this patch, premail will store your nym's PGP key on encrypted keyrings. This allows you to publish a PGP key for your pseudonym without the danger of your identity being revealed to someone with access to your main PGP keyrings (or a backup copy of them). To obtain more information about nym.alias.net, finger <nymhelp(a)anon.lcs.mit.edu> or send mail to <help(a)nym.alias.net>. To get information about using premail with nym.alias.net, finger <premail-info(a)anon.lcs.mit.edu> or send mail to <premail-info(a)nym.alias.net>. These documents are also available on the new nym.alias.net web page: http://www.cs.berkeley.edu/~raph/n.a.n.html Please report all bugs to <admin(a)nym.alias.net>. I'll also be glad to consider feature requests, particularly from anyone interested in developing any more client software. Enjoy! mix-admin(a)anon.lcs.mit.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMf6dcUTBtHVi58fRAQE4NgP/SoKSqHxobEHuyWl6lXVAHgk9yqNS/WAD jUfKYGodThr93kJZkmreyIHrWgbromJJlXo6MPq9KpZzIh85uHRzBPRSh293hfUo ta8/sdZsW1+uoEkAs8JUWlwAEGo+bfmgRnFswf80pAPClpbGo52DAKyLKfdCaFps kQ+4hoouUvo= =qEWa -----END PGP SIGNATURE-----

1 0

FW: Securing 5% of the Internet against Wiretapping by Christmas (fwd)
by Mr. Brandon W. Wheaton 17 Dec '03

17 Dec '03

Something I picked up from a mailing list called dc-stuff. <dc-stuff(a)fc.net> It's mostly having to do with security and hacking, thought not typically the "bad" sort. Thought it might not only be of interest the cypherpunks, but perhaps you could offer some hints, tips, advice?? Cheers, Bdog Date: Sat, 27 Jul 1996 16:24:52 -0700 From: John Gilmore <gnu(a)toad.com> Subject: FW: Securing 5% of the Internet against Wiretapping by Christmas I've been working on a project in secret for a few months, and now am talking about it with everyone so that we can all help it along. Want all the Internet traffic between you and every other privacy-conscious site on the net, worldwide, to automatically be encrypted using Triple-DES, RSA, and Diffie-Hellman? Without changing your hardware or software, except to stick a Linux PC on your network, or install a new version of Linux on your laptop? Want it all by Christmas? Then check out http://www.cygnus.com/~gnu/swan.html [...] -- John Gilmore An equal opportunistic encryptor

1 0

Re:FPGAs and Heat (Re: Paranoid Musings)
by mccoy＠communities.com 17 Dec '03

17 Dec '03

Oddly enough, I just left a talk at the '96 Genetic Programming conference on developing adaptable hardware and silicon evolution. One of the speakers at this particular session was the Product Line Manager from Xilinx and one of the goodies he handed out was pre-release data sheets for the new XC6200 series of FPGAs they are producing (the chips are already out in limited quantities) so here is a little update on the state of the art in this area. Tim May writes: > Bill Frantz wrote: > >> o As more and more chips are added to a machine, two effects occur: > >> > >> o Interconnections increase and increase running time; > >> o Heat from the chips eventually limit [sic] the size of a > >> machine. > >Fast machines produce a lot of heat. > > But, as many have pointed out, this is not a realistic limit. One can also use reversible logic to get arond the heat problem if mechanical means are not enough. This is a necessity for molecular-scale computing and during the post-session BS at another talk we speced out a system that could probably evolve a reversible logic compiler. Heat will not be a "wall" at any scale, it may add to the cost a little bit but the problem is solvable. The interconnection problem has also been solved in this chip series. [A long-standing problem with FPGAs is that there were generally a limited amount of "wires" running between the logic elements and thus a lot of cells were wasted because there were no interconnections left, I/O to the outside world was also a problem.] The chip has a really cool interconnection method which allows a much more efficient use of the chip real estate and which makes the entire chip directly addresable (like regular RAM) through an on-chip interface module. Given the relatively compact design in Ian and Dave's paper and the new chips one might even fit two or four cracking engines on a single FPGA. Either the NSA did not do thier homework in this area or they are lying. > >Now I have no problem with believing NSA would invest $7 million. However, > >$700 million makes me wonder. With FPGAs, there is a significant risk that > >people will change the crypto system and make the investment worthless. > >(Which, I guess, is why they prefer general purpose computers.) However, > >if they can get the equivalent of a few bits of key back by cryptanalysis, > >then they knock the costs down to entirely reasonable (for them) levels. > > An FPGA is field-programmable. (FPGA = Field Programmable Gate Arrays) The > Xilynx and Altera lines of FPGAs could be reconfigured for other > algorithms, surely. (I recall several preliminary designs discussed in > various places.) There are two types of FPGAs, one is based on anti-fuse technology which is essentially a big complicated PROM, but the Xilinx FPGAs use SRAM to configure the interconnections between logic elements. The newest line from Xilinx, the XC6000 series has the capability to be reconfigured either partially or completely from an on-chip cache in 5 ns. That is five nanoseconds and you have a completely different piece of virtual hardware. If the configuration is loaded through the slowest I/O port on the chip it only takes 200 microseconds. Even if the encryption algorithm is secret these chips open up interesting posiblities for developing general-purpose cryptanalysis machines. [Hmm, there may be a paper in there... "Evolving A General-Purpose Cryptanalysis Engine"...] What is even better from the perspective of the NSA accountants is that they only need to build the machine _once_, after that they just load up a new set of interconnections and now the DES cracker is an IDEA cracker. Add to this the fact that the XC6000 series were designed to be built cheaply in large quantities (the Xilinx rep figures the price will get down to $29/chip in 5K lots for the samples he was passing around and he is a wafer guy and not marketting droid so this may be reasonably accurate.) If anything, the Blaze, et many als. paper _underestimated_ the cost of a FPGA hardware cracking engine, particularly if you amortize the savings FPGAs give over the long term with thier almost limitless flexibility. jim

1 0

Re: G7 Anti-Terrorism Reports [BRIEF]
by Deranged Mutant 17 Dec '03

17 Dec '03

On 30 Jul 96 at 18:47, Jonathan M Summers wrote: > Cypherpunks: > > At 1735 CDT on Tuesday, July 30, 1996, CNN Atlanta during World News > Tonight reported (in a _very_ brief flash) several "resolutions" adopted > by the Group of Seven (G7) trade meeting in Paris. > > At the bottom of the list of resolutions was to "prevent terrorist from > using the Internet" (quote from CNN anchorwoman). The Pacifica Report noted 'more controls on the Internet' and controlling the use of encryption, but didn't discuss this at length. Rob --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0

Re: Paranoid Musings
by Deranged Mutant 17 Dec '03

17 Dec '03

On 30 Jul 96 at 11:13, Bill Frantz wrote: [..] > (1) Now everyone knows that 40 bit RC4 is weak, but just how weak is it? Differentiate between the cipher and the key-initialization. There may be a flaw in how the key is set up that can make brute-force searches easier. Known plaintext of a few headers may also help in guessing the s-box state, even if partially: combined with flaws in the key, this could be exploited, especially if one has a lot of experience and computing power handy. [..] > (2) What did Microsoft give up to export its crypto API? > > Well, if you were a TLA, what would you want. I think I would want an > agreement to be able to insert my own code in that vendor's products. Then > I would be able to have widely distributed Trojan horses signed by the > vendor. I would have the opportunity to significantly weaken standardized > crypto systems installed world wide. Risky. Code can always be reverse engineered. If a flaw is exploited in too-strong an algorithm (3DES and 4k-bit RSA keys, for instance) to prosecute various people, somebody might notice. If US companies seem to magically have proprietary info from foreign companies, this would also be a sign of suspicion. I think the C[r]API will be used as a form of mandating GAK instead. Rob > > > Conspiracy theorists, start your mailers. > > > ------------------------------------------------------------------------- > Bill Frantz | Cave ab homine unius lebri | Periwinkle -- Consulting > (408)356-8506 | [Beware the man of one | 16345 Englewood Ave. > frantz(a)netcom.com | book] - Anonymous Latin | Los Gatos, CA 95032, USA > > > > --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0