- cypherpunks - lists.cpunks.org

Re: [cryptome] NYT on Nick Szabo and Bitcoin
by JS733NknRj6J 03 Jul '15

03 Jul '15

I seem to vaguely remember this profile (or one like it) but can't turn it up myself. Would be very grateful for the link if you do repost it. - JS7 Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland. -------- Original Message -------- Subject: Re: [cryptome] NYT on Nick Szabo and Bitcoin Time (GMT): May 18 2015 13:13:12 From: wilfred(a)vt.edu To: cryptome(a)freelists.org CC: cypherpunks(a)cpunks.org, cryptography(a)metzdowd.com, cryptography(a)randombit.net We did a context profile on Satoshi with analysis of intel-based datacenter profiles and certain known paterns from the USSS (Treasury Fincen) crew you like so much at Yale and another specific MI5 ish unit whome you remember from Anguilla. The analysis clustered age and language patterns and identified a very tight range of character and background with institutional intent, then modeled the propaganda influence that gave rise to the BTC trend. The analysis was posted on the forums and pdf, but are missing from search. We will repost the original and add some current profile analysis. In short, the character is a 20s 2-year AS pre-law 1811 (police) with distinct interest in using US/UK and new international law *pyramid scheme policies to take over global legacy datacenters* in criminal forfeiture cases. Another party did a review of law&policy influencers of the same market and similarily isolated the core group. (no need to mention DEA+FINCEN.) On Sunday, May 17, 2015, John Young <jya(a)pipeline.com> wrote: [ nytimes.com/2015/05/17/business/decoding-the-enigma-of-satoshi-nakamoto-and… Those around cypherpunks 1993-1998 will recall Szabo's emails on bitcoin early precursors along with Adam Back, Hal Finney, Tim May, Wei Dai, Lucky Green, Hettinga, many more burgeoning F-Cs. NYT piece credits cpunks as subversive birther, now being hyper-monetized by arch-cryptoanarchist Goldman Sachs and many more centralists. Szabo denies being Satoshi, but ... others rush to fill the gap

2 1

Brits: Cameron swats at crypto again, GCHQ spies Amnesty
by grarpamp 03 Jul '15

03 Jul '15

http://arstechnica.co.uk/tech-policy/2015/07/cameron-reaffirms-there-will-b… http://betanews.com/2015/07/02/uk-government-illegally-spied-on-amnesty-int…

2 1

The Intercept Releases ~1,264 pages of NSA Docs
by John Young 02 Jul '15

02 Jul '15

Mostly Xkeyscore and more. http://cryptome.org/2015/07/nsa-xks-more-intercept-15-0701.7z (643MB) List of files: https://pbs.twimg.com/media/CI3AatNUsAExiNV.jpg:large

6 8

Amazon TLS implementation
by grarpamp 01 Jul '15

01 Jul '15

https://github.com/awslabs/s2n s2n is a C99 implementation of the TLS/SSL protocols that is designed to be simple, small, fast, and with security as a priority. It is released and licensed under the Apache Software License 2.0.

1 0

5000 Darknet Websites
by grarpamp 30 Jun '15

30 Jun '15

http://fsxeh2tzrcby266e.onion/

1 1

Fixing the broken GPG and HTTPS (X509) trust models with Simple Public Key Infrastructure (SPKI)
by Seth 30 Jun '15

30 Jun '15

Reposted from http://vinay.howtolivewiki.com/blog/other/secure-private-reliable-social-ne… ** secure private reliable social networks: sprsn ** by Vinay Gupta • December 29, 2014 sprsn is an idea for a small piece of software which I think would do the world some good by existing, and which currently does not exist. It’s a deeply technical project that I probably don’t have time to build (unless somebody wants to pay my rent for a few months while I take a shot at it with a helper or two! – I am not serious about this) but I can describe what’s needed and maybe it will inspire somebody, in whole or in part. Synopsis: combine the new (telehash) with the old (SPKI) and get a Facebook-killer in the form of a command line utility that provides a decentralized social network. However, will Ethereum do this, and a ton more? The dream sprsn bob "hey when are you coming over?" sprsn bob list friends > leslie > carol > jake sprsn bob add carol > added bob's friend carol with key [a23fd61b7] > you have no other routes to carol sprsn jake > use bob's key for jake? Now imagine that sprsn also has a web interface mode: sprsn -d 9999 http://localhost:9999 mounts a web interface to your local sprsn instance. The sprsn instance connects to your (online) friends running sprsn using telehash (a persistant DHT tool) for web chat and for key management: click on your friend’s friends to acquire their keys, and multipath to people (“you have 9 friends in common”) to get more certainty about the keys. Obviously this would be great: the best of SSH and Facebook in a single utility. It is now relatively easy to build. Let me show you why it hasn’t happened already, and why we need it! The Problem GPG and HTTPS (X509) are broken in usability terms because the conceptual model of trust embedded in each network does not correspond to how people actually experience the world. As a result, there is a constant grind between people and these systems, mainly showing up as a series of user interface disasters. The GPG web of trust results in absurd social constructs like signing parties because it does not work and creating social constructs that weird to support it is a sign of that: stand in a line and show 50 strangers your government ID to prove you exist? Really? Likewise, anybody who’s tried to buy an X509 certificate (HTTPS cert) knows the process is absurd: anybody who’s really determined can probably figure out how to fake your details if they happen to be doing this before you do it for yourself, and of the 1500 or so Certificate Authorities issuing trust credentials at least one is weak or compromised by a State, and all your browser will tell you is “yes, I trust this credential absolutely.” You just don’t get any say in the matter at all. The entirely manual, Byzantine process is broken, and so is the entirely invisible, automated one. It just doesn’t work. The process of mapping keys to people is just broken and nearly all the rest of the trouble emanates from this fact. A GPG key maps a person to an email address to a key, and leaves you to pick who you trust enough to prove the map is right. An HTTPS cert maps an organization to an IP address to a key, and asks you to trust one of 1500 organizations your browser vendor chose to trust. It’s not just the trust model that’s broken, it’s the binding of these various pieces of data together using cryptography. Gluing the wrong stuff to the wrong stuff produces constant security and reliability problems. What’s the wrong stuff? Legacy delivery mechanisms like email and DNS. Mapping a person to an email address, and an email address to a key is two mappings. Same for HTTPS where we map an organization to an IP address to a key. Two mappings, one of which is essentially arbitrary: I care about identity and key. I should not have to worry about IP address or email address – that’s a minor technical detail. But these outmoded trust systems foreground it, much to our discomfort. Telehash Enter Telehash, an encrypted network stack in which you route messages directly to a public key. The code is pretty simple expect(mesh).to.be.an('object'); mesh.receive(new Buffer("208cb2d0532f74acae82","hex"), pipe); The cryptographic key is the routing address. So now we only have to accomplish one level of indirection: person to key. Something old, something new, something borrowed, something blue. Enter SPKI and our old friend, the Granovetter diagram. SPKI and trust in networks, not webs Simple Public Key Infrastructure is what we should have deployed instead of X509/HTTPS and the GPG web of trust. There are two critical differences between SPKI and X509/GPG. They are: 1) SPKI gives users the ability to certify facts about other users, for example “bob is allowed to use my computer” can be expressed in a machine-readable fashion (s-expressions.) This lets users build their own trust architectures on an ad-hoc basis. 2) SPKI allows anybody to chain certificates of this type (“fred says that bob says that vinay says that bob is allowed to use his computer.”) This ability removes the centrality of the CA: anybody that I trust can give me a certificate stating “this is the key for amazon.com” and because of certificate chaining, I can see the line of authority down which that key passed. These might sound like minor features, but they are not: these two features express the difference between trust-hierarchy (X509) and trust-soup (GPG), neither of which are productive, and the consumer-producer based trust-anarchy which SPKI permits and, indeed, requires. The best explanation of this in more detail is the Ode to the Granovetter Diagram which shows how this different trust model maps cleanly to the networks of human communication found by Mark Granovetter in his sociological research. We’re talking about building trust systems which correspond to actual trust systems as they are found in the real world, not the broken military abstractions of X509 or the flawed cryptoanarchy of GPG. Usable security is possible Once you fix the trust model so that it works for humans, and use Telehash to reduce the number of mappings from three (person -> delivery mechanism -> key) to two (person -> key) it’s possible to imagine a secure system in which people actually understand what is happening well enough feel comfortable that they understand what is going on. So let’s break this down into the desirable properties for the system we’d build using these primitives. For ease, let’s consider realtime chat in the first instance – just pushing messages down telehash sockets. The only question we have to answer is which telehash socket corresponds to which person. 1) person = key there’s no way to break the binding between a person and a key, because a person is a key, or multiple keys. 2) delivery = key this is what we get from telehash – I don’t need to worry about how I’m sending you the message, it’s right there. So I obtain a key for a friend of mine by, say, email. Once I’ve connected to them, I can then ask them to send me keys for our mutual friends. 3) keys carry the chain of referrers “alice says this is her key” “bob says that alice says that this is her key” “fred says that bob says that alice says that this is her key” What that looks like in practice is a social graph, like the one embedded in facebook. I click on you, my friend, and I click on alice, your friend, and the connection that forms is an SPKI key being transferred to my keyring. The key is its history – the path by which the key came to me is the trust chain. If I want to be more sure the key I have is Alice’s key (and not your sockpuppet) I need to find an independent route or two to Alice. If Google and Dunn & Bradstreet both agree that this key is the key for the IRS, that’s good enough for me. 4) tools and affordances So how would we actually build this? I would recommend a golang implementation for cross platform compatibility and ease of distribution. NaCl and Telehash both exist for golang, and the self-contained binaries which result are easy to spread around. A command line client would be easy to augment with a web interface in which the golang program running on localhost provides an HTTP interface for users that want graphics etc. Basically you get a decentralized social network with secure chat pretty much out of the box, where “friending” somebody acquires their key, and the referral network through which keys propagate is a key social dynamic. This can work. 5) advanced topics How do we message friends who aren’t online? Store and forwards seems to be the obvious approach. Suppose I create a certificate (“sign”) which lists a set of telehash keys that are my “store and forward” servers – if you try and chat to me and I’m not there, you can ping one of them and dump an (encrypted) message for me there and I’ll pick it up when I’m online again. Same holds for large block transfer (i.e. dropbox) – I specify my choice of servers by issuing a digital certificate. Do we need a central store of those certificates? Maybe, or maybe it’s simply an addressing mechanism: every time we chat, I push over my updated delivery info, and you can ask your friends for my updated delivery info if you need to reach me. In all probability, a decision has to be made about whether to keep the old SPKI s-expression format for certificates, or move to JSON. Good luck with that decision, it’s a hard one. Conclusion There’s no way to fix a broken conceptual model with a better user interface. GPG does not work for ordinary users, and GPG cannot work: we’ve been trying to fix this for 20 years and it has not happened. The process by which humans communicate is not tractable using those trust primitives. We are stuck with a mess, and X509 is not an answer either – it worked when only big orgs wanted to secure their email and web sites, but now everybody wants to do it and the certificate issuing mechanisms are becoming far too sloppy to trust. We have to go back 20 years to the brilliant analysis of the people who did not ship a sloppy hack to quickly get to market but sat there and figured out the right thing to do, if we want to fix this mess in a durable way. High roads and low roads The high road on these issues is Ethereum. Telehash takes the DHT and uses it for routing. Bitcoin takes the DHT and adds proof of work to generate a history. Ethereum takes bitcoin and puts executable contracts into the history, plus protocols for chat and block transfer. It’s entirely possible that SPKI-style user-generated certificates will make their way into Ethereum, either as part of the core spec or as a common class of DAAPs. “I have bought stuff from bob and would do so again” can be issues as a certificate, in a standardized format, and these certificates can be spidered out of the blockchain to generate trust metrics. Likewise, if all your messaging is happening on the Ethereum protocol, you do not necessarily need telehash. Here’s the question: is Ethereum’s “one ring to rule them all” approach feasible, or should we work closer to the Unix Philosophy and build smaller pieces, loosely joined. I can imagine a command line Telehash/SPKI client which is as commonly used as SSH is today, for slinging around chat and small data. I can also imagine an operating-system like sea of executable contracts and helper functions in a densely knit global decentralized computational ecosystem providing all the same services and more. I, personally, am in favor of a mixed strategy. I think the sheer naked moonshot ambition of Ethereum is extremely attractive, and part of the reason I joined the team (F.I.S.T.) was that I wanted to be part of such an ambitious vision. But it’s an awful lot of bleeding edge tech, and with a project that large and complex, you can never be quite sure what will come out the other end. In particular, I have no idea whether the nuances of SPKI etc. which will enable a revolution in the way that ordinary users experience cryptography will show up in Ethereum in a usable way – the core smart contract etc. functions can work perfectly well without fixing the nuances that user-issued certificates will get. So I’m writing this post for two reasons: to encourage the Telehash community to examine SPKI and look at it as a way of managing keys inside of their DHT routing paradigm, and to encourage the Ethereum community to look at SPKI and ask whether it might empower users within the larger Ethereum landscape. Either way, I would dearly love to see an SPKI revival so that, finally, at long last, pull the sword from the stone: Johnny can encrypt.

3 2

Elsevier tries to Swartz Sci-Hub
by grarpamp 29 Jun '15

29 Jun '15

http://torrentfreak.com/sci-hub-tears-down-academias-illegal-copyright-payw… http://www.sci-hub.club/

4 6

Tribler - anonymous downloading
by Александр 28 Jun '15

28 Jun '15

> > https://www.tribler.org/ > https://github.com/Tribler/tribler/releases > > "Tribler - Privacy using our Tor-inspired onion routing. > Tribler offers anonymous downloading. Bittorrent is fast, but has no > privacy. We do NOT use the normal Tor network, but created a dedicated > Tor-like onion routing network exclusively for torrent downloading. Tribler > follows the Tor wire protocol specification and hidden services spec quite > closely, but is enhanced to need no central (directory) server" > This looks very nice. And they are constantly improving.

7 6

Re: Elsevier tries to Swartz Sci-Hub
by John Young 28 Jun '15

28 Jun '15

Peculiar that there are not thousands of mirrors of offerings by Libgen, Sci-hub and the like, as well as new inititatives by the thousands. These collections are a lot more valuable than puny, by comparison, offerings by WikiLeaks and Snowden's media apparatus -- heavily publicized, politicized, monetized, glorified but minimally technically and scientifically useful due to sparse and drippy releases. For example, 3,415 volumes liberated by Aaron Swartz remain on torrent (some of which we have mirrored with only a half-dozen DMCA notices): http://cryptome.org/aaron-swartz-series.htm At 08:33 PM 6/27/2015, you wrote: >On 6/27/15, grarpamp <grarpamp(a)gmail.com> wrote: > > > http://torrentfreak.com/sci-hub-tears-down-academias-illegal-copyright-payw… > > http://www.sci-hub.club/ > >""" >âThanks to Elsevierâs lawsuit, I got past the point of no return. At >this time I either have to prove we have the full right to do this or >risk being executed like other âpiratesâ,â she says, naming Aaron >Swartz as an example. > >âIf Elsevier manages to shut down our projects or force them into the >darknet, that will demonstrate an important idea: that the public does >not have the right to knowledge. We have to win over Elsevier and >other publishers and show that what these commercial companies are >doing is fundamentally wrong.â >""" > >- i expect all onions, all the time, eventually :)

2 1

Re: Helmholtz Tubes, CRT Signals (Was: Sigint Dumps)
by John Young 28 Jun '15

28 Jun '15

Excuse delay, thought this went to the cpunks list. Date: Thu, 11 Jun 2015 10:39:49 -0400 Message-ID: <CAG+6jObQAytv2+mCvszWx_OgnpGANTaKggsu4jfVn-D1Tb0v5A(a)mail.gmail.com> Subject: Re: Helmholtz Tubes, CRT Signals (Was: Sigint Dumps) From: Wilfred Guerin <wilfred(a)vt.edu> To: John Young <jya(a)pipeline.com> Content-Type: text/plain; charset=UTF-8 To John- there are over 200 groups discussing the same issues, at least 2 got nationalised aggressively, and there have been some tangential posts on blogs or commercial forums mainly concerns about their datacenter security not knowing who might attack them, but overall the same concerns are expressed: Can the data be spoofed? Not at this resolution without having a model of everything at the same resolution... Are the blocks secure? No. [...] But services are stable. Exports to public? yes, p2p clusters loading, datacenters doing preparation processing, packed table files are set up for distributed search How do *you* know? UHD/4k VNC video stream to one of the master control servers handling the database import and text chat with 200 others, no direct access to data here, but certainty that the data is distributing. Involved how? rendering code to make GEO-TIFF map tiles and aggrigated spline/curves to simplify snapshot data and level of detail pyramid (multi-variate parametric search) index data. Now we ask... If this was NATO-ish or any variety of US/UK system built in the 1960s(?) can we solve for locations or viable downlink targets to intercept? This hint at geo-magnetic shift is a huge opportunity! The coin data is ... glorious... but the other signals are no less amusing, one set appears to be wired sigint in mhz carrier bands, assumably urban analogue phone signals as recorded from the switch routing system's ground or related wiretaps to rf via cable. genome.gov had links to the various data formats that others identified in the organics table. X-Ray physics and detector materials need research, 1890s through 1970s was a huge ammount of X-Ray publicity, but NEVER EVER DID ANYONE USE IT FOR SIGNALING??? BULLSHIT! ALSO!!! "is there any distinction at military bases or secure areas?" YES. there is some access control doors which others suggest is a standard card reader with number pad and automatic door that is common on the secure layer of military and COMMERCIAL CONTRACTOR facilities that has a proximity detector signal built into the door frame. THE COIN DATA WARPS AROUND THIS CYLINDRICAL SIGNAL ON THE DOOR PORTAL AND VECTOR PASSES THROUGH THE WALL. Obviously the vector is impossible without fields projected from that security device! There is also a ghosting signature that reduces sample rate (in the digitiser) around similar facilities, looks like it was isolated in the newer signal index, so it should be really obvious who is using these jamming systems and where! (and where else!) more questions: coins on boats? yes. coins on submarines? YES. (with ghosting) organic signals? wtf? Yes, but im told the prior emailed reference is erroneous: the primary index is a SIGNALS CHARACTERISTIC tree, the supporting block (large bit scope number) is VERY SIMILAR to a genetic expression profile tree such as genome.gov/ and many of the gene profiling standards. Hopefully the news will start posting the technical reports the primary groups have been preparing last few days... we need to get physics and advanced crypto groups attention, if the signals are encoded and that party broke through dense analogue crypto, it will take a huge effort to solve for that (it may have been an analogue EM field as well that performed the encoding or reference signals) to make the same capability posible for others. Staying alive! On Thu, Jun 11, 2015 at 10:08 AM, John Young <jya(a)pipeline.com> wrote: > We're tweeting these posts. Blowback: is any evidence available to > support the narrative? Sample of the data, say, for close examination, > with credible provenance, not the GG secret pact bloviation. > > Mild critique: is this sci-fi or legit or both, advancing the literary-video > prize winning breaking news big screen Hollywood Neal Stephenson > spirit of the Snowden "NSA disclosures." > > > At 09:54 AM 6/11/2015, you wrote: >> >> More specifics on the sigint system: >> >> This looks like a "Growth Industry" ... >> >> Access to the beam is not restricted, anyone can pull signals out of >> the reconaissance loop from any of its exposed vectors.*** >> >> Viable areas: >> Terrestrial: >> a: Spurrious emissions from tubes or conduit, beam deflection from >> interior particles >> b: Stray beams passing through field coils but not redirected >> c: Direct access to tubes or conduit (any variety of methods) >> Orbital: >> d: Geo-Magnetic Shift (downlinks) >> e: Refractive / deflection (downlinks) >> >> As the rate of geo-magnetic shift continues to deform the containment >> of the projected fields used to shape and steer the beams (which may >> also have something to do with the sensor itself?), wider areas will >> be accessible which are hit with the rogue spot beam from orbital (and >> projected field electro-magnetic) guides. >> >> This means almost anyone with a sensor can gather data from the downlinks. >> >> Additionally, spurrious radiation from the terrestrial system is >> available around endpoints and field coils, especially from damaged >> conduit or particles in the tubes. >> >> Time to raid the libraries for antique books about 1800s-1980s X-Ray >> EM physics and electromagnetic wave guides! >> >> It would not be rational to encode the carrier signal unless it was >> certain that the encoding would not disrupt signals quality, however >> raw X-Rated signals might have been too risky? >> >> [There are Thz ring oscillators, detectors, and various photonic >> rings, but properly implemented field-effect lenses, EM field vector >> control circuitry and coils(/phased array) (abstract field >> projection), and optimal tube design are all that should >> theorhetically be needed once a rogue beam is identified. X-Ray >> Materials and interference fields must be researched and made common >> knowledge.] >> >> Hopefully the data source is not too easily found and the dumps get >> out, this is extremely relevant for "civil liberties", human rights, >> and reconstructing your own personal history and records where your >> data is otherwise mising. >> >> >> >> On Thu, Jun 11, 2015, Wilfred Guerin <wilfred(a)vt.edu> wrote: >> > Helmholtz Tube, Beam Steering, EM field interaction, simple field >> > dynamics, (and your oscilliscope) are all you need to create complex >> > EM signals processors. >> > >> > No different than your antique crypto cracker, which uses an abstract >> > field to solve complex pre-defined systems. "56-bit" https cracker was >> > mass implemented as a 300mhz backplane EM field solver about the size >> > of your desktop computer. >> > >> > Using the same technology, resolution, and methods, BTC Bitcoins are >> > around 8m^3 of field to solve. >> > >> > No doubt the access and decoding to these sigint signals requires >> > similar proessing before being steered to the digitiser. >> > >> > (Maxwell Tube, Helmholtz Tube, typical of high school physics >> > classrooms) > > >

5 4