- cypherpunks - lists.cpunks.org

Re: "Whew, wondered where we'd put those 200,000 BTC!"
by tpb-crypto＠laposte.net 23 Mar '14

23 Mar '14

> Message du 23/03/14 04:45 > De : dan(a)geer.org > A : cypherpunks(a)cpunks.org > Copie à : > Objet : Re: "Whew, wondered where we'd put those 200,000 BTC!" > > > It were write that: > > > You are in the same boat of Karpeles and Ulbricht, they also were > > barely able to code some interpreted language and they were overwhelmed > > by the intricacies of the systems they were building. Until they > > finally brought disaster for themselves and everyone that depended > > on them. > > True but inevitable. Humans can design systems more complex than > they can then operate. The financial sector's "flash crashes" are > one, but only one, public proof-by-demonstration of that fact. I > predict that the fifty interlocked insurance exchanges for Obamacare > will be another. It is likely that any cryptocurrency exchange > that is center-free and self-mobile is harder still. The HTTP > Archive says that the average web page now makes out-references to > 16 different domains as well as making 17 Javascript requests per > page, and the Javascript byte count is five times the HTML byte > count. > > Above some threshold of system complexity, it is no longer possible > to test, it is only possible to react to emergent behavior. Even > the lowliest Internet user is involved -- on the top level page for > a major news site, I found 400 out-references to 85 unique domains > each of which is similarly constructed. If you leave those pages > up, then because most such pages have an auto-refresh, moving your > ass to a new subnet signals to every single advertising network > that you have done so. > > --dan > Your comments naturally lead us to think how to make simple systems, yet functional enough for the purpose we are building them. KISS is coming back into vogue. We are up to a revival in self-made purpose-specific web servers. Learning the few needed protocols and building from the ground up using open-source tools seems the way to go. Notwithstanding hardware issues, using things out of intel and amd seems also to become a trend.

1 0

Re: secure anonymous decentralized systems [was: "Whew, wondered where we'd put those 200,000 BTC!"]
by coderman 23 Mar '14

23 Mar '14

this thread needs more violin and cutting one's self. my comments on this familiar lament inline,... On Sat, Mar 22, 2014 at 6:14 PM, Lodewijk andré de la porte <l(a)odewijk.nl> wrote: > ... > The sad part is that I got scared away from [storing value on-line] ... > > I spent days feeling sick because I couldn't figure out a way to do > exchanges distributed over sufficiently geographically disperse points to > avoid trouble with a single government going mad. Then I realized the > Megaupload situation means that any US-ally country is susceptible to a > planned US-exercise. > > Once I found that I cannot trust maybe 150 countries in the world with the > rest being mostly unsuitable, that turned into a bit of a problem... > > Then you realize you're still not physically secure. The server itself is a > hotbox of 100% exposure... > > If you let the box call homes first (homes is the list of other servers) it > can use it's already present crypto to prevent any possible MITM or > listening in. So that's good. Problem is a little liquid nitrogen, > connection on a bus or firewire port, etc. is enough to make the server > bleed information faster than the Titanic ate water. So you have to cut the > firefire connections (USB is okay and convenient AFAIC) and heat-conductive > epoxy the motherboard, RAM and a good margin around the CPU too (use a > taller and wider cooler than usual). Maybe even run some wires through it to > measure breach. > > Then you find out Intel's chips have all sorts of hyperintelligence on it to > allow "remote administration" which just blew my fucking mind halfway across > the galaxy. [ED:. yes, it really is this bad!] > > Once you have your physical platform you have to make sure the software is > okay. I found that it's entirely impossible to not trust your compiler. And > the likelihood of cutting yourself is way too high with low level languages. > ... But you have to, because you can't do better. ... > > By now I'm a week further in worrying and researching, I'm sweating more at > night, I don't feel comfortable using my own computer anymore, I don't > understand why the world isn't a chaotic place where no computer ever is not > hacked out of it's guts. I realize it's probably because nobody is motivated > and smart enough to go through the effort, and then also doesn't get caught > except for those that'd pay a high price to hide their capabilities, which > is why you'd never notice. it's like a pair of glasses you put on, and can't take off! " i see vulns, everywhere! " ;P > Knowing all this I quite damn well decided I couldn't make a secure and > reliable centralized exchange. No distributed exchange would earn me a > profit, which I'd need to produce more software to help other people's life > better, so that wouldn't really help either. Aside from the fact that it > would not be popular because it'd be slower and less easy than a "central" > exchange. see also stealthy dopant level trojans, beam-steering TEMPEST, and you've seen much the same as i on my excursion down what it takes to build "secure anonymous decentralized systems". ( decentralized meaning that every node potentially equal, which means that every threat model a node might experience must be defended, which means you're building to the absolute hardest target, which means you've adopted multiple nation state attackers into scope, which means you're building something entirely unlike what we currently have or know how to build, and absolutely a long way from here...) wanna help? just working on the pieces is useful! [see also, not getting discouraged and giving up. *grin*] > Overall I decided I respect greatly the people that take on this challenge. > This was over a year ago. have you gone through the NSA TAO and SSO catalog? this is a great resource for putting some technical capability around the threat models above, and building test systems able to carry out attacks like those above. (for testing. in a test environment. of course :) > Looking at the hacks that happen I'm mostly shocked to find the level of > stupidity. Shocked as much to see how long things just go on without > significant trouble. and you wonder why USGov is trying to beat miscreants into submission with CFAA life destruction. everyone is passing the security buck, DA gotta do something... [this is just one of many poor trends.] > MtGox failing because money dissapeared over the > years... That was shocking at an unbelievable level. you must be new to interwebs? see also, every blackhat doxing crew since ever. > ... The list goes on. see also, every blackhat doxing crew since ever. > So I think I'm capable of making an exchange platform that's far better than > what's out there right now. And I will once I have time (I really don't have > it right now, life is such a fuzz). > > I still question if it'd be used by anyone. But at least I can try. don't do it. instead, build software secure and usable enough that every average user can be their own exchange and bank without falling prey to haxxors or stupidity. oh, someone told me that i'm depressing the hackers with my realism and please try to make the self hurt less desirable, so here, my real world cover is goat farmer: https://peertech.org/files/totes-coders-goats.jpg </shameless_plagiarism> [ i hope that didn't reduce my anonymity set too much! ]

2 1

Fwd: [RNG] Haveged - A Simple Entropy Daemon
by coderman 23 Mar '14

23 Mar '14

fwd, and added comment at end about a "upstream distribution" of repute. ---------- Forwarded message ---------- From: coderman <coderman(a)gmail.com> Date: Sat, Mar 22, 2014 at 6:06 PM Subject: Re: [RNG] Haveged - A Simple Entropy Daemon To: Brad Martin <yabrad(a)gmail.com> On Sat, Mar 22, 2014 at 5:44 PM, Brad Martin <yabrad(a)gmail.com> wrote: > ... > When great HWRNG is working, it can be damned difficult to find the > signatures - but they're always there. Even in the best case, cryptographers > must whiten, if only to scramble those signatures. But the magic is in that > underlying raw data - so unpredictable! this too, a much longer discussion. we are in agreement, though one point: when FreeBSD decided against direct use of _both_ RDRAND and XSTORE, it was not an equal dismissal. RDRAND is specifically, and intentionally designed without direct access to the physical entropy sources, while XSTORE allows direct access to a userspace entropy daemon through the MSR configuration bits. XSTORE in raw mode, to userspace entropy daemon (rngd) that continously monitors for catastrophic failure (as above), and then _conservatively_ digests and folds the entropy before adding to OS kernel entropy pool is a robust configuration. RDRAND and RDSEED inherently crippled - if you had to pick a design, you would pick raw access with open and independent validation of run-time behavior with configurable conservative'ness as you so chose. instead, NIST and FIPS push _hard_ on opaque designs without raw access. in turn, US Gov pushes vendors hard for NIST/FIPS compliance. this is just one stream of influence working against the interest of users and strong privacy. if you really want to do entropy without repute: 1.: it starts with development and distribution, where every host and runtime is seeded with distinct mastering entropy that is mixed on first boot.** 2.: every physical host contains two (redundant) physical entropy sources run in continuous verification with immediate halt/panic on dual physical source failure. 3.: opportunistic entropy gathering daemons also running on host including haveged, dakarand, and kernel interrupt and activity scavenging. 4.: virtio-random device support feed into guest OSes from host entropy pool. (Qemu, KVM, Vbox, etc.) 5.: at shutdown of physical host entropy state is saved to FDE protected root volume for re-incorporation into entropy state on next start. 6.: as signal of care, in all mastering images and runtime ensure that /dev/urandom links to /dev/random special device. 7.: use the strace to confirm in every application that appropriate entropy from /dev/*random is read when generating keys or nonces. [post to HN when confused about key length equivalences and application level entropy pools...] ** your distribution in turn is fully reproducible, and the builder of your images provides you an installation image signed by them, including all the other public sigs, and including the per-instance entropy, the entirety of which is then also signed again. you exchanged keys in person at some point in the past, to get your first copy of $secure_distro, and have been using meatspace authenticated keys ever since...

1 0

fractional reserves (was Re: Gox)
by dan＠geer.org 23 Mar '14

23 Mar '14

It was quoted: > "Injections in coin are most useful (enough to run the exchange) but > some cash is also needed to not run a fractional reserve" Those who find BitCoin interesting and wish it was more like world class banking will perhaps also be interested in this (de-html-ized) description of what that means: 21stcenturywire.com/2014/03/21/the-latest-heist-us-quietly-snatches-the-ukr… The Latest Heist: US Quietly Snatches the Ukraine's Gold Reserves March 21, 2014 As the dust settles in Kiev, another money trail has been revealed... According to reports out of Kiev (see links below), the US has quietly transfers 33 tons of Ukrainian gold out of the country and back to vaults in the US. Presumably, this sovereign wealth transfer would be counted as partial "collateral" for a fresh round of IMF, US FED, and ECB paper debt that is currently being organised for dumping into the Ukraine's economic black hole. Multiple inquiries to US Federal Reserve administrators into the location of the Ukraine's gold have been met with the proverbial `pass the buck', making tracking and tracking the final resting place of these 33 tonnes very difficult indeed - but one can expect that the NY Fed is probably the institution who has masterminded this financial heist. Note how gold flows into New York, but has difficulty flowing out of US private banking hands as is the case with the `confiscation' of Germany's gold. Numerous attempts by Bundesbank to repatriate its gold reserves have been met with a brick wall, and to date, Germany has only recovered a miniscule 5 tonnes directly from the NY Fed - out of the total 674 tonnes (an additional 32 tonnes were recovered via French central bank). It's worth pointing out here that when NATO sacked Libya in 2011, one of the first items that came into question was the gold in Libya's state-run central bank. Prior to the NATO takeover of that country, Libya had one of the highest per capita gold reserves in the world, alongside Lebanon, giving Libya a distinct advantage should it carry out former Libyan leader Muammar Muhammad al-Gaddafi's long-term financial transition to a gold-backed Libyan Dinar. As you can imagine, this is no longer the case in Tripoli. Additionally, like Libya, both Syria and Iran are two of the world's last remaining nation states who both have state-run central banks and gold reserves which fall outside of the world's private central banking syndicate. Needless to say, you can see an obvious pattern emerging here. And the story continues... The Big Lie + What Happened To Ukraine's Gold? By PM Fund Manager Dave Kranzler Investment Research Dynamics The Big Lie is that Central Banks don't care about gold. Nothing could be further from the truth. Ben Bernanke, more than once, claimed that he didn't understand gold. When Ron Paul asked Bernanke in front of Congress why Central Banks own gold if it's irrelevant, Bernanke flippantly suggested that it was out of tradition. In both cases Bernanke was lying and he knew it. In comparison, Greenspan seemed to have some respect for the laws of economics and - at least that I can recall - never would outright state that gold was not an economic factor. Greenspan lied as much as Bernanke did about everything else but he never committed himself to lie about gold. Most of you have probably read Greenspan's 1966 essay, "Gold and Economic Freedom" (linked). I have read it several times because it explains as well as anything out there why gold works as a currency and why Government-issued fiat currency does not. What I find amazing about The Big Lie about Central Banks and gold is that if gold really is considered to be irrelevant, the how come Central Banks - especially the Fed - are so secretive about their gold storage and trading activities? What's even more amazing is that no one other than Ron Paul and GATA asks them about this. Think about it. GATA spent a lot of money on legal fees attempting to get the Fed to publicly disclose its records related to the Fed's gold activities. The Fed spent even more money denying GATA's quest. And how come the Fed won't submit to a public, independent audit of its gold vaults? This brings me to the issue of the Ukraine's gold. According to public records, the Government of Ukraine owns 33 tonnes of gold that was being safekept in Ukraine. Last week a Ukrainian newspaper reported that acting PM Arseny Yatsenyuk ordered the transfer of that gold to the United States. The actual report is here: LINK. Jesse's Cafe Americain provided a translated version here: LINK. On the assumption that the report is true, and so far I have not seen any commentary or articles suggesting it is not true, the biggest question is, how come the U.S. has absolutely no problem loading up and transporting 33 tonnes of gold from Ukraine to the U.S. but seems to have difficulty loading up and transporting any of Germany's gold from New York to Berlin? And how come the U.S. and Ukraine seem to care about that gold at all, if indeed gold is irrelevant? It would seem that it would be a lot less expensive and logistically complicated just to have the U.S. military post a few armed guards around the gold if they're worried about theft. On the other hand, I'm sure Putin would be happy to buy the gold from Ukraine. What makes the story even more interesting is that GATA's Chris Powell has spent considerable time trying to get an answer to the question of whether or not the U.S. has taken custody of Ukraine's gold. When he queried the NY Fed, they responded with: "A spokesman for the New York Fed said simply: "Any inquiry regarding gold accounts should be directed to the account holder. You may want to contact the National Bank of Ukraine to discuss this report" (LINK). After trying for two days to get an answer from the U.S. State Department, they finally responded by referring him to the NY Fed (LINK). The final piece in verifying that the report is true is deflection from Ukraine. Mr. Powell has queried the National Bank of Ukraine, the Ukrainian Embassy in DC, and the Ukrainian mission to the UN in NYC. Crickets. As Chris states the case: "The difficulty in getting a straight answer here is pretty good evidence that the Ukrainian gold indeed has been sent to the United States." Unfortunately, it is likely that the citizens of Ukraine will end up paying the same price for allowing the U.S. to "safekeep" their sovereign gold. That price is the comforting knowledge that their gold has been delivered safely to vaults in China under U.S./UK bullion bank contractual delivery obligations, where it will be locked away for centuries.

1 0

Using some crypto to make gov't dataset identifiers better
by Eric Mill 23 Mar '14

23 Mar '14

So this is a little different from the usual fare here, but my colleague Tom Lee at the Sunlight Foundation has been thinking about using basic cryptographic concepts to convince governments to publish more unique identifiers in their datasets -- even when the identifiers they have in their *databases* is sensitive (like SSNs). The problem of anonymizing unique data is in some senses easier than others here, because in some gov't contexts, making things personally identifiable isn't the problem -- the *intent* is to publish personally identifiable, connect-able information, like for campaign donors and lobbyists. So the Mosaic Effect (de-anonymizing Netflix data) is less of a concern. Depends on the problem, though. After talking about it on a couple<https://groups.google.com/forum/#!topic/sunlightlabs/CdCdB_0TCgc>of lists<https://mailman.stanford.edu/pipermail/liberationtech/2014-February/012834.…>, Tom blogged it up: http://sunlightfoundation.com/blog/2014/03/20/a-little-math-could-make-iden… Your feedback would be very welcome, either here or in public fora. Of course, convincing government agencies to actually do this sort of thing might be a challenge, but there's a lot of levels and branches of government out there - you never know who might lead the way. -- Eric -- konklone.com | @konklone <https://twitter.com/konklone>

2 1

"I hunt sysadmins"
by coderman 22 Mar '14

22 Mar '14

can such a tasking pass my PCI PA-DSS audit for me?? "Imagine a master list of all admins of all networks on earth..." 'Inside the NSA's Secret Efforts to Hunt and Hack System Administrators' - https://firstlook.org/theintercept/article/2014/03/20/inside-nsa-secret-eff… also, slides: https://s3.amazonaws.com/s3.documentcloud.org/documents/1094387/i-hunt-sys-… """ Across the world, people who work as system administrators keep computer networks in order - and this has turned them into unwitting targets of the National Security Agency for simply doing their jobs. According to a secret document provided by NSA whistleblower Edward Snowden, the agency tracks down the private email and Facebook accounts of system administrators (or sys admins, as they are often called), before hacking their computers to gain access to the networks they control. The document consists of several posts - one of them is titled "I hunt sys admins" - that were published in 2012 on an internal discussion board hosted on the agency's classified servers. They were written by an NSA official involved in the agency's effort to break into foreign network routers, the devices that connect computer networks and transport data across the Internet. By infiltrating the computers of system administrators who work for foreign phone and Internet companies, the NSA can gain access to the calls and emails that flow over their networks. The classified posts reveal how the NSA official aspired to create a database that would function as an international hit list of sys admins to potentially target. Yet the document makes clear that the admins are not suspected of any criminal activity - they are targeted only because they control access to networks the agency wants to infiltrate. "Who better to target than the person that already has the 'keys to the kingdom'?" one of the posts says. The NSA wants more than just passwords. The document includes a list of other data that can be harvested from computers belonging to sys admins, including network maps, customer lists, business correspondence and, the author jokes, "pictures of cats in funny poses with amusing captions." The posts, boastful and casual in tone, contain hacker jargon (pwn, skillz, zomg, internetz) and are punctuated with expressions of mischief. "Current mood: devious," reads one, while another signs off, "Current mood: scheming." The author of the posts, whose name is being withheld by The Intercept, is a network specialist in the agency's Signals Intelligence Directorate, according to other NSA documents. The same author wrote secret presentations related to the NSA's controversial program to identify users of the Tor browser - a privacy-enhancing tool that allows people to browse the Internet anonymously. The network specialist, who served as a private contractor prior to joining the NSA, shows little respect for hackers who do not work for the government. One post expresses disdain for the quality of presentations at Blackhat and Defcon, the computer world's premier security and hacker conferences: It is unclear how precise the NSA's hacking attacks are or how the agency ensures that it excludes Americans from the intrusions. The author explains in one post that the NSA scours the Internet to find people it deems "probable" administrators, suggesting a lack of certainty in the process and implying that the wrong person could be targeted. It is illegal for the NSA to deliberately target Americans for surveillance without explicit prior authorization. But the employee's posts make no mention of any measures that might be taken to prevent hacking the computers of Americans who work as sys admins for foreign networks. Without such measures, Americans who work on such networks could potentially fall victim to an NSA infiltration attempt. The NSA declined to answer questions about its efforts to hack system administrators or explain how it ensures Americans are not mistakenly targeted. Agency spokeswoman Vanee' Vines said in an email statement: "A key part of the protections that apply to both U.S. persons and citizens of other countries is the mandate that information be in support of a valid foreign intelligence requirement, and comply with U.S. Attorney General-approved procedures to protect privacy rights." As The Intercept revealed last week, clandestine hacking has become central to the NSA's mission in the past decade. The agency is working to aggressively scale its ability to break into computers to perform what it calls "computer network exploitation," or CNE: the collection of intelligence from covertly infiltrated computer systems. Hacking into the computers of sys admins is particularly controversial because unlike conventional targets - people who are regarded as threats - sys admins are not suspected of any wrongdoing. In a post calling sys admins "a means to an end," the NSA employee writes, "Up front, sys admins generally are not my end target. My end target is the extremist/terrorist or government official that happens to be using the network some admin takes care of." The first step, according to the posts, is to collect IP addresses that are believed to be linked to a network's sys admin. An IP address is a series of numbers allocated to every computer that connects to the Internet. Using this identifier, the NSA can then run an IP address through the vast amount of signals intelligence data, or SIGINT, that it collects every day, trying to match the IP address to personal accounts. "What we'd really like is a personal webmail or Facebook account to target," one of the posts explains, presumably because, whereas IP addresses can be shared by multiple people, "alternative selectors" like a webmail or Facebook account can be linked to a particular target. You can "dumpster-dive for alternate selectors in the big SIGINT trash can" the author suggests. Or "pull out your wicked Google-fu" (slang for efficient Googling) to search for any "official and non-official e-mails" that the targets may have posted online. Once the agency believes it has identified a sys admin's personal accounts, according to the posts, it can target them with its so-called QUANTUM hacking techniques. The Snowden files reveal that the QUANTUM methods have been used to secretly inject surveillance malware into a Facebook page by sending malicious NSA data packets that appear to originate from a genuine Facebook server. This method tricks a target's computer into accepting the malicious packets, allowing the NSA to infect the targeted computer with a malware "implant" and gain unfettered access to the data stored on its hard drive. "Just pull those selectors, queue them up for QUANTUM, and proceed with the pwnage," the author of the posts writes. ("Pwnage," short for "pure ownage," is gamer-speak for defeating opponents.) The author adds, triumphantly, "Yay! /throws confetti in the air." In one case, these tactics were used by the NSA's British counterpart, Government Communications Headquarters, or GCHQ, to infiltrate the Belgian telecommunications company Belgacom. As Der Speigel revealed last year, Belgacom's network engineers were targeted by GCHQ in a QUANTUM mission named "Operation Socialist" - with the British agency hacking into the company's systems in an effort to monitor smartphones. While targeting innocent sys admins may be surprising on its own, the "hunt sys admins" document reveals how the NSA network specialist secretly discussed building a "master list" of sys admins across the world, which would enable an attack to be initiated on one of them the moment their network was thought to be used by a person of interest. One post outlines how this process would make it easier for the NSA's specialist hacking unit, Tailored Access Operations (TAO), to infiltrate networks and begin collecting, or "tasking," data: Aside from offering up thoughts on covert hacking tactics, the author of these posts also provides a glimpse into internal employee complaints at the NSA. The posts describe how the agency's spies gripe about having "dismal infrastructure" and a "Big Data Problem" because of the massive volume of information being collected by NSA surveillance systems. For the author, however, the vast data troves are actually something to be enthusiastic about. "Our ability to pull bits out of random places of the Internet, bring them back to the mother-base to evaluate and build intelligence off of is just plain awesome!" the author writes. "One of the coolest things about it is how much data we have at our fingertips." """

5 6

Re: [cryptography] Compromised Sys Admin Hunters and Tor
by Stephan Neuhaus 22 Mar '14

22 Mar '14

On 2014-03-22, 04:28, Nico Williams wrote: > Insiders are always your biggest threat. I'm always interested in empirical evidence for the things that we believe to be true. Do you have any? Fun, Stephan

1 0

anyone have libtech archives?
by Adam Back 22 Mar '14

22 Mar '14

For old cpunks, who may have been subscribed to libtech: I am curious to lookup some discussion around b-money, bit-gold those parts which were not posted on cpunks at the time. This would be like 1997-2005 say. (I believe it is different to, or an earlier incarnation of the libertech list, at least the archives on that list dont go back that far.) (Presuming that it was not a private/invite only list! If so offlist doc drop:) Adam

1 0

Dynasty of Compromised Comsec and Legal Protection
by John Young 21 Mar '14

21 Mar '14

The marriage of flexible legal protections and malleable comsec is a venerable dynasty of compromise.

1 0

Re: DEFCON On The Mat
by coderman 21 Mar '14

21 Mar '14

"Odinn Cyberguerrilla" <odinn.cyberguerrilla(a)riseup.net> wrote: > > DEFCON On The Mat at what point should you decide to, and to what number, do parrallel'ize the mats? [ i have a conjecture to test during peak mat traffic, congested singleton mat may skew results ... ] best regards, good luck :)

1 0