- cypherpunks - lists.cpunks.org

[guardian-dev] Perception of cryptography being to complicated to use...
by Kai Krueger 28 Oct '13

28 Oct '13

Hello everyone, you have likely all heard about the scandal regard the NSA listening in on calls of various heads of states, particularly that of the German Chancellor Angela Merkel's phone. What ever your opinion might be regarding the issue of bugging phones of friendly partner nations politician and whether you may consider it as "normal and everyone does it" or "unheard of", there seems to be another dimension to the scandal that I think might be of interest to this list. Although I don'… [View More]t think there are yet enough information publicly available to say what actually happened and what phones exactly were effected, but all indications appear to point to that it wasn't the Chancellors highly secured official government phone, but a private party phone that she uses all the time. Again, I am not aware of details yet of how that phone was secured, but media reports appear to suggest it might have been a standard smartphone using entirely unsecured plain phone lines and text messaging. So despite the German government spending 10s of millions of Euros to develop and purchase highly secure phones, it appears many of the ministers aren't actually using them. Indeed, the German secretary of commerce (Philip Roesler) was supposedly quoted as saying "Everyone knows that we are using our private phones, despite it being illegal" [my own translation from an indirect quote in German]. The media have so far mostly given as explanations for this astounding ignorance towards the risks of data security amongst politicians to be due to the "complicated and tedious procedures" involved in using cryptographically secured communications channels. The media are writing about how terribly complicated and inconvenient using secure phones are and I have read claims that e.g. the security features add latency of up to 1s or more and one has to "learn how to speak correctly to overcome such high latencies". Furthermore, because secure phones are so expensive (several 1000s of Euro's per phone), "no one" has them and because obviously both communications partners need them, secure phones are "close to useless". None of these claims and news articles are likely to help get more people to secure their electronic communication. Unfortunately, I haven't seen the main stream media ever talk about some of the great software out there like that of the guardian project, and that e.g. using CSipSimple or Jitsi via ostel to get an encrypted phone call is actually really pretty simple. Or how TextSecure or ChatSecure allow to use encrypted messaging with very little additional overhead. Do people know if there are efforts underway to try and counter this general impression of "cryptography is too hard and cumbersome to use"? And try and convince the media to report more positively about the available tools to secure ones communication? Are there other ways to influence public opinion that cryptography isn't that difficult to use and it is worthwhile doing? And that thanks to various opensource projects there are various high quality, standards compliant / inter-operable solutions available at no extra cost? Kai _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/eugen%40leitl.org You are subscribed as: eugen(a)leitl.org [View Less]

1 0

hide & seek (url)
by brian carroll 28 Oct '13

28 Oct '13

(potentially lots of relevance here to security issues, esp perhaps mimicry, limits or parameters, insecurity via looped evaluation of shared technique...) 1-Trick Chameleon: Predators Learn to See Through Camouflage // via digg http://nautil.us/blog/1_trick-chameleon-predators-learn-to-see-through-camo… "...the researchers found that it took their participants longest to spot the [prey] when they were using disruptive coloration rather than the other strategies, and that was especially true … [View More]

1 0

[tor-talk] x.509 for hidden services
by Gregory Maxwell 28 Oct '13

28 Oct '13

==Background== (you can skip to the Tor section if you don't care) The Bitcoin universe is in the process of creating a specification for digital invoices called "the bitcoin payment protocol". (More info: https://bitcointalk.org/index.php?topic=300809.msg3225143#msg3225143) The payment protocol allows someone to request someone else pay Bitcoin for specific things, instructing them to pay specific amounts in specific ways, and allows the receiver to provide things like instructions for … [View More]sending a refund if the transaction is for some reason aborted... all sorts of extra metadata which doesn't belong in the public Bitcoin network for scalability and privacy reasons. One of the things these invoices have is an optional signing mechanism for authentication and non-repudiation. Normally these requests would be sent over an authenticated and encrypted channel which provides confidentiality and authentication, but not non-repudiation. The non-repudiation will provide cryptographic evidence to the participants which can be used to resolve disputes: e.g. "He didn't send me my alpaca socks!" "Thats not the address I told you to pay!" "He told me he'd send my 99 red-balloons, not just one!" "No way, that was the price for 1 red-balloon!" The payment protocol is extensible and may someday commonly support many kinds of signatures, but the initial implementations only support signing with internal x.509 certificates and verifying those certificates with standard CAs. As _horrible_ as this is, it's better than nothing, and the primary users asking for this functionality have SSL websites today. We don't believe that any other PKI mechenism is actually functional enough to be usable (e.g. as evidenced by the fact that downloads of our GPG signatures, is on the order of 1% of the downloads of the Bitcoin software; and probably only a small portion of those users have actually done anything to verify the signing keys) today, so other options haven't been a priority. However, the need to use the known insecure CA infrastructure for this (optional!) feature has seriously spazzed out some people. A lot of this is pure confusion, e.g. people thinking that all payment requests would have to go via the CA (no kidding!), but its surprisingly hard to convince people who are responding emotionally of the subtle tradeoffs involved especially when they have the luxury of saying "it's your problem to go figure out, figure it out and go write a bunch extra of software for me". So having some alternative on day one would be useful in helping the more conspiracy minded understand that this isn't some effort to cram the use of CAs down their throat. ==Where Tor comes in== One of the downsides if using x.509 certs to non-repudiate here is that sites hosted as tor hidden services can't participate. It occurred to me that this could be fixed with very little code: Take the HS pubkey, pack it into a self-signed x.509 cert with the cn=pubkeybase32.onion. And specify that .onion certs have a special hostname validation rule that hashes and encodes the key. Then the whole process would work for .onion, we'd have a non-CA option available and working, etc. I'm aware that HS pubkeys have been used for application level authentication in Tor elsewhere (e.g. I believe torchat does this) so it's not entirely unprecedented. I'm not aware of anyone packing them in x.509 certificates. If anyone has, I'd like to use the same encoding style for greater compatibility. The biggest reason I can see not to do this is that it will not be compatible with future editions of hidden services which aren't based on RSA keys. (e.g. the EC point addition stuff to protect against enumeration attacks wouldn't fit into this model). I don't think this is a serious concern: if HS x.509s do become widely used we could add a new authentication type for the new onion addresses when those are introduced. Does anyone else see any other reasons not to do this? Are there other applications which would benefit from having x.509 certs for onion names? -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk [View Less]

3 3

[liberationtech] A Public Statement Regarding Ubiquitous Encryption on the XMPP Network
by Moritz Bartl 28 Oct '13

28 Oct '13

-------- Original Message -------- Subject: [jdev] TLS Everywhere Date: Sun, 27 Oct 2013 21:23:08 -0600 From: Peter Saint-Andre <stpeter(a)stpeter.im> Reply-To: Jabber/XMPP software development list <jdev(a)jabber.org> To: jdev(a)jabber.org Almost 15 years have passed since my friend Jeremie Miller released the initial version of the jabberd IM server, launching the Jabber open-source community and the technology we know today as XMPP. Yet, all that time, hop-by-hop encryption … [View More]

1 0

Re: [Cryptography] BitMessage?
by Keyfur 28 Oct '13

28 Oct '13

That would get extremely bulky in mass-adoption, in both local storage and network usage. Currently they have some structure to create tiered "streams", but that still doesn't eliminate the excessive network burden, it just saves some disk space. The streams work in a hierarchy, with the uppermost assuming the highest network burden. Because it's necessary to send an acknowledgement message, a complete circuit must established (though not all at once) between nodes. Also "broadcast messages" … [View More]

1 0

Re: [Freedombox-discuss] Dumb idea: Alternative to Tor that promotes good behavior
by Daniel Kahn Gillmor 28 Oct '13

28 Oct '13

On 10/27/2013 01:26 PM, Bill Cox wrote: > Here's the problem: Tor has little public support, because most Tor > traffic is wasted on supporting bad behavior. I don't think that's the main reason Tor has little public support. I think Tor has little public support because using Tor is slower and less convenient than not using Tor, and people (at least in the USA) seem to value convenience above most other things. > Here's my solution: Build a Tor-like network for routing anonymous … [View More]data, > but track behavior of all users' secret identities, and make their > Internet history public. Allow node operators to choose categories of > public identities they which to support. This would not be anonymous data. You're asking people to publish their full internet histories for the privilege of being able to use the network. Are you aware of the work being done toward de-anonymization of rich data sets? I think many people's web browsing habits alone would be sufficient to discover their physical identity with relatively high certainty. Even if we were to assume that the data was not possible to tie back to someone's physical location to put them in harm's way, if their network use patterns are how they do their activism, then publishing their network use patterns provides an adversary with a lot of information that is very helpful to disrupt this same activity (e.g. "Which web sites do they usually use to distribute their [tools|analysis|incitements]? Which chat channels do they frequent? Where/how do they get their e-mail? Can we destroy or subvert those services?) > For example, I would choose to promote all forms of non-violent free > speech. I should be able to contribute my bandwidth to this purpose. > If a dissident in China goes by the public ID of ChinaCat, and has a > high reputation for promoting freedom, they are welcome to use my > bandwidth. If someone just wants access to redtube.com, they can get > that access from someone else. If you prefer this, then you should personally make arrangements with ChinaCat directly. I'm not convinced that you could ever make such an arrangement scale cleanly without gross oversimplifications that wouldn't meet many people's assumptions about what the terms mean. Is a sit-in at a restaurant "non-violent free speech"? What about a work stoppage at a factory? how about when the workers barricade the factory against its owners? What about people who sabotage or destroy machinery in their factory? What about destruction of machinery that is prepared to destroy desparately needed housing stock? What about people who smash the windows of low-wage corporate franchises? What about smashing the windows and doors of fire-prone sweatshops? Are all of these things non-violent free speech? can you imagine that someone else might have a different answer for any of them than you do? > There are various technical aspects to this idea. For example, would > prefer that the social graph between secret identities be public so I > can use a simple network flow algorithm over trust edges between > identities to determine how much I trust someone. I think it would be worthwhile to spec out such an algorithm, and then think through the spec under a handful of real-world use cases. what does it mean to do "network flow over trust edges"? What specifically does "trust" mean in this context? Can you give an example of how that would let you automatically determine how much you trust someone? What does that kind of automated trust discovery mean from a human perspective? What are the ways it could be exploited by an adversary intent on causing trouble? sorry to be a pessimist, but i'm not convinced this is an effective or even desirable framework. --dkg _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss [View Less]

2 1

Re: [tor-relays] Filtering TOR Non-exit Relay - Just Curious
by Zack Weinberg 27 Oct '13

27 Oct '13

Lukas Erlacher <l.erlacher(a)gmail.com> wrote: >> Middle nodes don't know the type of traffic. If they have any way >> to find out, that is a bug that needs to be fixed. End-of. Packet timing analysis may be able to tell you *something* -- this is part of my current research project, ask again in six months :-) Mr. Nelson Laurenti wrote: > I didn't say I knew the type of traffic on my relay, that would be an > entirely new set of problems; I said I can see the IP … [View More]

1 0

Re: [Cryptography] [RNG] /dev/random initialisation
by John Denker 27 Oct '13

27 Oct '13

On 10/24/2013 02:42 PM, Sandy Harris wrote: > What I want to model here is the harder case where none of the above [sources for a good high-entropy seed] > is in place or urandom starts producing output without waiting for > them. In an ideal world, this case would never arise but in the real > world it has and likely will again. This is excellent. This is exactly the sort of discussion we ought to be having. > The problem involves avoiding > duplicate outputs, so the … [View More]birthday paradox works against us. If we > need a low risk of collision for 2^n cases, then we need about 2n bits > of input entropy. I agree with the sentiment, but having lots of entropy isn't the only way of solving the problem; we can make do with a lot less entropy if it is /computationally infeasible/ for the attacker to untangle what we have done. > There are two separate cases to consider: avoiding duplicate outputs > when a single device is rebooted many times and avoiding it when many > identical devices are deployed. OK, good. > Multiple reboots of the same device are the easy case. One threat > involves a computer that is rebooted often (perhaps several times a > day) and whose outputs are monitored continuously over a fairly long > period (perhaps a year). Another involves an enemy that can force many > reboots of a network device without the administrators noticing and > blocking the attack. Neither threat looks at all likely to involve > more than a few thousand reboots, so a dozen or so bits of timing > information per reboot should be enough to block them. It may help to add a little bit more detail to that analysis. There are two subcases: a) The PRNG starts out in a good state, with a seed that is large enough, random enough, and unknown to the attacker. If we now use the real-time clock (RTC) to /stir/ the seed, that should be sufficient to guarantee no collisions. That should be enough to stop replay attacks. b) If the PRNG starts out in a bad state, because the seed has been compromised, then the PRNG cannot quickly recover, and in particular it cannot recover while it is under attack. The RTC is nowhere near sufficient to /substitute/ for a proper seed. To say the same thing in slightly different words: There are two separate objectives that we need to consider: A) Resistance to attack, and B) Recovery from compromise. In some rock-candy world it would be nice to do both at the same time, but in this world, there are situations where a practical PRNG cannot do both at the same time, and that's OK. The moral of the story is that it is super-important to make sure the PRNG is properly seeded. The seed needs to be big enough, random enough, and unknown to the attacker. Note that the RTC does not add real entropy to the PRNG. All it does is stir the PRNG. Assuming the PRNG's hash function is working properly, (seed + RTC1) should be effectively very different from (seed + RTC2). The attacker could try to mount a related-plaintext attack against the hash, but for any decent cryptologic hash this should be computationally infeasible. There is a fundamental conceptual distinction between (a) reseeding the PRNG with honest-to-goodness entropy and (b) merely stirring the existing seed. However, there are some situations in which stirring suffices. > Timing data appears to be the only thing we can use against this > threat; more-or-less everything else is constant across reboots. Linux > random already mixes in some timing information, but I am not certain > how much. It shouldn't take much stirring, assuming the hash function is working properly. We absolutely require that the RTC produce non-repeating values, but that's about all we really require. Again, this is all predicated on starting with a high-quality seed. > Many identical devices are a harder case. I hate to sound like a broken record, but the solution is the same in all cases: You need a proper seed: big enough, random enough, and unknown to the attacker. > A manufacturer might produce > tens or hundreds of thousands of the same device The manufacturer reeeeally needs to provision each instance of the device with a proper seed. The cost of doing this is ridiculously small. The manufacturer already needs to provision things like the MAC address, hostname, IMEI, et cetera ... and the addition burden of provisioning the seed for the PRNG is negligible. > a Linux distro > might send out some huge number of installation images; Again (!) the solution is the same: If there is a proper seed, you're fine. If there is not a proper seed, you're screwed. Specific suggestion: a) Download the .iso image onto disk. b) Provision a proper seed onto the image. c) Burn the modified image to CD if desired. A few years ago I cooked up some tools to do exactly this. I tried to get support for it installed into the distributions, but the proposal was shot down by some "expert" who decided that the RTC was sufficient security, even if every attacker on earth knew what was in the distributed seed-file ... and even if every attacker on earth knew what time it was. More general suggestion: We ought to produce some sort of "Best Practices" document that explains to manufacturers, software distributors, VM providers, et cetera how important it is to provision a proper seed, and explains how to do it. We should also provide tools and infrastructure that makes it easy to do the right thing and hard to do the wrong thing. For example, in the general case, unpacking and repacking an .iso image is a pain in the neck, but if the image is engineered to facilitate rewriting the seed-file the procedure is much, much simpler. ================================== Following up on a proposal by Jerry Leichter, on 10/25/2013 05:15 AM, John Kelsey wrote: > I like this idea. If my PRNG is in a secure state, I can give out > random numbers to anyone who asks. I like this idea so much that I implemented it many years ago. The command line looks roughly like: lynx -auth=harpo:swordfish -source 'https://example.com/pvt/random?bytes=512' | randomize kernel from - > At first startup, it won't be > possible to establish a secure connection yet (no entropy), I disagree; see below. > but by > asking some hosts for a random number, we ensure that if those > messages aren't recorded, the attacker can't possibly guess our PRNG > starting state. Again (!) the key is to have a proper seed stored on the machine in question. It's like the proverbial seed-corn: If you have none, you're screwed. If you have some, you can grow more. On 10/24/2013 07:59 AM, John Kelsey wrote: > a. Get 256 bits of entropy from the OS. > b. Get 256 bits of entropy from the hardware entropy source. > c. Ping several hosts on the internet and measure the response time, and fold that into your seed. > d. Fold your ethernet address, IP address, and serial number into the seed. > e. Fold the installed-at-birth secret 128 bit value from your device into the seed. > > Initialize a PRNG with all that, and the attacker is in an extremely > hard place, as he has to be able to guess all five elements. (d) > isn't all that hard to guess, but the rest will in general be very > hard to guess. Some comments: a) If you have 256 bits of honest-to-goodness entropy from /any/ source, OS or otherwise, then that's more than enough to seed the PRNG, and nothing on the list matters. b) Ditto. c) Not so good. Ping times are not guaranteed to be always different, and not guaranteed to be unknown to the attacker. In the crypto business it is conventional to worry about MITM attacks. A scenario where the MITM doesn't need to mess with the packet contents, just the packet timing, is extra-easy for the attacker. d) Not so good. All that stuff is constant, and relatively easy for the attacker to know or guess. The RTC wasn't mentioned, but it is better than the items that were mentioned, in that it is at least non-constant and non- repeating. The RTC cannot /substitute/ for a proper stored seed, but it can /stir/ the seed. e) That's basically the right idea, except that we should call it the "stored" seed rather than the "at-birth" seed. The stored seed should be changed at frequent intervals. This helps with the recovery from compromise. Perhaps more importantly, it reduces the window of vulnerability and reduces the value the attacker gets from peeking at the stored seed. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography [View Less]

1 0

[tor-talk] PrivateCore Demonstrates Industry’s First PRISM-Proof Tor Server in Public Cloud
by Pokokohua 27 Oct '13

27 Oct '13

Saw this ad/news item on another list ------------------------------------------------------ PrivateCore Demonstrates Industry’s First PRISM-Proof Tor Server in Public Cloud PrivateCore, the private computing company, today demonstrated the first cloud Tor server protected from NSA PRISM-like programs by fully encrypted memory. The company deployed a Tor server protected by PrivateCore vCage software to a dedicated server hosted by infrastructure-as-a-service provider SoftLayer. Tor directs … [View More]Internet traffic through a free, worldwide volunteer network consisting of more than three thousand relays to maintain the anonymity of a user’s location or usage. This PrivateCore Tor deployment provides undeniable evidence that organizations can achieve private computation in the public cloud. Without vCage full memory encryption, Tor servers operating in hosted provider environments expose secret key material in memory, where it can be accessed through NSA PRISM-type programs. Using PrivateCore vCage, no trace of Tor server code or data is maintained in memory or on disk, eliminating the possible exposure of secret key material through memory forensics. As demonstrated by the NSA PRISM program, information owned by an organization can be handed to authorities without their knowledge by cloud service providers who control the cloud servers. While organizations need to respond to lawful requests for information such as the NSA PRISM program, PrivateCore vCage enables them to remain in control of servers in the cloud and prevent access without their prior authorization. Click to Tweet: .@PrivateCore vCage memory #encryption software enables #PRISM proof Tor server http://bit.ly/1gCCkMP “PrivateCore vCage is a very important step forward for cloud security that uses a brilliant design created by experts who really know what they are doing,” said Felix “FX” Lindner, Head of Recurity Labs a leading security consultancy based in Germany. Service providers and enterprises face growing risks of physical access to sensitive data through the proliferation of outsourced IT infrastructures in untrusted environments including the cloud, co-location facilities and remote sites. Sensitive data-in-use is subject to compromise due to lawful requests, such as the recently disclosed NSA PRISM program, as well as illegal compromise. For example, state actors can target server memory which typically contains sensitive information such as digital certificates, encryption keys, intellectual property and personally identifiable information. While sensitive data may be protected by encryption while at rest or in transit, it is unprotected and “in the clear” while in use. PrivateCore’s unique vCage software encrypts data-in-use without requiring application or hardware modifications. “The NSA PRISM program has raised concerns around the world among organizations considering deploying sensitive data in the public cloud. This proof of concept shows that data in the public cloud can remain under the control of the owner under any circumstance,” said Oded Horovitz, CEO of PrivateCore. “Protecting data-in-use has been a challenge in security sensitive industries for years, but hardware advances such as larger processor caches have enabled PrivateCore to develop an innovative platform that shrinks the hypervisor into the CPU to secure data even in memory.” -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk [View Less]

1 0

[cryptome] Re: Obama vs Merkel
by coderman 27 Oct '13

27 Oct '13

On Sun, Oct 27, 2013 at 4:16 AM, John Young <jya(a)pipeline.com> wrote: > Hard to believe the DE spies did not know of spying on Merkel > perhaps assisted it as part of their own spying on her,... this entire fiasco manufactured - ongoing dilution and castration of the leakage. impact and relevance continually declining from piece to piece. one of many legitimate cries for wide distribution of the entire archive! this phone spy posturing a particularly irrelevant sacrificial … [View More]

1 0