- cypherpunks - lists.cpunks.org

US State Of California to Ban Encrypted Screenlocked Phones and Devices
by grarpamp 22 Jan '16

22 Jan '16

http://asmdc.org/members/a09/news-room/video-gallery/cooper-introduces-huma… https://news.ycombinator.com/item?id=10949354 (Sacramento) – Assemblymember Jim Cooper (D-Elk Grove), along with the Sacramento County District Attorney’s office, crime victim’s families, and bill supporters, announced at a state capitol news conference the introduction of Assembly Bill 1681. The legislation will help law enforcement investigate and prosecute suspected criminals and criminal organizations that are involved in human trafficking and other serious crimes. In 2014, cell phone manufactures began providing new operating systems for smartphones and tablets, these new operating systems employ, by default, “full-disk encryption” (FDE). That can be a problem for law enforcement investigators. “Human traffickers are using encrypted cell phones to run and conceal their criminal activities,” said Assemblymember Cooper. “Full-disk encrypted operating systems provide criminals an invaluable tool to prey on women, children, and threaten our freedoms while making the legal process of judicial court orders useless.” Learn more about AB 1681 in this Assembly Access video.

1 0

European Court of Human Rights about Bulk Surveillance aka Big Data aka Massive Monitoring
by grarpamp 21 Jan '16

21 Jan '16

On Tue, Jan 19, 2016 at 12:25 AM, <tor_talk(a)arcor.de> wrote: > Hi Tor Talkers, > > January 13, 2016 > https://cdt.org/blog/did-the-european-court-of-human-rights-just-outlaw-mas… > Did the European Court of Human Rights Just Outlaw “Massive Monitoring of Communications” in Europe? > December 9, 2015 > https://www.justsecurity.org/28216/echr-deals-heavy-blow-lawfulness-bulk-su… > European Human Rights Court Deals a Heavy Blow to the Lawfulness of Bulk Surveillance http://yro.slashdot.org/story/16/01/20/0348233/european-human-rights-court-…

1 0

libreboot not supporting post-2008 Intel hardware?
by Georgi Guninski 20 Jan '16

20 Jan '16

Got this from some forum. https://libreboot.org/faq/#intel --- Why is the latest Intel hardware unsupported in libreboot? #intel It is extremely unlikely that any post-2008 Intel hardware will ever be supported in libreboot, due to severe security and freedom issues; so severe, that the libreboot project recommends avoiding all modern Intel hardware. --- There are similar concerns about AMD from Joanna Rutkowska: http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf pp 44-45 Is there safe off the shelve hardware and sufficiently powerful? (Don't think android is an option) This is not intended as flamewar Intel vs AMD vs whatever.

3 5

FOIPA Glomar
by grarpamp 20 Jan '16

20 Jan '16

On Mon, Jan 18, 2016 at 11:26 PM, coderman <coderman(a)gmail.com> wrote: > a richer annotation of refusals would be useful. Let FOIA do the work for you... Annual count of all queries replied with "can neither confirm or deny / etc". Initial query date, query ID number, and query subject for all such replies.

4 3

Fwd: [whispersystems] Addressing Frustration in the Signal Community
by coderman 20 Jan '16

20 Jan '16

---------- Forwarded message ---------- From: Sam Lanning <sam(a)samlanning.com> Date: Sat, 16 Jan 2016 09:16:48 +0000 Subject: [whispersystems] Addressing Frustration in the Signal Community Hi All, I have noticed that there has been some amount of frustration present on this mailing list as of late, and I'd just like to address it as a an observer and member of the Signal Community. The popularity of Signal, and in particular the number of people who want to help get involved in the project, contribute, help influence the future of it etc... has been growing very impressively. We have just under 1000 people on this mailing list (967 at time of writing), multiple PRs and issues are being opened in the repos by newcomers each day, and we have prominent people in the security community (Edward Snowden, Various Tor People, George Torwell [1] etc...) constantly telling everyone to use Signal. It's clear why this is happening, Signal is the only project to have emerged that really has the potential to put a dent in mass surveillance since Tor, and I use the word "only" on purpose here; Yes there are a million different privacy apps / projects that have emerged in the last 4 years or so, and existing tools have been improved (we have the likes of Tox, Pond, Ricochet etc... And OTR and PGP are still going strong), but Signal has always put a very strong focus on Usability and User Adoption, and it's these things that have lead it to becoming as widely adopted as it is, and it's these things we need to continue to focus on more than anything until it becomes as popular as, for example, Whatsapp. This is why it has the potential to put a dent in MASS surveillance. But this is obvious to most of you, in fact it is probably these reasons that have got you so excited about the project, and why we have so many people getting involved in the development of Signal, and contributing in any which way they can. That being said, I feel that the community doesn't realise just how big it's growing, and how that contrasts with the size of the OWS team itself. I have so much respect for them, they are each being pulled in a thousand different directions: development, managing + reviewing contributions on github, responding to issues, responding to support tickets, addressing each of the feature requests that come in (and deciding which ones they can take on etc...), handling PR / marketing / social media, corresponding with large projects that want to get involved and increase growth that drastically change the requirements for the infrastructure, managing and growing the infrastructure itself, managing finances and donations, general admin stuff, and of course... this mailing list. Go have a look at their website, to see how big their team is, and how many people are working on development (and also understand that Frederic Jacobs has recently moved on and the website is yet to be updated)... Then look again at this list of things that they need to handle among themselves. Also consider how amazingly Moxie has run a tight ship, keeping strict control of the direction of the project, and fighting to maintain that. It's this strict process that has lead Signal to where it is today. We can't let the project grow beyond this control, this strict direction that is vital to the steady, consistent, continual growth and success of the project, it can't be diluted... and yet growth is the single most important thing we're currently fighting for. This team is insane. So I ask you, please don't get frustrated, I know it can be difficult, and it can feel like you're shouting into the void, but we still need you, the community still needs everyone who's currently involved to stay as involved as they can and support one another. The whispersystems team reads each and every one of the emails that come through this mailing list, as insane as that may sound given the rest of their work load... they just don't have time to respond to everything, and they leave it up to us to do much of that. We need to work together, as a community, to help the OWS team grow this project into something even more fantastic then it is currently, rather than just increasing their workload, and taking their focus away from important development work and decision making. We each need to take a step back, and make calculated contributions, and help to make their life easier any way we can. So where, as a community, can we go from here... Well, the single most effective thing you could do, if you really want to make a difference, and are able to work in San Francisco, consider applying to work full time at OWS [2]. They need designers and developers alike. If like me, you're not in San Francisco, or even the USA, then you can continue to contribute online. Keep the morale up and continue doing what you're doing. Direct newcomers in the right directions (mailing list, issues, support, docs, the unofficial server support google group, etc...), and spread the word and try and get as many people to adopt Signal as possible. As a community, we can probably do with some better coordination as to what each of us are doing, assigning ourselves development tasks, doing code review, handling responding to people, discussing design / feature requests, working out as a community which features / work we feel are most critical etc... Feature requests, however well intentioned, do fill up this mailing list quite a bit, but there doesn't really seem like there is a proper (public) home for them at the moment, issues should be focussed on bugs / minor feature requests only, and sending an email to this list sends it to almost 1000 people... not ideal. Perhaps there is the scope for some online space to handle / discuss feature requests / work in progress in an open manner? and perhaps allow the OWS team to be a little more transparent with the things they are currently working on etc... We could then also incorporate projects like the new windows phone initiative, and coordinate much more effectively? Anyway that's just food for thought, and probably best discussed another time. In the meantime, I'm probably going to write up some intro page for newcomers of the Signal community, to outline the landscape, and help direct their efforts. I'll post in here when that's done. Anyway, thanks for reading through this monster of an email! It was mostly a brain dump on my part. =) Oh! And make sure you watch the youtube video I linked below. Cheers, Sam --------- Links: [1]: https://youtu.be/c4EEa0HAqzQ?t=2m31s ^ watch this, really! [2]: https://whispersystems.org/workworkwork/

2 1

Fwd: [Cryptography] GCHQ's plan to backdoor encrypted phone calls
by Ben Mezger 20 Jan '16

20 Jan '16

-------- Forwarded Message -------- Subject: [Cryptography] GCHQ's plan to backdoor encrypted phone calls Date: Tue, 19 Jan 2016 19:03:25 -0800 From: Henry Baker <hbaker1(a)pipeline.com> To: cryptography(a)metzdowd.com FYI -- The whole article is too long to reproduce here; follow the link to read the whole article. https://www.benthamsgaze.org/2016/01/19/insecure-by-design-protocols-for-en… Insecure by design: protocols for encrypted phone calls The MIKEY-SAKKE protocol is being promoted by the UK government as a better way to secure phone calls. The reality is that MIKEY-SAKKE is designed to offer minimal security while allowing undetectable mass surveillance, through the introduction a backdoor based around mandatory key-escrow. This weakness has implications which go further than just the security of phone calls. The current state of security for phone calls leaves a lot to be desired. Land-line calls are almost entirely unencrypted, and cellphone calls are also unencrypted except for the radio link between the handset and the phone network. While the latest cryptography standards for cellphones (3G and 4G) are reasonably strong it is possible to force a phone to fall back to older standards with easy-to-break cryptography, if any. The vast majority of phones will not reveal to their user whether such an attack is under way. The only reason that eavesdropping on land-line calls is not commonplace is that getting access to the closed phone networks is not as easy compared to the more open Internet, and cellphone cryptography designers relied on the equipment necessary to intercept the radio link being only affordable by well-funded government intelligence agencies, and not by criminals or for corporate espionage. That might have been true in the past but it certainly no longer the case with the necessary equipment now available for $1,500. Governments, companies and individuals are increasingly looking for better security. A second driver for better phone call encryption is the convergence of Internet and phone networks. The LTE (Long-Term Evolution) 4G cellphone standard carries voice calls over IP packets, and desktop phones in companies are increasingly carrying voice over IP (VoIP) too. Because voice calls may travel over the Internet, whatever security was offered by the closed phone networks is gone and so other security mechanisms are needed. Like Internet data encryption, voice encryption can broadly be categorised as either link encryption, where each intermediary may encrypt data before passing it onto the next, or end-to-end encryption, where communications are encrypted such that only the legitimate end-points can have access to the unencrypted communication. End-to-end encryption is preferable for security because it avoids intermediaries being able to eavesdrop on communications and gives the end-points assurance that communications will indeed be encrypted all the way to their other communication partner. Current cellphone encryption standards are link encryption: the phone encrypts calls between it and the phone network using cryptographic keys stored on the Subscriber Identity Module (SIM). Within the phone network, encryption may also be present but the network provider still has access to unencrypted data, so even ignoring the vulnerability to fall-back attacks on the radio link, the network providers and their suppliers are weak points that are tempting for attackers to compromise. Recent examples of such attacks include the compromise of the phone networks of Vodafone in Greece (2004) and Belgacom in Belgium (2012), and the SIM card supplier Gemalto in France (2010). The identity of the Vodafone Greece hacker remains unknown (though the NSA is suspected) but the attacks against Belgacom and Gemalto were carried out by the UK signals intelligence agency -- GCHQ -- and only publicly revealed from the Snowden leaks, so it is quite possible there are others attacks which remain h idden. Email is typically only secured by link encryption, if at all, with HTTPS encrypting access to most webmail and Transport Layer Security (TLS) sometimes encrypting other communication protocols that carry email (SMTP, IMAP and POP). Again, the fact that intermediaries have access to plaintext creates a vulnerability, as demonstrated by the 2009 hack of Google's Gmail likely originating from China. End-to-end email encryption is possible using the OpenPGP or S/MIME protocols but their use is not common, primarily due to their poor usability, which in turn is at least partially a result of having to stay compatible with older insecure email standards. In contrast, instant messaging applications had more opportunity to start with a clean-slate and so this is where much innovation in terms of end-to-end security has taken place. Secure voice communication however has had less attention than instant messaging so in the remainder of the article we shall examine what should be expected of a secure voice communication system, and in particular see how one of the latest and up-coming protocols, MIKEY-SAKKE, which comes with UK government backing, meets these criteria. MIKEY-SAKKE and Secure Chorus MIKEY-SAKKE is the security protocol behind the Secure Chorus voice (and also video) encryption standard, commissioned and designed by GCHQ through their information security arm, CESG. GCHQ have announced that they will only certify voice encryption products through their Commercial Product Assurance (CPA) security evaluation scheme if the product implements MIKEY-SAKKE and Secure Chorus. As a result, MIKEY-SAKKE has a monopoly over the vast majority of classified UK government voice communication and so companies developing secure voice communication systems must implement it in order to gain access to this market. GCHQ can also set requirements of what products are used in the public sector and as well as for companies operating critical national infrastructure. ............. Conclusions and future work The design of MIKEY-SAKKE is motivated by the desire to allow undetectable and unauditable mass surveillance, which may be a requirement in exceptional scenarios such as within government departments processing classified information. However, in the vast majority of cases the properties that MIKEY-SAKKE offers are actively harmful for security. It creates a vulnerable single point of failure, which would require huge effort, skill and cost to secure -- requiring resource beyond the capability of most companies. Better options for voice encryption exist today, though they are not perfect either. In particular, more work is needed on providing scalable and usable protection against man-in-the-middle attacks, and protection of metadata for contact discovery and calls. More broadly, designers of protocols and systems need to appreciate the ethical consequences of their actions in terms of the political and power structures which naturally follow from their use. MIKEY-SAKKE is the lat est example to raise questions over the policy of many governments, including the UK, to put intelligence agencies in charge of protecting companies and individuals from spying, given the conflict of interest it creates. Update 2016-01-19: Fix broken links to GCHQ website, note that master key must be permanently available though not necessarily directly connected to the Internet, and mention suspicions that the NSA were involved in the Vodafone Greece compromise. The photograph above this article is of a AT&T TSD-3600E Telephone Security Device based around the Clipper key-escrow chip (© Matt Blaze). An edited version of this article will appear in the March 2016 special edition of IEEE Computer Magazine: Communications and Privacy under Surveillance. CC BY-ND 4.0 Insecure by design: protocols for encrypted phone calls by Steven J. Murdoch is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License. Published by Steven J. Murdoch Dr Steven J. Murdoch is a Royal Society University Research Fellow in the Information Security Research Group of University College London, working on developing metrics for security and privacy. His research interests include authentication/passwords, banking security, anonymous communications, censorship resistance and covert channels. He has worked with the OpenNet Initiative, investigating Internet censorship, and for the Tor Project, on improving the security and usability of the Tor anonymity system. His current research on developing methods to understand complex system security is supported by the Royal Society. He is also working on analysing the security of banking systems, especially Chip & PIN/EMV, and is Innovation Security Architect of Cronto, an online authentication technology provider and part of the VASCO group. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

effective and fully decentralized means we're all Fort Knox [was: Cryptsy theft->bankruptcy]
by coderman 20 Jan '16

20 Jan '16

On 1/19/16, dan(a)geer.org <dan(a)geer.org> wrote: > ... > Bitcoin Heist Steals Millions from Exchange full decentralization a double edged sword, for sure. if we're all sovreign bankers and multi-national producers, perhaps Snowden threat model not so outlandish? first disable passive Eve, then deny Mallory her middle, finally defend the edges from Black Burglary... sounds trivial! ;) best regards,

1 0

Fwd: [Cryptography] A possible alternative to TOR and PrivaTegrity without backdoors
by grarpamp 20 Jan '16

20 Jan '16

---------- Forwarded message ---------- From: Bill Cox <waywardgeek(a)gmail.com> Date: Sun, Jan 10, 2016 at 9:38 AM Subject: [Cryptography] A possible alternative to TOR and PrivaTegrity without backdoors To: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com> This is an old idea, but perhaps now there might be more reason to consider it. I currently call this idea Alias. Here's my dumb data-dump on it. Thoughts? Alias is a concept for a TOR-like Internet protocol supporting free speech and user privacy, but without encouraging the worst evil behaviors. Exit Nodes are replaced with Public Gateways, which sponsor users. The definition of evil behavior is defined by the Public Gateways and operators of routing nodes. Users would be encouraged to use good behavior, as their public alias would develop a reputation over time. Anonymity would be protected, but a user's Public Gateway and any routing node could refuse to route data for aliases with poor reputations. TOR was created with a lofty goal: to support free speech. Unfortunately, TOR has drawn attention from governments and law enforcement, as it could be used to protect some of the worst activities, such as contract killing, and the slave trade. TOR Exit Node operators generally follow a strict policy of never looking at traffic, because simply observing this traffic would require Exit Node operators in most countries to regularly contact law enforcement to report crimes. PrivaTegrity is an alternative protocol to TOR, which aims to find a balance between protecting free speech and protecting the world from the worst behavior. Unfortunately, the PrivaTegrity inserts encryption backdoors. Alias Design: This is very much a dumb idea in the half-baked stage. Feedback and ideas are welcome. Alias would be a fork of TOR, and route Internet traffic from a user's machine through a couple of Routing Nodes, to a Public Gateway, which replaces the Exit Node. The Public Gateway would have an account for the user, under a pseudonym used on Alias network by the user, called his alias. The Public Gateway should keep an email contact address for the user, similar to regular accounts on various web sites. In Alias, user aliases would have trackable reputations, and the reputations of user aliases would be combined into a reputation for a Public Gateway. At a minimum, incident reports would be used to compute user reputations. Exactly how this works is TBD, but the goal is to cause gateways with very poor reputations to be effectively blacklisted by routing nodes, and for users with poor reputations to be dropped by reputable gateways. Users could move their alias from one gateway to another when needed, but they could not erase what their previous gateway knows about there identity. The Gateway would not know a user's location, and in many cases will know nothing other than the user's reputation and email address. When requested by a government authority, at a minimum, a gateway can drop support for a user alias, causing that alias to try to find a new gateway that will agree to sponsor it. Participants who act as routing nodes in Alias would be able to select what sort of reputations they require from aliases and Gateways to allow traffic to be routed through them to those gateways. They could, for example, choose to not route data for any gateway with a high reputation for routing to pornography sites. I compare the TOR, PrivaTegrity, and Alias concepts in several "threat cases" below: Threat Case: Governments Overreact to Terrorism In this case, we assume all the governments involved have decided to share all user network traffic in a mass surveillance program. The user Alice has something to say, such as wanting to tell the world that the mass surveillance program exists. TOR: Alice succeeds in using TOR to log into various blogging sites and publishes her knowledge about the surveillance program. Unfortunately, TOR provides limited defense against the Men in Black (MiB), and Alice may be arrested. The MiB is assumed to compromise TOR in various ways, such as operating many Exit Nodes and monitoring meta-data such as packet timing and size between nodes. PrivaTegrity: With the assumption that all governments involved are colluding, Alice is revealed directly, without having to subvert the protocol. Alias: Alice needs a Public Gateway to sponsor her. She can choose a gateway with a reputation of sponsoring free speech, such various newspapers, in a country that is not participating in the mass surveillance program. When Alice posts what she knows to various blogs, the Public Gateway (newspaper in this case) will be the the one defending her anonymity. In any case, even if the newspaper is forced to reveal what they know about Alice, they never knew her location. Conclusion: Alias seems to provide better protection of free speech in this case. Threat Case: A Single Government Blackmails the Rest Suppose one of the governments involved decides to use it’s influence in the protocol to blackmail one or more of the other governments involved into agreeing to some political agenda. TOR: If the government were the USA, it might have unique powers to track users through the TOR network. If true, the USA could refuse to reveal a French suspected terrorist unless the French government share mass surveillance data collected on it’s citizens. Is this sort of thinking too paranoid? PrivaTegrity: With nine separate governments who must collude to expose a user, it is possible for any one of the nine to blackmail the rest. For example, if tracking down a particular user is of critical importance to one government, another could demand certain trade policies be agreed to before allowing that user to be revealed. Alias: A country containing the Public Gateway sponsoring a user might make political demands from another country before agreeing to force the Public Gateway to reveal a user’s email address. However, this coercion is weaker than weaker than the TOR case because there is no country with majority control, and weaker than the PrivaTegrity case because a government can coerce cooperation only from Public Gateways in its country. Conclusion: While none are immune to this threat, Alias seems to perform better in this case. Threat Case: Hackers Compromise the Network In this case, a group of hackers wants to reveal the identity of a particular user. TOR: There is little chance that the attacker can hack all the nodes from the user to the Exit Node, and since the Exit Node has no information about the user, there seems to be little chance that the hacker can reveal the user’s identity, short of bugs in the protocol. PrivaTegrity: While hackers might hack one or more of the nine governments, it would be a considerable task for the hacker to hack them all. However, it is possible, and this is a weakness vs TOR. Alias: The hacker need only hack the user’s chosen Public Gateway, which is a considerably simpler task than with PrivaTegrity. Conclusion: Hackability of Public Gateways is a significant weakness for Alias compared to the other two. Threat Case: Evil Users Secretly Collude In this case, suppose there is strong evidence that several evil users wants to collude to do something terrible, and they want to communicate anonymously. For example, they could be running a contract-killing business or enslaving people and selling them on the Dark Web. TOR: Unfortunately, evil behaviors have been enabled in some cases over TOR. PrivaTegrity: The users involved in such evil activities can have their communication secretly wiretapped. This is a strong capability for law enforcement in this case. Alias: Assuming reputable Public Gateways are used, most of the users’ emails would be revealed to law enforcement. This is weaker than a wiretap. Conclusion: In the case of severe evil, PrivaTegrity performs the best, Alias next best, and TOR the worst. Threat Case: Somewhat Evil Users Secretly Collude What is evil vs good is highly subjective, and getting people to agree can be difficult. In this case, the users are engaged in what most reasonable people consider evil. For example, consider illegal trade in ivory, which could lead to the extinction of wild elephants. TOR: Users trading in ivory likely would benefit from using TOR. PrivaTegrity: Having to get cooperation from nine governments may be too painful when tracking down a single ivory trader, and the ivory trader likely could use PrivaTegrity to their advantage. If, on the other hand, the nine governments put in place a rapid rubber-stamp process to enable going after small-time criminals, then this capability can be highly abused. Alias: Ivory traders would avoid using Alias through reputable Public Gateways, since their identities could easily be revealed¸ and the sites the traders visit to buy/sell ivory would not likely be very reputable, lowering their alias' reputation. Conclusion: Alias seems to perform better at determine somewhat evil behaviors. Bill _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

4 7

Re: freedom is a gentle SeppuKuma
by coderman 19 Jan '16

19 Jan '16

SeppuKuma also offers 23 very different methods one can choose to end their life, including Everlasting Sleep (lethal injection), Pillow Kisses (suffocation), Peaceful Breath (helium asphyxia) and Sleepy time Hug which is where the robotic bear strangles its partner until their pulse stops for 15 minutes. All of these attributes enable the SeppuKuma to give it’s patient the power to choose how they get to end their own life. - http://www.iflscience.org/japan-engineers-design-robotic-bear-to-aid-in-ass…

3 5

Avoid beta testing medical drugs, you can die
by Georgi Guninski 19 Jan '16

19 Jan '16

http://www.bloomberg.com/news/articles/2016-01-15/french-drug-trial-leaves-… ---- Six people participating in a clinical trial for an experimental drug have been hospitalized after a “serious accident,” France’s Health Ministry said. One of the people is on life support and is considered brain dead, the ministry said in an e-mailed statement on Friday. ----- Drugs reach software quality.

3 3