- cypherpunks - lists.cpunks.org

Bitcoin mining ASIC decapped
by Peter Gutmann 30 Sep '14

30 Sep '14

In case anyone's interested, this site: http://zeptobars.ru/en/read/bitfury-bitcoin-mining-chip has some photos of what looks like a decapped Bitfury ASIC. It's a pretty unique structure... Peter.

3 2

Julian Assange Speaks with teleSUR English
by Damian Fossi 30 Sep '14

30 Sep '14

http://www.youtube.com/watch?v=POzBnAT7ZoQ In an exclusive interview with teleSUR English, WikiLeaks founder Julian Assange has warned Google has “lulled” the world into a false sense of security. WikiLeaks founder Julian Assange has warned Google and the U.S. government are collaborating to create the most advanced surveillance state the world has ever seen. In a secret meeting in 2011, Assange says he caught a glimpse into the inner workings of the Google “empire,” and its intimate relationship with the U.S. government. “Google is literally in bed with the State Department,” he told teleSUR English in an exclusive interview. -- Damián D. Fossi Salas > ¡Software Libre hasta el 2 mil siempre! http://damian.fossi.me Uso: Debian GNU/Linux con Kernel 3.12.6-libre Linux User: 188464 Jabber ID: dam1an en chat.cpunks.us Twitter.com > http://twitter.com/dam1an

1 0

Manufacturing open hardware
by bluelotus＠openmailbox.org 29 Sep '14

29 Sep '14

http://www.datamation.com/open-source/what-linux-users-should-know-about-op…

1 0

Re: Re: bashing your head against nation-state social engineering
by Subrosa.io 29 Sep '14

29 Sep '14

I think this vulnerability should have been discovered with any kind of basic fuzzing. I have little doubt that this has been discovered and has been exploited in the wild. How is Mirage OS promising and relevant here? ---- On Sat, 27 Sep 2014 14:48:24 -0400 Travis Biehn wrote ---- >From: Travis Biehn <tbiehn(a)gmail.com> >To: Lodewijk andré de la porte <l(a)odewijk.nl> >Cc: "cypherpunks(a)cpunks.org" <cypherpunks(a)cpunks.org> >Subject: >Message-ID: > <CAKtE3zcZ9LuBKvJnFm_RJ3te=MotchXXDioJa17291uHUvFJFg(a)mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >I'm partial to Joanna Rutkowska's statement that "Security by Isolation" is >the best course followed for -users- of software. [in addition to all the >patching and whatever.] > >Developers of that software, ultimately, are responsible for securing their >stuff. As an aside - separating your complex system into multiple trust >zones, from a development standpoint, is de-rigueur for secure design. > >Security heads have long been decrying cgi-bin. Most of the reason is that >the threat surface is insane - for binaries you have user input that's not >running in some sort of VM [php,perl,ruby,node.js, etc] and existing in >memory entangled with executable instructions. > >Injection attacks, are, of course old-hat. The daemons could have done some >hand-holding in this respect before passing off headers to ENV variables. > >The issue is that 'restricted chars' wasn't defined by a standard interface >between daemon and cgi-bin script. The called function has a completely >arbitrary set of restricted chars. >/bin/bash, of course, isn't written to withstand env attacks - since the >calling user controls the env / and bash is executed under that user's >privileges. >So it is, of a matter of course, inevitable to find vulnerability there. >With one process isolating the client from the env, modifying the env as a >result of the user's whims and then passing off to a sub-process that >trusts the env implicitly. > >It is very unlikely that any TLA 'created' this vulnerability. The notion >is entirely incredible. The existence of vulnerability in such a design is >immediately obvious from anyone who takes more than a cursory look at it. >That isn't to say that this specific attack was trivial to identify - that >is to say from an architecture standpoint it should be evident that the >handoff between httpd and cgi-bin is a location of extreme vulnerability. > >On a related note: Mirage OS looks like it's on a promising tack: >http://www.xenproject.org/developers/teams/mirage-os.html > >-Travis > >On Sat, Sep 27, 2014 at 12:49 PM, Lodewijk andré de la porte <l(a)odewijk.nl> >wrote: > >> Know what you code, and what you run. Don't be fooled by words and shapes, >> code does what code does, that is all. >> >> We seriously need a way to detach code from mental models to expose hidden >> features. Basically, all computer law is rubbish because everything you run >> on your computer, exploits and all, is something you run by choice. But >> there's no way you could validate the sheer bulk of code. If you want to >> really solve security flaws it'll involve somehow validating the >> possibilities of the code run. >> >> It's a discipline that touches on visualization, automated testing and >> simplification. Simplification meaning, reducing possible states and >> "execution paths". And just making code easier to comprehend. >> >> The problem is that there's either no market for "truly secure" computing, >> or there's just nobody filling the gap. Banks with their Cobol are laughed >> at, mostly, and accused of lacking innovation. They do lack innovation in >> the technical field. And Cobol is definitely not an ideal language. But >> "truly secure" is worth a lot to them. L4 validated is a step in the right >> direction, but catches a lot of wind saying it's still imperfect and >> therefore worthless. >> >> I'm utterly bored by code review. Maybe it'd be better if there were some >> nicer tools to help out. I'm really sure someone has great recommendations >> regarding this. (That don't even require Cobol :) >> > > > >-- >Twitter <https://twitter.com/tbiehn> | LinkedIn ><http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn> >| TravisBiehn.com <http://www.travisbiehn.com> | Google Plus ><https://plus.google.com/+TravisBiehn> >

4 3

bashing your head against nation-state social engineering
by Troy Benjegerdes 28 Sep '14

28 Sep '14

the recent bash exploit seems to have all the hallmarks of a sophisticated nation-state attempt to insert backdoors into debian and lots of embedded devices. Any thoughts? How do you defend against an adversary that uses social engineering and psychology to convince developers to add a new feature to an 'essential' package that can then be exploited? To any of you in the NSA and NNSA with clearances, here's a question for you: how many US government systems have bash installed, and can your admins running the world's largest supercomputers run them without having a pre-loaded exploit train pre-installed? This is like the mother-of-all advanced persistent threats, so it would be a good idea to figure out a way for those of you might know, but can't publicly disclose to figure out how to let the rest of us know how to defend against this. Maybe DARPA will post some interesting new RFPs? -- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer(a)hozed.org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash

4 6

Torrent of Cryptome archive 2014-06-02 (22GB)
by ban＠unseen.is 27 Sep '14

27 Sep '14

https://thepiratebay.se/torrent/11113511/Cryptome_archive_2014-06-02 # Cryptome Archive from 2 June 2014 magnet:?xt=urn:btih:F5763EB5C5FFD8B40B9047CF72350D320A59BDAC&dn=cryptome-archive-2014-06-02&tr=udp%3a%2f%2ftracker.istole.it%3a80 https://zoink.it/torrent/F5763EB5C5FFD8B40B9047CF72350D320A59BDAC.torrent #Donate to John from Cryptome.org for collecting this files: http://www.cryptome.org/donations.htm #This is the Cryptome Archive as provided by coderman on a Tor hidden service: The three wikileaks files mentioned in the post are included in the USB-2.rar #Verify with GnuGPG: The files Update-13-1231.rar, USB-1.rar and USB-2.rar have a *.sig file which can be used to verify the files. That key 0xb650572b8b3bf75c is published on http://www.cryptome.org/#Cryptome%20PK and is available on keyservers like http://pgpkeys.eu:11371/pks/lookup?op=vindex&search=0xb650572b8b3bf75c #Torrent of old Cryptome Archive from 2011: https://thepiratebay.se/torrent/7919294/Cryptome_Archive_2011_Unverified magnet:?xt=urn:btih:ba401110a60ad844a09d4219e5f95a46385f7410&dn=Cryptome+Archive+2011+Unverified&tr=udp%3A%2F%2Ftracker.istole.it%3A80

1 0

Informing the user they have the wrong key
by Tony Arcieri 27 Sep '14

27 Sep '14

If we build fancy systems to detect things like misadvertised keys or MitM attacks, how can we reasonably inform an end user what is amiss in an actionable way that won't confuse them with too many false positives to avoid taking action when something bad actually happens? I recently went to SOUPS and saw a number of presentations on the general difficulty of communicating security-actionable information to users. From what I saw I'd say the problem is twofold: 1) How does the system provide a high confidence level that when it tries to communicate a security-actionable event, it's fairly certain it's not a false positive? False positives condition users to ignore security warnings 2) How do you express what's happening to the user in such a way that they will actually take action on it and not just click-through dismiss it? Given the wide-ranging number of scenarios, the answer will of course be contextual, and I'd be curious to hear any replies about how systems try to solve the "right key" user experience problem in general. That said, the messaging use-case (in conjunction with a "key directory" system) is particularly interesting to me. If an end-to-end encrypted messaging system which relies on a centrally-managed key directory (e.g. iMessage) were to by coersion or compromise publish a poison key to their directory to facilitate a MitM attack, but the system creators wanted to make such action obvious to their users, how can the systems reasonably detect and reflect this in such a way that such users aren't conditioned to ignore such alerts for routine events (e.g. the SSH "SOMETHING NASTY" message) and actually feel compelled to take action on that knowledge? And then what? How can we help someone who is a victim of an attack like this actually compile all of the necessary information for someone to figure out what actually happened? How can encryption tools compile incident reports that experts can scrutinize to determine what happened? -- Tony Arcieri

1 0

Re: GoldBug SF projects [was: Bittorrent Bleep]
by grarpamp 24 Sep '14

24 Sep '14

On Tue, Sep 23, 2014 at 4:50 PM, Dmitrij D. Czarkoff <czarkoff(a)gmail.com> wrote: > Hi! > >> Attn czarkoff: Background threads for reference in your wikipedia work >> https://cpunks.org/pipermail/cypherpunks/2014-September/thread.html >> https://cpunks.org/pipermail/cypherpunks/2014-September/005505.html >> >> keywords: goldbug messenger, firefloo communicator, lib spot-on, echo >> protocol, cassiopeia bitmail, dooble web browser, interface social >> network > > I am not sure how I can help here. In those threads and links following from the above are people showing that these 'goldbug' related projects have serious trust issues and may be some form of malware/crapware. Read the linked threads for more info. If you search around wikipedia for these projects and look at their edit, talk and contributor histories you can find their edit trails there. Bogus listings is their way of free advertising and luring gullible users to them. I don't know much about how these things are handled within wikipedia community. But I have seen articles that have 'Controversy' sections in them. So if I were an editor I'd add exactly such a controversy section to all the pages... that some people see big issues with these projects. And back it up with links out to these threads on the cpunks, gnupg, and tor lists. At least that way it's on wikipedia history for people to see. http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/GoldBug_(softw… http://en.wikipedia.org/wiki/Draft:GoldBug_(software) http://en.wikipedia.org/wiki/GoldBug_(Instant_Messenger) http://en.wikipedia.org/wiki/Echo_(communications_protocol) Saw your arguments on the deletion page and figured you would like to be aware of these issues as well.

3 2

Where's a human-like randomizer?
by Douglas Lucas 23 Sep '14

23 Sep '14

I've an odd question. Is there a program that will generate passwords that imitate the badness with which humans armed with pen and paper only would generate randomness? No, not a program that spits out "password" over and over, that contemptible most frequently used password; I'm imagining an English speaker of above average intelligence who has some familiarity with best practices for coming up with passwords, but who's no mathematical crypto wizard or anything. Imagine a human who wants to generate an alphanumeric passphrase with both upper- and lowercase, and he's in a jail cell with just pen and paper. So he has a set of 62 characters to work with, and he tries to write out a truly random password. But maybe he puts "M" in the password too often for it to be truly random, because his name is Mario, so he thinks about "M" unusually often; or maybe his writing surface is shaped such that it incentivizes long downstrokes, so he pens the letter "l" too often for true randomness. Now, has anyone created a computer program to MIMIC what that human would come up with? Is such a thing possible? Obviously I could simply do it myself as a human being by, you know, qrMt8x3, but I want a program that will create that for an x-long, say, 80,000 character-long, string.

2 1

SENTER Sandman: Using Intel TXT to Attack BIOSes - request for slides / transcript
by coderman 23 Sep '14

23 Sep '14

anyone have details on: SENTER Sandman: Using Intel TXT to Attack BIOSes - http://2014.hack.lu/index.php/List#Xeno_Kovah.2C_Corey_Kallenberg.2C_John_B… """ At CanSecWest 2014 we presented the first prototype of Copernicus 2, a trustworthy BIOS capture system. It was undertaken specifically to combat our “Smite’em the Stealthy” PoC which can forge the BIOS collection results from all other systems (including our own Copernicus 1, the open source Flashrom, Intel Chipsec, etc). Copernicus 2 makes use of the open source Flicker project from Jon McCune of CMU which utilizes Intel Trusted Execution Technology in order to build a trustworthy environment from which to run our BIOS measurement code. We specifically chose TXT because it has the ability to disable System Management Interrupts (SMIs) effectively putting the SMM MitM, Smite’em, to sleep. But if you’ve been following our work (specifically “Defeating Signed BIOS Enforcement” and “Setup for Failure: Defeating UEFI SecureBoot”) you will have seen that we have two other attacks where we leverage the ability to suppress SMIs to break into some BIOSes. Thus the Sandman cometh! We will explain how we could implement the PoC Sandman attack using the same infrastructure as Copernicus 2. We will also explain what can be done against this kind of attack, and how the latest Copernicus 2 attempts to prevent opening the door to the Sandman. We will also cover how Copernicus 1 and 2 can check for the problems with BIOSes that make SMI-suppression attacks feasible, how to tell if you’re vulnerable, and what you may be able to do about it. """

1 0