- cypherpunks-legacy - lists.cpunks.org

NSA crypto at DNC?
by Jack Lloyd 27 Jul '04

27 Jul '04

http://www.nytimes.com/2004/07/26/business/26verizon.html "Nextel, the official mobile provider to both conventions, is deploying its iDEN network with encryption codes used by the National Security Agency to make sure no one eavesdrops on all the deal making." Anyone know what's up with this? I'm guessing this just means AES, or maybe Skipjack, but it would be interesting (and very strange) if they were using BATON or JUNIPER. -Jack

1 0

Re: Email tapping by ISPs, forwarder addresses, and crypto proxies
by Tyler Durden 27 Jul '04

27 Jul '04

Variola wrote... >>While this cannot be discounted in toto, the tech comes to them from >>academia (most of the time), so generally, if you are widely read, you'll >>have a pretty good idea of what's *possible*. You are likely dead-on >>accurate about the fabs though. >In the *public* lit. Well, perhaps but perhaps not. Burst-mode signaling, transceivers, and networking technology are a good example. If you see DISA, NSA, and DARPA all working with the acknoledged experts inthe academic field, and if you see them spending $$$ on burst-mode testbeds, then it's clear that there are some issues they haven't solved. Of course, they may not be the issues WE think they are, but you get some idea. What that also hints at is that they can't actually always backhaul EVERYTHING. Their interest in burst-mode indicates they still view bandwidth as an obstacle (and not dark fiber, but actual lit bandwidth). Of course, their bandwidth "problem" is probably at orders of magnitude greater than we'd consider a problem, but their continued interest in burst mode probably indicates there are times when they have huge amounts of data that needs to get through i a short amount of time, and they don't want to clog up a channel. >Fair 'nuff. You know that 5 year predictions are too conservative, and >20 year predictions too liberal. Ask Orwell. Well, there's the famous Adaptive Optics story centered around bringing Manua Kea online. When the Manua Kea designers were trying to solve some of the big issues ca. 1988, the military (as part of one of their dual-use programs) declassified Laser Guidestar research they had done in 1962! In other cases you can, however, take a reasonably good guess. Remember, during the bubble there was billions poured in by the private sector in making lasers more efficient, smaller, etc...There just happen to be physical limitations. But I have zero doubt that the NSA can't make a laser that is siginificantly more efficient than what I can buy off the shelf. >You think subs are just toys? Actually, this is a most interesting point. Those cables are not merely giant rubber hoses running around on the sea floor...the telecom equipment is actually powered via an electrical layer in the cable sheath. And then remember that there are lots of fibers in any one of those cables, and that the signal therein might easily need to be amplified due to splice losses. So that Sub (which I know exists) must really be something to see. Almost makes me want to join the dark side! (Oh yeah, come to think of it I did actually work on an NSA project that examined some undersea optical component failures out of one of their networks. From the components we looked at, I can only guess what their network topology must have been (OC-3 ATM, BTW), but I can only take vague guesses as to what it must do). -TD _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

1 0

[Meetingpunks] SF Bay Area Cypherpunks August 2004 Physical Meeting Announcement
by Bill Stewart 27 Jul '04

27 Jul '04

Rick Moen suggested we have a Cypherpunks meeting in August, so: SF Bay Area Cypherpunks August 2004 Physical Meeting Announcement General Info: DATE: Saturday 14 August 2004 TIME: 12:00 - 5:00 PM (Pacific Time) PLACE: Stanford University Campus - Tressider Union courtyard Agenda: "Our agenda is a widely-held secret." (This will be our first meeting since April 2003, so the agenda is somewhat up for grabs. Among upcoming events to note is the 7th annual Information Security Conference, aka ISC04, Sept. 27-29 at Xerox PARC, http://isc04.uncc.edu/ . Also of note: Our friendly Federalistas seem to be imposing unprecedented visa restrictions on visiting foreign cryptographers. Is it time for all international cryptography conferences to move off-shore? See: http://www.schneier.com/crypto-gram-0407.html#3 ) As usual, this is an "Open Meeting on US Soil", and the public is invited. Location Info: The meeting location will be familiar to those who've been to our outdoor meetings before, but for those who haven't been, it's on the Stanford University campus, at the tables outside Tressider Union, at the end of Santa Theresa, just west of Dinkelspiel Auditorium. We meet at the tables on the west side of the building, inside the horseshoe "U" formed by Tresidder. Ask anyone on campus where Tressider is and they'll help you find it. Food and beverages are available at the cafe inside Tresidder. Location Maps: Stanford Campus (overview; Tressider is dead-center). http://campus-map.stanford.edu/campus_map/bldg.jsp?cx=344&cy=471&zoomto=50&… Tressider Union (zoomed detail view). http://campus-map.stanford.edu/campus_map/results.jsp?bldg=Tresidder Printable Stanford Map (407k). http://www.stanford.edu/home/visitors/campus_map.pdf [ This announcement sent to the following mailing lists: cypherpunks-announce(a)toad.com, meetingpunks(a)cryptorights.org, cypherpunks-request(a)minder.net, cryptography-request(a)metzdowd.com Mailing list complaints or address corrections to bill.stewart(a)pobox.com. ] ---- Bill Stewart bill.stewart(a)pobox.com _______________________________________________ Meetingpunks mailing list Meetingpunks(a)lists.cryptorights.org http://lists.cryptorights.org/mailman/listinfo/meetingpunks ---- Bill Stewart bill.stewart(a)pobox.com

1 0

DES: Now 'really most sincerely dead'
by Trei, Peter 27 Jul '04

27 Jul '04

Back in late 1996, I wrote to Jim Bidzos, proposing an RSA Challenge to break single DES by brute force computation. Later in 1997, the first DES Challenge was successfully completed. Its taken another 7 years, but NIST has finally pulled single DES as a supported mode. Favorite line: "DES is now vulnerable to key exhaustion using massive, parallel computations." Triple DES is still a supported mode, as it should be. So, if a product claims to use DES for protection, you can now officially diss them for it. Peter Trei ------------------------------------------ http://edocket.access.gpo.gov/2004/04-16894.htm [Federal Register: July 26, 2004 (Volume 69, Number 142)] [Notices] [Page 44509-44510] >From the Federal Register Online via GPO Access [wais.access.gpo.gov] [DOCID:fr26jy04-31] ----------------------------------------------------------------------- DEPARTMENT OF COMMERCE National Institute of Standards and Technology [Docket No. 040602169-4169-01] Announcing Proposed Withdrawal of Federal Information Processing Standard (FIPS) for the Data Encryption Standard (DES) and Request for Comments AGENCY: National Institute of Standards and Technology (NIST), Commerce. ACTION: Notice; request for comments. ----------------------------------------------------------------------- SUMMARY: The Data Encryption Standard (DES), currently specified in Federal Information Processing Standard (FIPS) 46-3, was evaluated pursuant to its scheduled review. At the conclusion of this review, NIST determined that the strength of the DES algorithm is no longer sufficient to adequately protect Federal government information. As a result, NIST proposes to withdraw FIPS 46-3, and the associated FIPS 74 and FIPS 81. Future use of DES by Federal agencies is to be permitted only as a component function of the Triple Data Encryption Algorithm (TDEA). TDEA may be used for the protection of Federal information; however, NIST encourages agencies to implement the faster and stronger algorithm specified by FIPS 197, Advanced Encryption Standard (AES) instead. NIST proposes issuing TDEA implementation guidance as a NIST Recommendation via its ``Special Publication'' series (rather than as a FIPS) as Special Publication 800-67, Recommendation for Implementation of the Triple Data Encryption Algorithm (TDEA). DATES: Comments on the proposed withdrawal of DES must be received on or before September 9, 2004. ADDRESSES: Official comments on the proposed withdrawal of DES may either be sent electronically to DEScomments(a)nist.gov or by regular mail to: Chief, Computer Security Division, Information Technology Laboratory, ATTN: Comments on Proposed Withdrawal of DES, 100 Bureau Drive, Stop 8930, National Institute of Standards and Technology, Gaithersburg, MD 20899-8930. FOR FURTHER INFORMATION CONTACT: Mr. William Barker (301) 975-8443, wbarker(a)nist.gov, National Institute of Standards and Technology, 100 Bureau Drive, STOP 8930, Gaithersburg, MD 20899-8930. SUPPLEMENTARY INFORMATION: In 1977, the Federal government determined that, while the DES algorithm was adequate to protect against any practical attack for the anticipated 15-year life of the standard, DES would be reviewed for adequacy every five years. DES is now vulnerable to key exhaustion using massive, parallel computations. The current Data Encryption Standard (FIPS 46-3) still permits the use of DES to protect Federal government information. Since the strength of the original DES algorithm is no longer sufficient to adequately protect Federal government information, it is necessary to withdraw the standard. In addition, NIST proposes the simultaneous withdrawal of FIPS 74, Guidelines for Implementing and Using the NBS Data Encryption Standard and FIPS 81, DES Modes of Operation. FIPS 74 is an implementation guideline specific to the DES. An updated NIST Special Publication 800- 21, Guideline for Implementing Cryptography in the Federal Government, will provide generic implementation and use guidance for NIST-approved block cipher algorithms (e.g., TDEA and AES). Because it is DES- specific, and DES is being withdrawn, the simultaneous withdrawal of FIPS 74 is proposed. FIPS 81 defines four modes of operation for the DES that have been used in a wide variety of applications. The modes specify how data is to be encrypted (cryptographically protected) [[Page 44510]] and decrypted (returned to original form) using DES. The modes included in FIPS 81 are the Electronic Codebook (ECB) mode, the Cipher Block Chaining (CBC) mode, the Cipher Feedback (CFB) mode, and the Output Feedback (OFB) mode. NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation, specifies modes of operation for generic block ciphers. Together with an upcoming message authentication code recommendation, SP 800-38B, SP 800-38A is a functional replacement for FIPS 81. FIPS 81 is DES-specific and is proposed for withdrawal along with FIPS 46-3 and FIPS 74. NIST invites public comments on the proposed withdrawal of FIPS 46- 3, FIPS 74 and FIPS 81. After the comment period closes, NIST will analyze the comments and make appropriate recommendations for action to the Secretary of Commerce. Future use of FIPS 46-3 by Federal agencies is proposed to be permitted only as a component function of the Triple Data Encryption Algorithm or ``TDEA.'' TDEA encrypts each block three times with the DES algorithm, using either two or three different 56-bit keys. This approach yields effective key lengths of 112 or 168 bits. TDEA is considered a very strong algorithm. The original 56-bit DES algorithm can be modified to be interoperable with TDEA. Though TDEA may be used for several more years to encourage widespread interoperability, NIST instead encourages agencies to implement the stronger and more efficient algorithm specified by FIPS 197, Advanced Encryption Standard (AES) when building new systems. TDEA implementation guidance will be issued as a NIST Recommendation rather than as a FIPS. NIST plans to issue TDEA as Special Publication 800-67, Recommendation for Implementation of the Triple Data Encryption Algorithm (TDEA). Authority: Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National Institute of Standards and Technology after approval by the Secretary of Commerce pursuant to section 5131 of the Information Technology Management Reform Act of 1996 and the Federal Information Security Management Act of 2002, Public Law 107-347. E.O. 12866: This notice has been determined not to be significant for purposes of E.O. 12866. Dated: July 18, 2004. Hratch Semerjian, Acting Director, NIST. [FR Doc. 04-16894 Filed 7-23-04; 8:45 am]

1 0

[IP] Cybersecurity: they just don't get it... (fwd from dave@farber.net)
by Eugen Leitl 27 Jul '04

27 Jul '04

----- Forwarded message from David Farber <dave(a)farber.net> -----

2 1

Re: "Terror in the Skies, Again?"
by Tyler Durden 26 Jul '04

26 Jul '04

Sounds to me like Al-Qaeda is just getting the most mileage they can out of their little PR Event a couple of years ago. They don't even need to blow up anything to get the most bang for their buck. Hell, in this story the biggest threat was the incompetence of the airline. -TD >From: "Major Variola (ret)" <mv(a)cdc.gov> >To: "cypherpunks(a)al-qaeda.net" <cypherpunks(a)al-qaeda.net> >Subject: Re: "Terror in the Skies, Again?" >Date: Fri, 16 Jul 2004 17:36:21 -0700 > >At 02:19 PM 7/16/04 -0500, Riad S. Wahby wrote: > >I don't quite know what to make of this. Is it just paranoid rambling? > > > > >http://www.womenswallstreet.com/WWS/article_landing.aspx?titleid=1&articlei… > > > > >What I experienced during that > >flight has caused me to question whether the United States of America > >can realistically uphold the civil liberties of every individual, even > >non-citizens, and protect its citizens from terrorist threats. > > > >Ask the American citizens interned in California during WWII.. > > > > > _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

4 3

Re: cypherpunks-digest V1 #13888
by Tim Benham 26 Jul '04

26 Jul '04

> Date: Sun, 25 Jul 2004 15:39:47 -0700 > From: Bill Stewart <bill.stewart(a)pobox.com> > Subject: Re: Email tapping by ISPs, forwarder addresses, and crypto > proxies > > At 04:44 PM 7/24/2004, J.A. Terranson wrote: > > > [1] the original phone phreaks were blind, > > > >This is a ridiculous statement, and even worse, leaks information about > >your nym: [young enough to have not been there]. > >You are thinking of Joe "Whistler" Joe Egressia (sp?), and the kid form > >New York whose names escape me at the moment. These two do not even com > >close to "the original phone phreaks were blind". More like "at least two > >of the original batch of phreaks were blind". > > Cap'n Crunch may have bad teeth, but his eyes were fine the last time I saw > him. Who stole the Cap'n's mind? was it the Fedz?? :?) TimB

1 0

Re: Email tapping by ISPs, forwarder addresses, and crypto proxies
by Major Variola (ret) 25 Jul '04

25 Jul '04

At 01:07 PM 7/18/04 -0500, J.A. Terranson wrote: >Let me fill in what he left out. Yes, the industry is moving towards >MPLS over POS. That's not where it is now though. At least not for most >interfaces. Right now the industry is chock full of lagacy gear, mostly >old fashioned ATM. You think you can just casually reassemble this crap >in transit? Let's see it! Gimme an intel IXA network processor and no problem. ATM is fixed size data, not as tricky as IP decoding. Predicatable bandwidth. Stream all into megadisks, analyze later. You need to tap the MPLS label assignment service (or watch all the egress ports and correlate to endpoints) too to know which ATM chunks went where. >Besides that old fashioned transport diversity, we have the original >problem: even if you could do it (maybe in three to five years), what are >you going to do with the data you've snarfed? Backhaul it? Shove it into >TB cassettes? Better keep a guy on staff to change the tray!! You don't know about tape robots, or offline indexing, eh?

4 4

Feds and Yahoo Muzzle DNC Security Whistleblower
by John Young 25 Jul '04

25 Jul '04

It appears that the Feds and LEA at the DNC Convention have ordered Yahoo to axe the mail list TSCM-L run by James Atkinson for his blistering attack on security at the convention. http://cryptome.org/dncsec-yahoo.htm Jim's reports on the inferior security: http://cryptome.org/dnc-insec.htm http://cryptome.org/dnc-dauphine.htm The mail list had nothing to do with these reports, and the gag appears to be spite against Atkinson for whistleblowing. However, the mail list purpose is likely to have scared them more than his insecurity reports: http://finance.groups.yahoo.com/group/TSCM-L/ TSCM-L Technical Security Mailing List Dedicated to TSCM specialists engaging in expert technical and analytical research for the detection, nullification, and isolation of eavesdropping devices, wiretaps, bugging devices, technical surveillance penetrations, technical surveillance hazards, and physical security weaknesses. This also includes bug detection, bug sweep, and wiretap detection services. Special emphasis is given to detecting and countering espionage and other threats and activities directed by foreign intelligence services against the United States Government, United States corporations, establishments, and citizens. The list includes technical discussion regarding the design and construction of SCIF facilities, Black Chambers, and Screen Rooms. This list is also for discussing DIAM 50-3, NSA-65, and DCID 1/21, 1/22 compliance. The primary goal and mission of this list is to "raise the bar" and increase the level of professionalism present within the TSCM business. The secondary goal of this list is and increase the quality and effectiveness of our efforts so that we give spies and eavesdroppers no quarter, and to neutralize all of their espionage efforts. This mailing list is moderated by James M. Atkinson and sponsored by Granite Island Group as a public service to the TSCM, Counter Intelligence, and technical security community. --

1 0

Re: Email tapping by ISPs, forwarder addresses, and crypto proxies
by hal＠finney.org 25 Jul '04

25 Jul '04

Thomas Shaddack writes: > Reading some news about the email wiretapping by ISPs, and getting an > idea. > > There are various email forwarding services, which are nothing more than a > SMTP server with pairs of recipient(a)forwarder.com -- > recipient(a)hiscurrentisp.com. Right, mostly for use as disposable email addresses. I've used spamgourmet to good effect, myself. > Messages in storage have much lower judicial protection than messages in > transit. (This does not have much technical merit, in the current > atmosphere of "damn the laws - there are terrorists around the corner", > but can be seen as a nice little potential benefit.) One thing I haven't understood in all the commentary is whether law enforcment still needs a warrant to access emails stored in this way. Apparently the ISP can read them without any notice or liability, but what about the police? Also, what if you run your own mail spool, so the email is never stored at the ISP, it just passes through the routers controlled by the ISP (just like it passed through a dozen other routers on the internet). Does this give the ISP (and all the other router owners) the right to read your email? I don't think so, it seems like that would definitely cross over the line from "mail in storage" to "mail in transit". > There can be an easy enhancement for such forwarder service; GnuPG proxy. > Every email that arrives to the forwarder address, before it is forwarded > to the real recipient, is piped through a GnuPG script; the recipient has > then to upload his public key during the registration of the target > address, otherwise the function is the same. That's a great idea. You'd want to be sure and encrypt the whole message including headers, and make the whole thing an encrypted attachment. Has the added side benefits of compressing the email, and you could even have the server do some spam filtering. > For added benefit, the > forwarder should support SMTP/TLS (STARTTLS) extension, so the connections > from security-minded owners of their own mailservers would be protected. STARTTLS support at the proxy should pretty much go without saying these days, so you might as well do it, but if you're already PGP encrypting then it's not adding that much security. Well, maybe it does, but you're talking about a different threat. For the problem that ISPs can read your email in storage, STARTLS doesn't help much because it will only protect the email until it gets to your local ISP, who will store your email for you and can read it then (which is where the PGP comes in). Where STARTTLS would help is with power users who run their own mail servers. But those people don't suffer from the problem we are talking about here, legal access to the email by the ISP (I think, see above). Nevertheless a mail-receiving proxy that uses STARTTLS connections to power users would be kind of cool because it would keep anyone local from knowing anything about the incoming mail. Hopefully, STARTTLS will eventually become so widespread that this functionality will be redundant, but we are not there yet. > The recipient himself then can either run his own mailserver and download > mails through fetchmail, or receive mails using SMTP/ETRN (both methods > allow automated decryption of such wrapped mail during its receiving), or > use a POP/IMAP decryption proxy, or have a plugin in mail client. > > (I know, auto-decryption is dangerous, but we now talk about the system > for one's grandma, transparent to use.) Absolutely, look at the threat model. You're not worried about someone breaking into your computer, you're worried about your ISP legally reading your email. To address this threat, auto-decryption is a perfect solution. Recently there was a proposal for a nym receiving service, http://www.freehaven.net/doc/pynchon-gate/, by Bran Cohen and Len Sassaman. They have a complicated protocol for downloading email anonymously. To hide the complexity, they propose to set up a POP compatible mail server agent on the user's computer running as a daemon process (Windows service). He would configure his mailer to connect to localhost:4949 or whatever, just like any other POP server. The service would periodically go out and poll for email using the fancy protocol, but then it would make it available to the local mail agent in perfectly vanilla form. The point is that this architecture hides the complexity and makes it transparent for end users to use arbitrarily complex crypto for mail receiving. Something similar would be perfect for your idea. > The only vulnerable parts of the mail route then will be the sender's > computer, the pathway between the sender and the forwarder server (if > SMTP/TLS is not used correctly or at all), the forwarder server (if > compromised), and the recipient's computer. The way between the forwarder > and the recipient's ISP, including the recipient's mailbox, is secured. > > What do you think about this scheme? I think it's a great idea. Of course as you say there is still the problem that the forwarding server could read your email, so you have only moved the threat from the ISP to another operator. The difference I suppose is that the forwarder would be selling privacy services, hence different ones would compete to get a good reputation. Any cheating might be detected by insider whistle blowers or perhaps some kind of audit. Hal Finney

6 6