- cypherpunks - lists.cpunks.org

Re: [Cryptography] IA side subverted by SIGINT side
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from John Gilmore <gnu(a)toad.com> ----- Date: Fri, 06 Sep 2013 10:27:58 -0700 From: John Gilmore <gnu(a)toad.com> To: Jon Callas <jon(a)callas.org> Cc: cryptography(a)metzdowd.com, "Perry E. Metzger" <perry(a)piermont.com> Subject: Re: [Cryptography] IA side subverted by SIGINT side > I have a small amount of raised eyebrow because the greatest bulwark > we have against the SIGINT capabilities of any intelligence agency are > that agency's IA cousins. I don't think that the Suite B curves would > have been intentionally weak. That would be a shock. Then be "shocked, shocked" that the muscular exploitation side of an intelligence agency would overrule the weak Information Assurance side. It happens over and over. It even happens in companies that have no SIGINT side, like Crypto AG, when somebody near the top is corrupted or blackmailed into submission. As late as 1996, the National Academy of Sciences CRISIS panel was tasked by the US Congress with coming up with a US crypto policy that would be good for the whole nation, updating the previous policy that was driven by spy agency and law enforcement excesses to sacrifice the privacy and security of both people and companies. After taking a large variety of classified and unclassified input, the panel's unanimous consensus suggested that everybody standardize on 56-bit DES, which they KNEW was breakable. Diffie, Hellman and Baran persuasively argued in the 1970s when DES was up for standardization that a brute force DES cracker was practical; they recommended longer keys than 56 bits. See for example this contemporaneous 1976 cassette recording / transcript: https://www.toad.com/des-stanford-meeting.html Subsequent papers in 1993 (Weiner, "Efficient DES Key Search") and in 1996 (Goldberg & Wagner, "Architectural Considerations for Cryptanalytic Hardware") provided solid designs for brute-force DES key crackers. Numerous cryptographers and cypherpunks provided input to the CRISIS panel as well. They even cited these papers and input on page 288 of their report. I have never seen a subsequent accounting by the CRISIS panel members for this obviously flawed recommendation. It was rapidly obsoleted by subsequent developments when in June 1997 Rocke Verser coordinated a team to publicly crack DES by brute force in months; when in 1998 EFF revealed its DES Cracker hardware that cost $250K and could crack DES in a week; and when in 2000 the export regs were effectively removed on any strength encryption in mass market and free software, a change forced upon them by EFF's success in Dan Bernstein's First Amendment case. The panel members included substantial information-assurance folks like Marty Hellman and Peter Neumann, Lotus Notes creator Ray Ozzie, and Willis Ware (an engineer on WW2 radars and the Johnniac, who later spread computers throughout aviation design and the Air Force, ended up at RAND, and served on the 1974 Privacy Act's Privacy Protection Study Commission). But several of those people (and others on the panel such as Ann Caracristi, long-term NSA employee and 2-year deputy director of NSA) also have a long history involved with classified military work, which makes their publicly-uttered statements unlikely to reflect their actual beliefs. John PS: The CRISIS panel also recommended that encryption of any strength be exportable "if the proposed product user is willing to provide access to decrypted information upon a legally authorized request". They assumed the ongoing existence of a democratic civilian government and a functioning independent court system in the United States -- an assumption that is currently questionable. I don't think the panel foresaw that a single "legally authorized request" would come with a gag order from a secret court, would purport to "target" a single unnamed individual, but would nevertheless require that information about every person making a phone call in the United States be turned over to a classified government agency for permanent storage and exploitation. Nor did they see that the government they were part of would be committing serious international war crimes including political assassination, torture, indefinite detention without trial, and wars of aggression, on an ongoing basis. Either that, or maybe NSA blackmailed the committee members into these recommendations, just as J. Edgar Hoover blackmailed his way through 40 years of unchecked power. Trouble is, Hoover eventually had to die; NSA, not being human, does not have that natural limit. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

2 1

[cryptography] NSA can spy on smart phone data
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from ianG <iang(a)iang.org> ----- Date: Sun, 08 Sep 2013 20:11:47 +0300 From: ianG <iang(a)iang.org> To: Crypto discussion list <cryptography(a)randombit.net> Subject: [cryptography] NSA can spy on smart phone data User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 http://www.spiegel.de/international/world/privacy-scandal-nsa-can-spy-on-sm… Privacy Scandal: NSA Can Spy on Smart Phone Data SPIEGEL has learned from internal NSA documents that the US intelligence agency has the capability of tapping user data from the iPhone, devices using Android as well as BlackBerry, a system previously believed to be highly secure. The United States' National Security Agency intelligence-gathering operation is capable of accessing user data from smart phones from all leading manufacturers. Top secret NSA documents that SPIEGEL has seen explicitly note that the NSA can tap into such information on Apple iPhones, BlackBerry devices and Google's Android mobile operating system. The documents state that it is possible for the NSA to tap most sensitive data held on these smart phones, including contact lists, SMS traffic, notes and location information about where a user has been. The documents also indicate that the NSA has set up specific working groups to deal with each operating system, with the goal of gaining secret access to the data held on the phones. In the internal documents, experts boast about successful access to iPhone data in instances where the NSA is able to infiltrate the computer a person uses to sync their iPhone. Mini-programs, so-called "scripts," then enable additional access to at least 38 iPhone features. The documents suggest the intelligence specialists have also had similar success in hacking into BlackBerrys. A 2009 NSA document states that it can "see and read SMS traffic." It also notes there was a period in 2009 when the NSA was temporarily unable to access BlackBerry devices. After the Canadian company acquired another firm the same year, it changed the way in compresses its data. But in March 2010, the department responsible at Britain's GCHQ intelligence agency declared in a top secret document it had regained access to BlackBerry data and celebrated with the word, "champagne!" The documents also state that the NSA has succeeded in accessing the BlackBerry mail system, which is known to be very secure. This could mark a huge setback for the company, which has always claimed that its mail system is uncrackable. In response to questions from SPIEGEL, BlackBerry officials stated, "It is not for us to comment on media reports regarding alleged government surveillance of telecommunications traffic." The company said it had not programmed a "'back door' pipeline to our platform." The material viewed by SPIEGEL suggests that the spying on smart phones has not been a mass phenomenon. It has been targeted, in some cases in an individually tailored manner and without the knowledge of the smart phone companies. Visit SPIEGEL ONLINE International on Monday for the full article. _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

2 1

Re: [Cryptography] tamper-evident crypto?
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from John Denker <jsd(a)av8n.com> ----- Date: Fri, 06 Sep 2013 12:31:47 -0700 From: John Denker <jsd(a)av8n.com> To: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] tamper-evident crypto? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/05/2013 06:48 PM, Richard Clayton wrote: > so you'd probably fail to observe any background activity that tested > whether this information was plausible or not .... and then some chance > event would occur that caused someone from Law Enforcement (or even a > furnace maintenance technician) to have to look in the basement. Well, I'm sure /somebody/ on this list is clever enough to arrange countersurveillance and counterintrusion measures... a) especially given that detecting surveillance and/or intrusion is the whole point of the exercise; b) especially given that we have all the time in the world to arrange boatloads of nanny-cams and silent alarms etc., arranging everything in advance, before provoking the opponent; c) especially given that we know it's a trap, and the opponent probably isn't expecting a trap; d) especially given that the opponent has a track record of being sometimes lazy ... for instance by swearing that the fruits of illegal wiretaps came from a "confidential informant who has been reliable in the past" and using that as the basis for a search warrant, at which point you've got them for perjury as well as illegal wiretapping, *and* you know your information security is broken; e) especially given that we get to run this operation more than once. > (assuming that the NSA considered this [kiddie porn] > important enough to pursue) *) If they don't like that flavor of bait, we can give them something else. For example, it is known that there is a large-diameter pipeline from the NSA to the DEA. http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/05/the-nsa-is-giv… *) Again: We get to run this operation more than once. I repeat the question from the very beginning of this thread: Shouldn't this be part of the /ongoing/ validation of any data security scheme? There's a rule that says that you shouldn't claim a crypto system is secure unless it has been subjected to serious cryptanalysis. I'm just taking the next step in this direction. If you want to know whether or not the system is broken, /measure/ whether or not it is broken. One of the rules in science, business, military planning, et cetera is to consider /all/ the plausible hypotheses. Once you consider the possibility that your data security is broken, the obvious next step is to design an experiment to /measure/ how much breakage there is. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFSKi2j2FOSJqrRXAoRAtJAAJ9zUubRz66YdcdRM3G3Wpx70TcDtgCgm9tE xiI/Ikqt4PbbTDZeC0sK9vI= =UYAV -----END PGP SIGNATURE----- _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

2 1

Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Jean-Francois Mezei <jfmezei_nanog(a)vaxination.ca> ----- Date: Sun, 08 Sep 2013 15:50:33 -0400 From: Jean-Francois Mezei <jfmezei_nanog(a)vaxination.ca> To: nanog(a)nanog.org Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 With regards to the 10$ snake oil security product versus the real one at $100: since the NSA can break both, they are both worth worth $0 in terms of privacy. >From a business/corporate point of view, there are two aspects: 1- Image: If your weak security has allowed a data breach to become public (such as TJ-Maxx) then you have damage to your image. But TJ-Maxx has survived and average person forgot about millions of credit card numbers having been stolen from its databases. If the NSA snoops on your systems to see what kind of underwear Ossama Bin Ladin buys and where he has them delivered, there is nothing your company can do about it. Either you don't know it is happening and NSA will never make it public (no image problem), or you got a warrant and were forced to do it (some image problem, but you can say your hands were tied and shift blame to NSA) 2- Real cost: if you're a bank, and someone intercepts a letter of credit or payment transaction to find out how much a corporate customer pays for widgets, that customer can sue you for breach of security/confidentiality (since its competitors now know what deal he has negotiated to buy those widgets). The lawsuit against the bank has real costs (not only lawyers, but settlement as well). It becomes easier to cost justify security when you can put real costs to not having security. So risk management is an important factor in both cases. BUT, when you get to general public, the equation changes: For the general public, a burglary is a good analogy. You can easily put value to the stolen TV set and replace it. But this isn't what happens when the NSA spies on your private communications and you have no real measurable damage. The damage you get is akin to losing your family pictures or the feeling of having been violated because someone came into your home and rummage through all your personal stuff and not knowing exactly what they will do with your personal items and why they stole them. Putting a value to this is next to impossible. Risk managememnt becomes impossible, except at the politival level. If the NSA intercepts private emails between a husband and his mistress, the husband can't know if the NSA will ever use this against him. This fear remains because the NSA night hold on to these emails for a long time (or might not). And at the political level, Obama made it clear in a recent speech that he hopes this will blow over and that he will be able to convince americans that the NSA is doing good things. Their political staffers evaluated the risk that this might backfire and figured it wouldn't. This has nothing to do with selection of technology to guard against the NSA' it is all about political public opinion. Here is what the politicians forget: Because the economy is moving to the internet, losing trust in the internet is akin to losing trust in the banking system. I am not sure network operators have much of a choice. Sure, someone like Bell Canada will hopefully review their no-peering policy in Canada (forcing so much traffic to route via USA), but for other networks there isn't much they can do to prevent NSA from accessing any/all data while in transit. What is really needed is for an intelligent debate by politicians on the need to preserve trust in the internet and whether preventing a couple of bombs is really worth the loss of trust and freedom due to implementation of measures worse than what "1984" predicted. Since intelligent debate by politicians is impossible, the other way to change things is to seriously deprive any politician who supports excessive spying by NSA of any money and chance to be re-elected. Imagine the good publicity AT&T and/or Verizon would get if they were to announce that they are ceasing all political contributions to any party or individual politician who supports the indiscriminate data collection done by NSA. And this might be enough to tilt the table and get politicians to start to criticise the NSA and call for measures to limit its spying. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
by Eugen Leitl 08 Sep '13

08 Sep '13

Plants in the IETF? Sounds plausible. ----- Forwarded message from Phillip Hallam-Baker <hallam(a)gmail.com> ----- Date: Thu, 5 Sep 2013 16:33:58 -0400 From: Phillip Hallam-Baker <hallam(a)gmail.com> To: "Perry E. Metzger" <perry(a)piermont.com> Cc: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" On Thu, Sep 5, 2013 at 3:58 PM, Perry E. Metzger <perry(a)piermont.com> wrote: > I would like to open the floor to *informed speculation* about > BULLRUN. > > Informed speculation means intelligent, technical ideas about what > has been done. It does not mean wild conspiracy theories and the > like. I will be instructing the moderators (yes, I have help these > days) to ruthlessly prune inappropriate material. > > At the same time, I will repeat that reasonably informed > technical speculation is appropriate, as is any solid information > available. http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-secu… • The NSA spends $250m a year on a program which, among other goals, works with technology companies to "covertly influence" their product designs. I believe this confirms my theory that the NSA has plants in the IETF to discourage moves to strong crypto. -- Website: http://hallambaker.com/ _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

3 2

Re: [linux-elitists] Surveillance
by Eugen Leitl 08 Sep '13

08 Sep '13

Anyone with CA/package signing opsec clue willing to help Linux distros with advice to improve package signing security? ----- Forwarded message from Greg KH <greg(a)kroah.com> ----- Date: Sun, 8 Sep 2013 09:58:23 -0700 From: Greg KH <greg(a)kroah.com> To: linux-elitists(a)zgp.org Subject: Re: [linux-elitists] Surveillance User-Agent: Mutt/1.5.21 (2010-09-15) On Sun, Sep 08, 2013 at 06:43:09PM +0200, Eugen Leitl wrote: > On Sun, Sep 08, 2013 at 09:08:24AM -0700, Greg KH wrote: > > > > Real physical security and a process to keep signing secrets > > > secure in community based Linux and *BSD distributions. > > > > What are the problems in the existing processes that you feel are week? > > For example, what is wrong with openSUSE's signing process that you feel > > are wrong? > > I'm only aware of how Debian does things, and not in any detail. Then don't assume that all distros have this type of problem please. > What I would do is to separate the signing secrets across multiple > key people, and do a recorded/witnessed ceremony following a CA-like > model, signing on an air-gapped machine which is securely > wiped afterwards and transferring packages via sneakernet > (making sure there's nothing autoexecuted on plugin) > to the machine where it is being published. Yes, this is a huge > pain. And it makes automated builds an almost impossible thing to achive, so it's not realistic. > So have a secure process in place, monitor the process by > external parties so that we can be sure that it is actually being > done the way it is said to be done. Trust, but verify. Agreed, and I think that other distros already do this, Debian might be the exception :( > > > Review of anything crypto based. Completely different process > > > for anything crypto based than for everything else. No more > > > undetected regression meltdowns a la Debian. > > > > What type of review? What type of process would catch stuff like that? > > Getting in the professionals. A lot of old cryptography and > cypherpunk hands have reappeared and the woodwork is buzzing > with activity. They have clue and they're willing to help. Projects almost always gladly accept patches and review, what's stopping anyone from doing this today? I know of a handful of people who started doing this for the Linux kernel a few years ago and instantly got job offers to continue doing this full-time. Some of them accepted and have been working very well on fixing a huge range of issues. Some decided to stay where they were and continue to churn out great tools that let us fix these issues (academia is a good place for stuff like this.) Those tools work on all projects if they wish to be used, it's only a matter of the developers using them. > Somebody should first get them talking, and then organize a > physical meeting. If I knew any distro guys I would try to > hook them up. Have them go to FOSDEM, where all the distros have a multi-day track to work on issues that encompass them all. greg k-h _______________________________________________ Do not Cc: anyone else on mail sent to this list. The list server is set for maximum one recipient. linux-elitists mailing list linux-elitists(a)zgp.org http://zgp.org/cgi-bin/mailman/listinfo/linux-elitists ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[linux-elitists] Congruent Infrastructure (was: Re: Surveillance)
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Andy Bennett <andyjpb(a)ashurst.eu.org> ----- Date: Sun, 08 Sep 2013 17:14:01 +0100 From: Andy Bennett <andyjpb(a)ashurst.eu.org> To: Marc MERLIN <marc(a)merlins.org> Cc: linux-elitists(a)zgp.org Subject: [linux-elitists] Congruent Infrastructure (was: Re: Surveillance) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 Hi, >> Which means I need to set up that build the source >> package and check that the binaries match thing. >> Anyone doing this already for your favorite >> distribution? > > I did that at google for our distribution that runs in production, > well more specifically we don't run upstream binaries at all. We've > re-bootstrapped our own distribution, maintain and compile our own openssl, > openssh and so forth. > > We also have mostly binary invariant builds, and yes that was work, we had > to patch stuff for sure. > However, that process didn't tell us if the upstream binaries were the same > because we modified most of our source to be leaner and compiled differently > than upstream. > Home page: http://marc.merlins.org/ I notice you did this: http://marc.merlins.org/linux/talks/getupdates/ I'd be very interested in your views on things such as Puppet or Chef: I myself have been very skeptical of them. Some of the issues are outlined in this blog post (not by me): http://blog.thestateofme.com/2013/04/30/an-adventure-with-chef/ It seems that all the evangelists for such things have never heard of things like MIT Athena and http://www.infrastructures.org/ and don't seem to know much about the underlying theory. infrastructures.org describes a system similar to the one in your slides, albeit using slightly older technology. I'd be interested in your thoughts on "congruent infrastructure management" especially around the issues of avoiding divergence, proving convergence and recovery from failure that doesn't involve wiping the machine. Regards, @ndy -- andyjpb(a)ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF _______________________________________________ Do not Cc: anyone else on mail sent to this list. The list server is set for maximum one recipient. linux-elitists mailing list linux-elitists(a)zgp.org http://zgp.org/cgi-bin/mailman/listinfo/linux-elitists ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Bruce Schneier has gotten seriously spooked
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Brian Gladman <brg(a)gladman.plus.com> ----- Date: Sun, 08 Sep 2013 00:32:50 +0100 From: Brian Gladman <brg(a)gladman.plus.com> To: Gregory Perry <Gregory.Perry(a)govirtual.tv> Cc: Cryptography Mailing List <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] Bruce Schneier has gotten seriously spooked User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 07/09/2013 20:58, Gregory Perry wrote: > On 09/07/2013 02:46 PM, Brian Gladman wrote: >> Because NSA and GCHQ are much more interested in attacking communictions >> in transit rather than attacking endpoints. >> >> Endpoint attacks cost more to undertake, only give access to a limited >> amount of data and involve much greater risks that their attack will >> either be discovered or their means of attack will leave evidence of >> what they have done and how they have done it. The internal bueaucratic >> costs of gaining approval for (adverarial) endpoint attacks also makes >> it a more costly process than the use of network based interception. >> >> There is significant use of open source encryption software in end to >> end encryption solutions, in file archivers, in wifi and network >> routers, and in protecing the communications used to manage and control >> such components when at remote locations. The open source software is >> provided in source code form and is compiled from source in a huge >> number of applications and this means that the ability to covertly >> substitute broken source code could provide access to a huge amount of >> traffic without the risks involved in endpoint attacks. > > I would submit that the exact inverse is the real target - endpoint devices. There is simply too much volume of Internet traffic to realistically analyze and process, even with the next big datacenter in Utah and multi gigabit wire rate capable deep content inspection blades. It's the endpoint devices that the FBI is after for targeted intrusions (for both domestic and foreign targets), and the NSA used to have a very legitimate charter with a culture dedicated to protecting U.S. communications at all costs. I don't have experience of how the FBI operates so my comments were directed specifcally at NSA/GCHQ interests. I am doubtful that very large organisations change their direction of travel very quickly so I see the huge investments being made in data centres, in the tapping of key commmunications cables and core network routers and 'above our heads', as evidence that this approach still works well for NSA and GCHQ. And I certainly don't think that volume is a problem yet since they have been able to invest heavily to develop the techniques that they use to see through lightweight protection and to pull out 'needles from haystacks'. Of course, you might well be right about the future direction they will have to travel because increasing volume in combination with better end to end protection must be a nightmare scenario for them. But I don't see this move happening all that soon because a surprisingly large amount of the data in which they have an interest crosses our networks with very little protection. And it seems even that which is protected has been kept open to their eyes by one means or another. Brian _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

3 2

Re: [linux-elitists] Surveillance
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from "D. Joe" <deejoe(a)etrumeus.com> ----- Date: Sun, 8 Sep 2013 15:15:48 +0000 From: "D. Joe" <deejoe(a)etrumeus.com> To: linux-elitists(a)zgp.org Subject: Re: [linux-elitists] Surveillance User-Agent: Mutt/1.5.20 (2009-06-14) On Sun, Sep 08, 2013 at 06:58:08AM -0700, Don Marti wrote: > begin Greg KH quotation of Sat, Sep 07, 2013 at 09:14:31PM -0700: > > But what else needs to be worked on? What gaps do people feel we have > > that are cauing problems that we can solve with technological measures, > > not just legal ones? > > A repository of deliberately subverted packages > for some key components? Not just to show what's > possible when Bad Builds Happen to Good Software, > and call attention to it, but to give people some > real scenarios to work through. A little less . . . equinimity . . . in the face of unauditable blobs, maybe? Getting back to deterministic builds, Eugen has mentioned Tor's efforts with regard to deterministic builds, and I think we get the nugget of what deterministic builds entail in the context of a single system vis a vis a centralized repository, but consider: https://blog.torproject.org/category/tags/deterministic-builds Working out the conventions for this could diffuse the targets of malefactors' subversion attempts against source repositories, against binary repositories, and against build environments. Think of it, perhaps, as a web-of-trust applied to the build process, or DVCS meets web-of-trust meets grid computing. A great deal of the "build from source" enthusiasm revolves around making customized builds. To the extent that these are one-off efforts (even if done on a grand scale, as Marc has described), they don't yield to distributed end-to-end auditing of the code, from source to object. With the ability to compare the code at each end of the build toolchain, perhaps subcommunities of interest will have more incentive to share details of their more specialized efforts: So they can groom each other for bugs in the build environment. -- Joe On ceding power to tech companies: http://xkcd.com/1118/ man screen | grep -A2 weird A weird imagination is most useful to gain full advantage of all the features. _______________________________________________ Do not Cc: anyone else on mail sent to this list. The list server is set for maximum one recipient. linux-elitists mailing list linux-elitists(a)zgp.org http://zgp.org/cgi-bin/mailman/listinfo/linux-elitists ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"
by Eugen Leitl 08 Sep '13

08 Sep '13

----- Forwarded message from Jimmy Hess <mysidia(a)gmail.com> ----- Date: Sun, 8 Sep 2013 10:04:36 -0500 From: Jimmy Hess <mysidia(a)gmail.com> To: Eugen Leitl <eugen(a)leitl.org> Cc: cypherpunks(a)al-qaeda.net, info(a)postbiota.org, zs-p2p(a)zerostate.is, NANOG list <nanog(a)nanog.org> Subject: Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" On Sun, Sep 8, 2013 at 9:07 AM, Eugen Leitl <eugen(a)leitl.org> wrote: > 1. [...] In general the consuming public cannot tell the > difference between “good stuff” and snake oil. So when presented > with a $100 “good” solution or a $10 bunch of snake oil, guess > what gets bought. Or there might be 2 good solutions for certain security functions around $100. And 10 different flavors of $90 snake oil,and plenty of $50, $100, and $120 snake oil flavors. The world is full of salespeople and marketers; and the snakeoil salespersons are just as great as the "good stuff" salespeople ---- also, with more resources to devote to sales, than engineering; the snakeoil salespersons have more time and resources available to look at their competitors' merchandising, and make the snakeoil bottles on the store shelves are the ones that look the most appealing to the potential buyers. A wary buyer should not believe the salesperson, but demand a thorough long-term critical review (a 30 day demo of some product is not sufficient duration to discover that it's totally bunk). 2. Security is *hard*, it is a negative deliverable. You do not know > when you have it, you only know when you have lost it (via > compromise). It is therefore hard to show return on investment > with security. It is hard to assign a value to something not > happening. > This is because it doesn't make sense to say that security itself has a ROI in the first place. IT security is risk management --- therefore, in isolation security means nothing: security is a way of mitigating fundamental risks that are improbable events that are nevertheless certain to happen eventually (given enough time) that have an average negative ROI. There is a fundamental tradeoff between risk and return: If you spend NO money on security, lawyers, to help structure the business to avoid liabilities, and other protections such as insurance then you INCREASE return; in the short term, you will most likely have much greater profit, if you don't bother with any insurance, lawyers, or security. It all works fine, until there is a disaster, someone files a lawsuit, or you have a breakin. For example: by not purchasing insurance on your business assets; you avoid spending insurance premium dollars. This increases how much money you make (your return), as long as nothing bad happens. However, not buying insurance, or not paying the costs of security greatly increase the risk that the business incurs a loss because something bad happens. Furthermore, spending a lot of money on security reduces return, BUT also reduces the risk. Security does not have a ROI, but it does have a tradeoff. That tradeoff should be understood using the language of risk management, not profit/loss. And there is no reason people can't understand that.... after all; they do understand, what happens if you don't pay lawyers to help your enterprises comply with the law, or draft successfully binding contracts. You should expect to spend amounts on security per year, commensurate with the costs of insuring those data assets against the liability that would be incurred if they were tampered with or leaked to the public; granted, plenty of orgs are much more likely to have an internet-based security breach than a fire or a flood, therefore, the risk you take on by not spending on security is possibly a larger risk. 2a. Most people don’t really care until they have been personally > bitten. A lot of people only purchase a burglar alarm after they > have been burglarized. Most people purchase homeowners' insurance. Vehicle insurance is mandated by the state in many cases. I wonder if someday; a similar per-PC mandatory purchase will someday be required for computer security. > 3. As engineers we have totally and completely failed to deliver > products that people can use. I point out e-mail encryption as a > key example. With today’s solutions you need to understand PK and > PKI at some level in order to use it. That is likely requiring a > driver to understand the internal combustion engine before they > can drive their car. The real world doesn’t work that way. Yes. This is a total nightmare. Before Joe consumer can send an encrypted mail; he has to either go to some command line and gpg --gen-key or go to Xyz CA corporation, buy a personal SSL certificate for some expensive per-year premium $10 or more... and then go through a lot of trouble to figure out how to import that into the browser, and manually repeat this process every 1 to 3 years that his certificate expires; the process Joe has to go through to S/MIME enable every copy of his mail client on all his different computers, and his webmail provider, is even more complicated. Before anyone can send Joe an encrypted message; Joe somehow has to get all his correspondents to manually import a copy of his certificate. This is clearly miles outside the realm of possibility for the average Windows user. > -Jeff > -- -JH ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0