Re: [liberationtech] Whatsapp, a Trojan horse for seekers of easy privacy?
On Fri, Jan 16, 2015 at 02:12:38PM -0800, Al Billings wrote:
>
> > On Jan 16, 2015, at 2:07 PM, Leif Ryge wrote:
> >
> >
> > I did see two answers earlier, Iceland and Switzerland. There are many
> > other countries besides those two where it also seems very unlikely that
> > companies would be subjected to the sort of legal orders that we now know
> > US companies routinely receive. That obviously doesn't mean that TAO or
> > GCHQ's equivalent won't try to compromise them without their knowledge, but
> > that approach is obviously a much riskier and less reliable than the legal
> > means used in the US.
>
> What makes you think Iceland and Switzerland don’t have security and
> intelligence services that could have legal orders issued or that
> occasionally cooperate internationally with other organizations? Is it simply
> because Wikileaks managed to be in Iceland for quite a while?
>
> Al
Secret orders requiring technology companies to help spy on their customers are
unheard of in many countries, and something that would cause significant
public outrage were they found to exist, but they're something we've known
about in the US for at least a decade (long before Snowden or Wikileaks).
I'm sure similar orders exist in places where we don't know about them, but
given the possibility of leaks that each secret order entails I maintain that
it seems unlikely it's happening on a large scale in places like Iceland.
But, given that we can't prove that negative, it is obviously necessary to
remove single-points-of-failure in our software distribution systems.
Deterministic builds (with independent signers of each build in many legal
jurisdictions) and recording releases in public append-only logs (with notaries
in many different legal jurisdictions) are the two ways that I know how to
solve this problem. Either is good, and doing both would be better.
Hopefully in a few years everything will work that way. Probably the NSA will
try to sabotage some standards along the way, but I'm optimisitic that they'll
fail. However, until that reality exists, where we don't need to rely on
("trust") single entities to authenticate our software updates, I think
preferring to rely on 3rd parties in non-US countries is hardly unreasonable.
~leif
--
Liberationtech is public & archives are searchable on Google. Violations of
list guidelines will get you moderated:
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe,
change to digest, or change password by emailing moderator at
compa...@stanford.edu.
Re: [liberationtech] Whatsapp, a Trojan horse for seekers of easy privacy?
On Fri, Jan 16, 2015 at 01:37:12PM -0800, Al Billings wrote: > > > On Jan 16, 2015, at 12:18 PM, carlo von lynX > > wrote: > > > > Al, you may want to deviate the discussion towards the 10.000th debate > > about proprietary vs free software, but the topic here is the impossibility > > for a U.S. company to deliver what it promises. > > And I asked, and got no answer, as to which nation a company could be in and > not be just as potentially compromised. I’m still waiting for a substantive > answer. > > Al I did see two answers earlier, Iceland and Switzerland. There are many other countries besides those two where it also seems very unlikely that companies would be subjected to the sort of legal orders that we now know US companies routinely receive. That obviously doesn't mean that TAO or GCHQ's equivalent won't try to compromise them without their knowledge, but that approach is obviously a much riskier and less reliable than the legal means used in the US. As to the proprietary software issue, while I personally recommend using only free software, at least one of the solutions to the problem of targetted malicious software updates applies equally well to both: record hashes of all released binaries in a decentralized append-only log so that users can at least be reasonably sure that they're running the same thing as everyone else. (There are several efforts underway in this direction.) ~leif -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Meet the 'cowboy' in charge of the NSA
On Mon, Sep 09, 2013 at 06:50:05PM +0200, Al Billings wrote: > Have fun tilting that windmill, Mr. Quixote. > > Like it or not, to fully use websites at this point, you generally need > things like Javascript and CSS. The reason that most folks, even security > folks like the ones I work with, don't run with NoScript on all the time is > that it breaks the net as experienced. Lots of people do run with NoScript configured to deny by default. It is hyperbole to say that the seconds it takes to wait for a page to reload after clicking "temporarily allow scripts from example.com" constitutes breaking the net. (And of course, I do permanantly allow a few sites that I use frequently.) Many sites like the washington post have javascript coming from a hilariously large number of domains, only a few of which actually need to run to do something like viewing the PDFs they embed via documentcloud. In those cases, it can take a few more seconds to decide which domains seem likely to be the ones necessary to enable, but if you're in a hurry you can just "temporarily allow all this page". NoScript also not infrequently actually improves my browsing experience, as it did in the case of the FP article this thread was about: when I read the article, I didn't have any reason enable any scripts, so I didn't even know about their irritating overlay until I read the complaints about it here. ~leif -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Meet the 'cowboy' in charge of the NSA
On Mon, Sep 09, 2013 at 10:15:02AM -0400, liberationt...@lewman.us wrote: > On Mon, 09 Sep 2013 11:23:30 +0200 > Axel Simon wrote: > > > Am I the only one for whom the page is hidden behind an > > annoying "sign up" overlay? > > If you disable javascript for the site there is no overlay. If you > selectively block javascript from anything not fp.com, the overlay > doesn't load either. Trusting users with your revenue model seems > an odd choice to me. I'm kind of surprised FP's javascript is the main topic of discussion around this article. Doesn't anyone want to talk about the Army Intelligence and Security Command's Information Dominance Center being designed to mimic the bridge of the Starship Enterprise? Or that Keith Alexander wanted to do domestic surveillance when he was working there, too, and "said at one point that a lot of things aren't clearly legal, but that doesn't make them illegal"? Or that Rasmussen polls found 68 percent of respondents now believe it's likely the government is listening to their communications and 57 percent said they think it's likely that the government will use NSA intelligence "to harass political opponents."? No? Ok, well as long as we're talking about that FP javascript overlay: if you saw it, that means you run JavaScript by default, which means you're vulnerable to a larger number of the arbitrary-code-execution bugs in your web browser (of which there are undoubtedly many more which are not yet fixed, given the frequency with which new ones are discovered [1,2]). In my opinion, if you're using Firefox, you should really be using NoScript. [3] ~leif ps: Thank you FP and Shane Harris for this very informative article! 1: https://www.mozilla.org/security/known-vulnerabilities/firefox.html 2: http://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/opec-1/Google-Chrome.html 3: http://noscript.net/ -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Random number generation being influenced - rumors
The NYT article doesn't explicitly say they've backdoored hardware RNGs, but it separately says they've backdoored hardware somehow and and are recovering keys somehow: > By this year, the Sigint Enabling Project had found ways inside some of the > encryption chips that scramble information for businesses and governments, > either by working with chipmakers to insert back doors or by exploiting > security flaws, according to the documents. [...] > N.S.A. documents show that the agency maintains an internal database of > encryption keys for specific commercial products, called a Key Provisioning > Service, which can automatically decode many messages. If the necessary key is > not in the collection, a request goes to the separate Key Recovery Service, > which tries to obtain it. > > How keys are acquired is shrouded in secrecy, but independent cryptographers > say many are probably collected by hacking into companies’ computer servers, > where they are stored. Sure, the Key Recovery Service might sometimes involve "hacking into companies’ computer servers". But, if they're in the business of inserting hardware backdoors, going after RNGs seems like one of the most obvious things to do because they could use those backdoors passively without risk of being caught. There is a lengthy ongoing discussion right now between Theodore Ts'o (maintainer of Linux's /dev/random) and David Johnston (designer of Intel's RDRAND) about using RDRAND directly vs mixing it into Linux's entropy pool: https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J Here are a few highlights: David Johnston: > I've examined my own RNG with electron microscopes and picoprobes. So I and a > number of test engineers know full well that the design hasn't been > subverted. For security critical systems, having multiple entropy sources is > a good defense against a single source being subverted. But if an Intel > processor were to be subverted, there are better things to attack, like the > microcode or memory protection or caches. [...] > I understand that I'm in the privileged position of being able to understand > and examine my own design, where most people cannot. What I would like is for > people to stop presenting the straw-man argument that the government leant on > someone, so they must have subverted my RNG design. I would like (and we've > made this argument to the kernel developers) that there should be a policy > option so people can choose to benefit from the hardware they paid for and > choose to trust, or can decide to be more conservative and require the kernel > to mix more sources. Theodore Ts'o: > I never said that the NSA had definitely subverted your design. Just that it > is prudent and responsible to acknowledge that they might have done so, and > so we need to make sure the Linux kernel is robust against that kind of > failure. And remember, the random driver is generic code. Even if Intel is > clean, maybe AMD, TI, or Qualcomm were successfully leaned on by the US > Government, and their chips are dirty. We don't know, and we can't know. > > As far as making it be an option to the user, I fail to see the benefit. If > you can't trust the kernel because the attacker can read arbitrary kernel > memory, you're doomed anyway. But unlike the proprietary intel chip, at > least it's possible to audit the kernel to look for security breaches. [...] > If I were the NSA, I'd much rather compromise RDRAND, and then try to > convince people that it's safer and faster to just use the raw RDRAND when > creating session keys for IPSEC and GPG and VPN's. You wouldn't need to get > compromised code into the target machines, other getting out a meme out to > developers that using the output of RDRAND directly as a session key was > somehow "best practice". Wouldn't that be much easier than introducing a > vulnerability into the page table handling, especially if the goal is to do > bulk data collection, dragnet-style? -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
