- cypherpunks - lists.cpunks.org

Ethical Tor
by Ryan Carboni 12 Nov '15

12 Nov '15

https://blog.torproject.org/blog/ethical-tor-research-guidelines Interesting problem: to use Tor is to say you trust your ISP less than some pseudorandom person over the internet.

3 2

Re: [Cryptography] Cryptogit
by grarpamp 11 Nov '15

11 Nov '15

On Wed, Nov 11, 2015 at 4:27 AM, Markus Wanner <markus(a)bluegap.ch> wrote: > On 11/10/2015 08:45 AM, grarpamp wrote: >> PKI built in, that may serve as a idea / base for further encryption work... > does not support encryption of data. I meant further crypto work to include encryption.

1 0

UK To Demand Backdooring Else Prison [Crypto In Devices, Email And More]
by grarpamp 11 Nov '15

11 Nov '15

http://arstechnica.co.uk/tech-policy/2015/11/snoopers-charter-uk-govt-can-d… Buried in the 300 pages of the draft Investigatory Powers Bill (aka the Snooper's Charter), published on Wednesday, is something called a "technical capability notice" (Section 189). Despite its neutral-sounding name, this gives the UK's home secretary almost unlimited power to impose "an obligation on any relevant operators"—any obligation—subject to the requirement that "the Secretary of State considers it is reasonable to do so." There is also the proviso that "it is (and remains) practicable for those relevant operators to comply with those requirements," which probably rules out breaking end-to-end encryption, but would still allow the home secretary to demand that companies add backdoors to their software and equipment. That's bad enough, but George Danezis, an associate professor in security and privacy engineering at University College London, points out that the Snooper's Charter is actually much, much worse.

2 2

PGP, Mail, Devices, P2P, Bans, Utility [was: UK Crypto]
by grarpamp 11 Nov '15

11 Nov '15

> Its easier to make a slick UI than convince people to do work. Is it > so much to ask that people who make software try to make life easy for > their users? Apple understands and successfully applies that. They put their UX and code camps together. It's something open source coders should solicit more into their fold... open source UX'ers. Assuming for example that Apple's phone crypto really is as good as their word, then the only real weakness is whatever cheesy screenpass it takes to login, yet so long as you *can* enter a strong 128 bit, insert a cryptokey, whatever... then it services everyone well enough. > You can drive a car mostly successfully without too much information but > if it stops at the side of the road and the limited info from your dials > doesn't tell you what's wrong then a bit more knowledge might just get > you home. > If anything, this matches the Enigmail model more than the invisible > crypto model. Sure, level based access to more details and knobs is fine. Dummy Mode, Medium Mucking, and Advanced Footshooting > - Your key gets signed by your friends, so now your friend network public > - Emails with PGP are provably from you, in a way that can be traced > back to physically witnessed government ID. Then don't have your key signed, and or be a nym and sign those of nyms you trust based on context, not on govts. Use of WOT is an option there if you want it, not every use case of PGP needs it. > PGP as a *product* it was a complete failure. I mean, it > doesn't even protect metadata. No, PGP is excellent, at what it does. Like any other tool, it fails when people foolishly try to make it do what it can't in situations it shouldn't. There is no blame on the tool there, only upon the people stubbornly bashing their head trying to make it fit. Continuing to talk about traditional SMTP transport services as fixable by bolting on whatever... is futile, ignorant, and old. All the people circlejerking on Metzdowd about designing crypto fixes into existing SMTP models, and all the newfangled encrypted webmail providers fall into that category. > the metadata issue a big problem for everyone who connects to a > server that isn't owned by them and I suspect really requires a new mail > protocol to resolve. Owning both ends hides the non-body elements, but you're not hiding dns lookups, sizes, the fact that you hit send, etc. It's not a new mail protocol that's needed, it's a whole new messaging network. > the only option is to make GPG transparent by getting the > email providers to automatically create key pairs and automatically > handle signing and encryption by integrating their mail services with > GPG behind the scenes. No, this is a non option. - Free providers are out for their own, like govts, they have no real interest in their users going dark. - Paid providers are a bit more loyal, but building that and making statements about it entails risk of suit for failure such that they're not really inclined. Most of them can't even put postfix, dovecot and openldap together reliably and scalably, let alone functional spam control and peering. - You're still trusting your keys to the provider, and that the provider won't be forced to jack you through your browser or whatever cool software they give you. In today's world, that is an abject failure. As before: Traditional centralized messaging services are a failure. There is NOTHING you can do to fix them but to replace them. That is where you have the chance to integrate crypto and defenses. And the only valid thing to replace them with now against the risk of centralization and all but godlike attack is a new anonymous encrypted P2P messaging transport system that scales [1]. You could create a new UI on all the platforms, and for faster adoption encapsulate existing message format within and extend existing clients to deal with the cryptographic addressbooking and keep it Unix and business needs pipeliney. You could include storage and nym registration. But at minimum you need to shuffle messages between cryptographic endpoints within the net. Anyways, you're wasting your time talking about PGPifying webmail, desnooping and delogging SMTP, and poor little Johnny. Forget about that tired old refit shit and build something new. Put a little bling and sound effects in it, call it an IM, it worked for ICQ and Candy Crush. The users will come, trust me. Do it soon so you can try to head off bans with your newfound embedded ubiquity. [1] We have a handful of researched and implemented systems now. But don't yet have enough knowledge, experience and wisdom to determine what really should go into one that will remain valid for the next 30 years of relatively stable internet API as we know it [2]. There's a good rate of people deploying new p2p, crypto, anti-metadata, attack resistant, network tech such that by 2020 we may have explored enough areas to begin to feel confident in assembling a handful of them into such a system... even into a number of systems... messaging, storage, info / data distribution, payments. But it will take all of us trying them out and contributing to do it. [2] Packet switched IPv6 routed global end to end connectivity. https://en.wikipedia.org/wiki/Internet https://en.wikipedia.org/wiki/History_of_the_Internet

1 0

Re: FOIA MuckRock API
by coderman 11 Nov '15

11 Nov '15

On 11/10/15, Michael Morisy <m(a)morisy.com> wrote: > I don't, for me it crashed around page 40 when I had it doing 20 > requests a page, but good chance I was doing something dumb/it was a > problem with my computer comparing Python versions might be useful. (i am using 2.7.6 for this test) > Mitch wrote some export code that's much cleaner in case it's helpful, > with the big caveat that it drops everything into JSON files instead > of txt and PDF. thanks; i'm past 90 pages now, and wondering if this is a particular edge case with some specific versions of Python, urllib, requests - the whole crew are a motley bunch! last question: API only credentials, like a "Device Login" or API token, which don't use primary username and password: are these on the roadmap? i don't mind this method much, since i generate unique user and passwords anyway, but it is good practice to have separate credentials for the bots and scripts :) thanks again!

1 0

FOIA MuckRock API
by Michael Best 11 Nov '15

11 Nov '15

I've been in on-and-off contact with Michael Morisy over at MuckRock, and one of the things that's come up is the API script that they're working on the export the FOIA requests and responses. Unfortunately, the script crashes after processing a few dozen, but not consistently - likely the result of character encoding issues. He's given me permission to share the in-progress script. https://github.com/MuckRock/API-examples/blob/master/export_all_requests_as… If anyone is able to look at the code and offer any ideas about solutions (or even pinpointing the problem), it'd be a great public service. I'm not code savvy enough to help, but I'm hoping someone on the list can bring in some fresh eyes and help MuckRock get the script working. --Mike

2 2

UK's GCHQ and NCA: Joining Forces To Ferret Out Darknet
by grarpamp 11 Nov '15

11 Nov '15

http://motherboard.vice.com/read/the-uk-will-police-the-dark-web-with-a-new… The Joint Operations Cell will increase our ability to identify and stop serious criminals. The creation of this unit should finally shatter the image that GCHQ solely focuses on national security matters or terrorism cases. At the summit, it was said that GCHQ's technical skills would be its contribution to the unit. The JOC is a genuinely innovative development, using the best of our respective agencies' skills.

1 0

DropZone: An Anonymous Peer-To-Peer Local Contraband Marketplace
by grarpamp 10 Nov '15

10 Nov '15

https://github.com/17Q4MX2hmktmpuUKHFuoRmS5MfB5XPbhod To whom it may concern, Markets are objects of censorship and always have been. There is a presumed division, that renders commerce distinct from the notion of free speech. But I will allege that the act of commerce is, itself, indistinct from speech. Where or how one spends their value is a decision as personal and poignant as any words ever spoken or letters ever written. As a unfortunate consequence of freedom, bad actors will engage in repugnant trade that impinges upon the rights and freedoms of others. It is the job of humanity to cooperate and see to it that trade, such as this, becomes unprofitable. Whether it is accomplished through technological achievement or through the adjustment of social mores, or perhaps a simple appeal to the underlying natural law, it is not the job of bad acting third parties to force into hiding commerce that must be dealt with by means of an adjustment to the global, social conscience. Cooperation, in the manner I was just speaking about, has never been plausible until the invention of The Blockchain. I will not foist upon Satoshi's humble creation such impracticable possibilities as the achievement of world peace. But in approaching Drop Zone, I am attempting to do nothing more than what is possible and possibly more efficient than what exists. I wish for Drop Zone to be nothing more than an appendage to The Blockchain. As such, it is every bit as much Bitcoin as Bitcoin itself. Just as a fungible Bitcoin enables the exchange of spaceless value with near impunity, Drop Zone removes the ability of unwelcome parties from glancing over the shoulders of those in the act of an exchange, whatever it entails. This technology disrupts the ability of buyers to gain insight into the identities or movements of suppliers making supply chains far less vulnerable to disruption. It is this innovation that separates this project from all other decentralized market solutions. Whereas Bitcoin forces us to consider the nature of money and value, Drop Zone will do the same for commerce. At its root, Bitcoin is a message passing system. Those messages that are passed, unlike any electronic message that's come before it, articulate value. Commerce is, and has always been, similarly inclined toward message passing. Whether in-person, over email, or through large, online shopping carts, fundamentally, commerce is composed of messages that are in service of the transaction wherein a final message of value is sent to a recipient in exchange for a negotiated good or service. As such, Drop Zone is a secure message passing protocol inasmuch as it is a platform for commerce. And while the problem is far beyond the scope or capabilities of the protocol in its most fundamental form, the observant might even see the tenuous skeleton of a full-fledged reputation system. Such a project is, in itself, as important and difficult as any facing this decentralized ecosystem. I hope that Drop Zone lets us all dream of a day when no man will any longer be made to suffer indignity for simply engaging in unpopular or stigmatized commerce. May all commerce be created equal. Today is a Beautiful day, Miracle Max quia omnis qui se exaltat humiliabitur et qui se humiliat exaltabitur

1 1

Re: [FORGED] Re: [FORGED] Re: UK To Ban Crypto In Devices, Email And More
by oshwm 10 Nov '15

10 Nov '15

On 10/11/15 12:29, Neuhaus Stephan (neut) wrote: > On 2015-11-09 21:12, "oshwm" <oshwm(a)openmailbox.org> wrote: >> On 09/11/15 08:38, Neuhaus Stephan (neut) wrote: >>> On 2015-11-08 09:45, "cypherpunks on behalf of oshwm" >>> <cypherpunks-bounces(a)cpunks.org on behalf of oshwm(a)openmailbox.org> >>> wrote: >>> >>>> >>>> >>>> On 08/11/15 08:40, Peter Gutmann wrote: >>>>> oshwm <oshwm(a)openmailbox.org> writes: >>>>> >>>>>> Can GPG be easier to use, I think so, is it too difficult to use by >>>>>> ordinary >>>>>> people - no, they're just too fucking lazy and lack motivation. >>>>> >>>>> ... and this is pretty much the poster child for why we have so much >>>>> unusable >>>>> crypto today. >>>>> >>>> >>>> Or, why we have such a fucking retarded human race with the attention >>>> span of a knat who expect everything to be given to them on a plate. >>> >>> I think you're rather making Peter's point for him. >>> >>> Case in point: Would you care to try to explain to my dad (who is 76) >>> what >>> an expired PGP key means, exactly? What a trusted key is? Hell, what a >>> public key is, even? How a PGP plaintext signature could have failed to >>> verify? (In this context, don't forget to explain to him the difference >>> between UTF-8 and ISO 8859-1.) Hint: an attitude of "well, you just have >>> to learn all these new concepts, you fucking retarded human with the >>> attention span of a knat" is probably not going to help. >>> >> >> I feel sorry for your dad, having a child that thinks so little of his >> mental capacity. > > I guess that’s what I get for choosing an example that makes the > ad-hominem too easy. > You see, I didn't know what ad hominem mean't so I had a choice, I could wait for someone to explain it all to me or I could go and find out the meaning for myself - which I did :P >> If your dad can operate Windows and an email client then he has what is >> needed to learn enough to sign and encrypt emails with GnuPG. >> He doesn't need to know how crypto works or every minute detail, he just >> needs to be able to make sense of a Wizard and to be able to click a few >> buttons. > > I don’t think that’s true, and the reason is that it’s not enough to learn > the right sequence of buttons to press. You’re right: learning to press > some buttons in the right sequence is the easy part. The tricky part > happens when an error occurs, e.g., when a signature fails to verify. And > signatures can fail to verify for a huge number of reasons and an > Enigmail-style user interface will simply expose them to the user. > Without a correct mental model—which goes beyond knowing button > sequences—no one will be able to make a correct assessment of an error > situation, no matter what the age, education, or mental capacity. > >> He'll be at a disadvantage for not learning more about crypto and PGP >> but he'll be able to maintain a small amount of privacy in his use of >> email. > > Only when things go right. And only if he cares enough. If there was some > automated mechanism that would do all of these things automatically in the > background, he could be using encrypted email without even knowing it. > Like Skype, who at one time provided encrypted video and voice chat > without users even being aware. That did more for security than exposing > all the intricate details through an Enigmail-style UI. > Skype: centralized authentication by a third party corporation - you don't have to do any authentication for yourself, you just have to trust that Microsoft will never act in a way inconsistent with your privacy or freedom. PGP: decentralized authentication where the amount of trust you have in the certificates is fully under your control. But with this control comes complexity because you don't have some benevolent overlord taking care of your every need. Take your pick, personally I don't trust big corporations and for that reason will accept the extra complexity. >> When he gets stuck he might be able to ask his son or daughter for help > > He might indeed! Or he might not, given that his interest when interacting > with a computer is to e.g. send an email to someone, not to have to expend > work to preserve his privacy. I suspect that he’d rather go on with what > he was doing — sending email — than asking me what a good but untrusted > signature is. (For example.) > If he has little interest in protecting his privacy why would he even bother with any encryption no matter whether it's easy to use or not? >> - assuming he hasn't given up asking because you hold his mental >> capacity in such low regard. > > OK, next time, I’ll *really* choose another example that doesn’t open > myself up to the ad-hominem so easily. > Yep, use stereotypes and you get what you deserve :P >>> If we want "ordinary people” (whatever they are, but in a crypto context >>> they’ll be more like my dad than like me) to use encryption, we will >>> have >>> to make it invisible to them. It doesn't even have to be perfect; good >>> enough will do. >>> >> >> You think if crypto is invisible to people then they'll be able to deal >> with when things go wrong any better than your dad would be if you >> equipped him with minimal knowledge of how to get by with PGP using e.g >> Enigmail on Thunderbird? > > In most cases, yes. Also, it will enable things to go right more often, > simply because configuration options will be removed, making the whole > thing easier to write and test. > >> The more you hide details from people, the less they are able to help >> themselves. > > That is only true for a very small number of specialists. The success of > many products is precisely the careful hiding of many details, most of > which would be unintelligible to the vast majority of users anyway. Unless > you’re a trained engineer, you will have no detailed idea how a modern car > engine works (or FM radio or …), for example. If you had to know these > things in order to operate a car engine, there would be vastly fewer cars > out there. And common failure modes of cars — low fuel, low oil or tire > pressure and whatnot — have been incorporated into user interfaces that > many people routinely and correctly use. That works only by not exposing > details. > You can drive a car mostly successfully without too much information but if it stops at the side of the road and the limited info from your dials doesn't tell you what's wrong then a bit more knowledge might just get you home. If anything, this matches the Enigmail model more than the invisible crypto model. > Fun, > > Stephan > — > If I have downvote policy, I will downvote you. > >

1 0

Re: [Cryptography] Cryptogit
by grarpamp 10 Nov '15

10 Nov '15

On Mon, Nov 9, 2015 at 11:53 PM, Phillip Hallam-Baker <phill(a)hallambaker.com> wrote: > As some folk will know from my facebook feed, I have been struggling > with git over the past week. > > With a considerable amount of hassle, I now have the systems running. > Its not pretty and there are good reasons for the usability horrors. > SSH and GIT both bump up against the PKI bootstrap problem when in > comes to sharing public keys. Fortunately that is the problem I am > currently working on and git is now one of the applications I hope to > make a lot easier to use with the Mesh. > > > Anyhoo. Let us imagine for a moment that it is really easy to connect > up to a git repo in the cloud. On your Google drive or your 1Tb > OneDrive or whatever. > > Wouldn't it be really nice to be able to automatically encrypt the > data you store in the remote .git repo? Interesting in the context of using git, particularly regarding multi-user use of same. Simply using a block storage provider would suffice to put a filesystem then git on top. There's another git-like version control system that has some PKI built in, that may serve as a idea / base for further encryption work... http://www.monotone.ca/ > It probably wouldn't be all that hard to arrange either. Just a few > extensions to the git file format to write out encryption headers into > each of the object files and encrypt the body. > > As folk have noted, proxy re-encryption 'recryption' can be used as > leverage to simplify the key management problem once a certain patent > expires in a couple of years. > > > Anyone interested?

1 0