August 2013 - cypherpunks - lists.cpunks.org

Re: [liberationtech] Interesting things in keyservers
by Eugen Leitl 17 Aug '16

17 Aug '16

----- Forwarded message from micah <micah(a)riseup.net> ----- Date: Sat, 20 Jul 2013 10:05:42 -0400 From: micah <micah(a)riseup.net> To: Micah Lee <micahflee(a)riseup.net>, 'liberationtech' <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] Interesting things in keyservers User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> Hi Micah! Micah Lee <micahflee(a)riseup.net> writes: > I'm working on a talk for OHM2013 about PGP. Can anyone send me examples > of interesting keys in key servers that you know of? Since you are preparing a talk about the subject, I'm going to be pedantic and correct your usage of "PGP", because it is important to get your terminology straight when giving a talk. I presume you aren't giving a talk about the commercial software, but instead you are actually giving a talk about OpenPGP which is the standard specified by RFC4880 that different programs like GnuPG, Seahorse, MacGPG, and PGP etc. all implement. If that is true, then you should refer to it as OpenPGP, and not PGP. I dont know what your talk will consist of, besides the funny enigmail XSS and goatse.cx stuff (thanks for that! always good to have some goatse early in the morning), but I would like to point out a few things that might be useful to mention. One is a wiki page that I created with some people: https://we.riseup.net/riseuplabs+paow/openpgp-best-practices - it contains some useful hints about using OpenPGP, maintaining a good key and some general good practices that people often dont know about (such as the importance of keeping your keys updated to get critical revocation and expiration extension certifications!) One thing mentioned on that page that I wanted to highlight, because you used pgp.mit.edu links in your original email, is that the keyserver pgp.mit.edu is not a good one to use/promote. Everyone uses it as their 'goto' keyserver, but it is a really bad idea! As a keyserver, it has been broken for years. For a long time it was just dropping revocations, subkey updates and expirations on the floor. That is *really* bad. Eventually, they upgraded their keyserver software, but it is *still* running an older version of SKS, a version that fails to handle 16-digit subkeyid lookups (among other failings). So, please don't rely on pgp.mit.edu for your security, and please don't include them in your slides! If you are looking for one to use, I highly recommend using the SKS pool address (hkp://pool.sks-keyservers.net or http://hkps.pool.sks-keyservers.net/ - or if you want a more close geographical pool, have a look at http://sks-keyservers.net/overview-of-pools.php) Finally, there seems to be some amazing misconceptions about keyservers, keys and the web of trust. In particular this http://cryptome.org/2013/07/mining-pgp-keyservers.htm circulated recently and it pained me to see because it suggested various wreckless conclusions that were dangerously off the mark[0] (and used pgp.mit.edu, hah). While it is true that we've jokingly called the OpenPGP web of trust "the original social network" because of the exposed social relational graphing that can be done by querying keyservers, and it is for this reason that many activists I know do not want to have signatures uploaded to keyservers (and instead use the bulky local-only signature work-around)... ... but for some reason people seem to think that if it is on a keyserver, is true, or it means something that it doesn't. People don't realize critical things, such as the fact that I can create a key with the UID Nadim Kobeissi and upload it to the keyservers[1]. That doesn't mean that is the real Nadim's key (this is what exchanging key fingerprints and doing certifications is for, so you can know, with a certain degree of certainty, that this person is the person who controls that secret key material). Or people think that because I signed your key and that signature is on the keyserver that indicates: I trust you; we met in person at that date; we know each other; we are involved in a criminal conspiracy with each other; or many other wrong assumptions about what that certification means. I can sign Edward Snowden's key and send that to the keyservers[1]. Hell, I can sign Snowden's key with my fake Nadim Kobeissi key[1] and then send it to the keyservers. Does that mean that Nadim and Snowden have met in person?! No, it does not at all. Anyways, I can keep going... but I dont know what the focus of your OHM talk is about, so going on like this isn't particularly useful to you and your talk... however, I'd be happy to provide more feedback about your talk if you would like![2] After all, we Micahs need to stick together, micah 0. "the cryptome article just sounds like impenetrable bullshit from someone with no interest in actually understandning what's happening" - I'm not saying who said this... 1. no, I didn't do that, nor did I upload the edward snowden or bradly manning keys. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

4 3

Re: [liberationtech] Why can’t email be secure? - Silent Circle Blog
by coderman 19 Sep '13

19 Sep '13

On Sun, Aug 25, 2013 at 11:59 AM, katana <katana(a)riseup.net> wrote: > ... as Ladar replied in > <http://www.democracynow.org/2013/8/13/exclusive_owner_of_snowdens_email_ser…> > to Amy's question 'Do you think people should use email?': 'Yeah, I > think it’s a great way to communicate ... And I think email still has a > very important role to play in communication between people.' ACK. it is a question of private vs. public communication. email is and will continue to be useful for public communication. this gmail account indexes 190+ lists, 10,000 news alerts from scores of filters (everything from "TS//SI//NF" to "Flame OR Gauss OR Duqu OR Stuxnet" to Goldreich–Goldwasser–Halevi), a total of 643,132 pieces of communication. i can search through all of it in seconds and apply new filters to existing content just as easily as new, and keep an offline backup just in case. but there is zero i would consider private; for that use a medium of communication that is not a usability failure, that is not a metadata leakage nightmare, that is not an operational security mine field. let email _for private communication_ die already, please!

3 4

what to install on a secure communication device
by Eugen Leitl 04 Sep '13

04 Sep '13

I'm looking to build a list for reasonably secure (no snake oil) ways to communicate (search, store, etc.). My ad hoc list so far is: Pidgin/OTR cables Jitsi Tor YaCy RetroShare TorChat Tahoe LAFS GnuNet No doubt I'm missing a lot. Any further suggestions?

7 7

Lavabit and End-point Security
by Sean Alexandre 03 Sep '13

03 Sep '13

I find some comfort in the fact that they had to serve papers to Lavabit to get the information they wanted. To me this says Lavabit's security was so good they couldn't back door his machines. Or, maybe it was cover-up, to get the information "legally." But I'm guessing they really couldn't get what they wanted. I'd love to see some kind of write-up by Ladar about how he did this...maybe even a book. I expect he was just doing all the standard things any sys-admin should be doing. It would be great to see it all written down in one place, though, as a case study with details. Even better: Edward Swowden as a co-author.

12 23

Who bought off Zimmermann?
by StealthMonger 01 Sep '13

01 Sep '13

How ironic and sad it is that Phil Zimmermann, the author of PGP, has become so imbued with the enterprise culture that he's now so blind to the original peer-to-peer spirit of PGP that he would say things like There is no way to do encrypted e-mail where the content is protected. [1] This is simply false. If sender and receiver exchange keys out-of-band and nobody else knows the keys, the content can have cryptographically strong protection. Why would Zimmermann allow himself to be bought off? What kind of pressure is being brought to bear? Is this protracted world-class human engineering in action? [1] http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails-big-privacy-probl… -- -- StealthMonger <StealthMonger(a)nym.mixmin.net> Long, random latency is part of the price of Internet anonymity. anonget: Is this anonymous browsing, or what? http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?… stealthmail: Hide whether you're doing email, or when, or with whom. mailto:stealthsuite@nym.mixmin.net?subject=send%20index.html Key: mailto:stealthsuite@nym.mixmin.net?subject=send%20stealthmonger-key

9 11

So I discovered that my HP laptop leaks/transmits its built-in mic audio somewhere around 24Mhz
by Eugen Leitl 01 Sep '13

01 Sep '13

http://www.reddit.com/r/RTLSDR/comments/1le3if/so_i_discovered_that_my_hp_l… So I discovered that my HP laptop leaks/transmits its built-in mic audio somewhere around 24Mhz (self.RTLSDR) submitted 23 hours ago by cronek I accidentally stumbled upon a signal in the 24MHz range, appearing to be 4 carriers. I tuned to it and heard silence, then someone came into my office and started talking and I could hear them speak. The signal appeared to be coming from my other laptop (not the one running the SDR) and was pretty weak (my antenna, the crappy one that comes with the dongle, stuck to a metal stapler was right next to the HP laptop). Here's a picture Both mics transmit independently, in the picture I rubbed one mic. The signal appears to be mirrored. When I tap the microphone, or make a loud noise that would clip the preamp, the signal drifts off and then slowly comes back to its original frequency, as illustrated here (only one of the two mics drifted, if I hit it harder or clip both mics, both will drift). I'm pretty sure that if I build a nice high-gain antenna optimized for 24Mhz I would be able to pick up the sound from some distance away. The laptop is an EliteBook 8460p. I have checked identical laptops and they do not transmit at this frequency. I didn't have the time to scan the full spectrum though. I'm guessing the preamp is really crappy and somehow ends up transmitting FM at HF freqs. Anyone has any ideas about this? I work in a high security setting and having laptops transmitting audio from everyone's office/meeting room etc is a really big deal. I somewhat doubt it to be an intentional listening device due to the weird frequency drifting. For now I guess I'll just disconnect the mic preamp pcb.

2 1

Re: Who bought off Zimmermann?
by John Young 01 Sep '13

01 Sep '13

Emitting signal that "crypto works" is a hoary practice, nothing more useful than a belief in an uncrackable means of comms, used often in war and commerce and love affairs. Crypto-AG, AES, PGP, Tor, OTR, offline exchange of keys, the list is growing with each disclosure that something stinks in crypto ex-cess. Getting the best and brightest (BAB) to affirm that crypto works, say by open and limited competitions as well as by confidential testing results leaked, would be a part of that campaign. Leaking other forms of attack, like metadata, would be another part, bit by bit, authenticity heightened by obligatory redactions and vetting by quiet government consultation. Presume Snowden dribbling juicy comsec architecture and data, witting or unwitting of their ulterior purpose as beautifully crafted to appear suspicious to BABs but so tasty to be irresistable as a floating British officer corpse stuffed with secret war plans retrieved by the Germans. Until all of Snowden's booty is released and carefully studied by virulently suspicious and paranoid BABs not snared by sweet contracts to muse and declare authenticity, it cannot be seen as more than an ingenious ruse, likely with the complicity of the BABs once believed to be poorly-paid angels dancing on a pinhead. The saluatory benefit of these ruses is to shock the shit out of the lazy and arrogant comfuckers whose stake is put at risk by being left out of the ruse, not easy to do if they are lulled into complacency by admiration, handsome pay, invites to classified dances, insured and pensioned by NDAs, well, hell, why else raise a ruckus with ruses like crypto lists and fora and history confabbing at NSA. None of this is intended to impugn the few BABs who remain outside secret circles, or at least appear to do so in best and brightest ways. And don't invoke a hoary NSL as basis for silence. It does intend to impugn denial of the inevtiable failure of crypto alone or in concert with infrastructure. Remember that 1997 NSA paper foretelling the fail. Was that a ruse too? If I was a BAB looking for a edge on the competition for ruses, I might blurt that crypto deception is the essence of crypto, that is why it works so well.

2 1

[tahoe-dev] reproducible builds for Tahoe-LAFS: where do we start?
by Eugen Leitl 01 Sep '13

01 Sep '13

----- Forwarded message from Zooko O'Whielacronx <zookog(a)gmail.com> ----- Date: Sat, 31 Aug 2013 14:12:07 +0000 From: Zooko O'Whielacronx <zookog(a)gmail.com> To: tahoe-dev <tahoe-dev(a)tahoe-lafs.org> Subject: [tahoe-dev] reproducible builds for Tahoe-LAFS: where do we start? Folks: Here's some recent news: http://m.washingtonpost.com/world/national-security/us-spy-agencies-mounted… That article says that the U.S. espionage agencies have surreptitiously installed sophisticated malware on tens of thousands of remote machines, and have plans to increase that number into the millions. It is important to remember that while the U.S. espionage establishment is the one that is currently having its activities and plans exposed, it is not the only one of its kind. It is safe to assume that there are many other organizations with similar capabilities engaged in similar activities. It is also likely that some of those groups are engaged not in warfare but in industrial espionage or other kinds of theft or sabotage. In this modern world, it would be very useful if you could check whether the binaries that you are running are the same as the binaries that other people are running that were ostensibly built from the same source code. That way, implanted malware would be more likely to be exposed. This is the idea of "reproducible builds", as championed by Tor ¹, Bitcoin ², and Debian ³. LWN.net recently had a nice overview article about this: ⁴. Now: how do we start? We have a trac ticket: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2057# reproducible builds But I don't understand what the next step on the path to really protecting users. The situation we're considering here is that a user is installing Tahoe-LAFS, for example by running "sudo apt-get install tahoe-lafs" on Debian, and the computer that was used to build the tahoe-lafs Debian package had malware running on it, that inserted a backdoor into the tahoe-lafs Debian package. How can we help users to defend against that? There are lots of other packagers which provide installable versions of Tahoe-LAFS to their users. For example, the "pkgsrc/NetBSD" system ⁵, whose Tahoe-LAFS package is maintained by Greg Troxel, who reads this mailing list. If you click on the big friendly blue "Download Tahoe-LAFS" button on the front page of https://Tahoe-LAFS.org, it takes you to a menu of packages provided by different free-and-open-source operating systems. One thing that worries me about this issue is that it is one of those things were different open source projects can reasonably assume that it is Someone Else's Problem to fix this. I've often seen this: when there is an issue that spans multiple open source projects, that it is hard to make progress on that issue, since every open source project has a theory of how it ought to be fixed by some other open source project taking responsibility for it. So what can we do to push on this issue now? Regards, Zooko ¹ https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and… ² https://en.bitcoin.it/wiki/Release_process ³ https://wiki.debian.org/ReproducibleBuilds ⁴ http://lwn.net/Articles/564263/ ⁵ ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/filesystems/tahoe-lafs/READM… _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [liberationtech] Why cant email be secure? - Silent Circle Blog
by John Young 31 Aug '13

31 Aug '13

A swell beginning, for email to be merely one way to communicate, supplemented with unlimited other ways which do not require email, or for that matter, the Internet or any digital means. Presume that digital means are the easiest to fuck with, sorry, subvert, corrupt, pack with junk, surveil, harvest, store, search, forge, track, make your own list on your digital device and expect it to be violated accordingly and used against you whether you know or not, usually not. Here especially. Now the other means, non-digital, ancient and amply used and understood among those who use them although susceptible to the digital vulnerabilites if considerable more difficult: Paper Music Sound Dance Architecture Plastic arts Graphic arts Poetry Drum Glossalia Jokes Holler Gypsy Mime Chant Curse Vulgarity Sex Sin And much more everybody uses with greater facility than digital emissions. Note that conventional lanugages are not on the list because of the heavy reliance upon them to communicate and thus most heavily scutinized and attacked, usually successfully. Language is like metadata, with only its mastery the content can be followed from end to end, then the ends burgled, beat, cut, shot, persuaded to talk in plain language. Steagonagraphy is not on the list unless it is non-digital, and if not, then hiding communication has great potential. Its weakness is finding a means, non-digital, for preparation and transceiving. For example, architecture is an ancient means of communication, among its funders, designers, builders, maintainers, destructors, restorers, investors, evaluators, burgler, surveyors, surveillors, protectors, attackers, underminers, repairers, materials suppliers, excavators, and a host of participants -- the list of guilds and unions and professionals is vast -- perhaps one of the largest cohorts of quasi-private aggregations on earth lagging only farmers if taken to mean any form of human construction. I flatter myself, so do yourself likewise. Similarly, just about any specialty of human intercourse has its quasi-private, esoteric, unique means of communication. The human body specialists -- scientific, shamanistic, soulseeking -- along with its pschobabbling corollary, generates a fantastic array of marketable, if not wholly, believable garble and gibberish. Politics and law the most vivid at laying on the self-serving shit about the necessity of government and the rule of law(yers). Now back to the simple task of communicating in private. Before that, a side note, the end is near: First do not expect anyone to believe anything using the word "security." So comsec is dead due to abuse. Maybe compriv is better, understanding that privacy has become a crock of shit too. "Shit bag" (thanks to Assange) Natsec needs to go as well because it has been abused the most of all since assuming the parmount importance of a secular religion prevailing over all belief-systems with deadly weaponry, heartlessness, amorality, criminality and unaccountability, motto: fuck with it and you will die. Much evidence of motto in deed. And much evidence it will be used against its insiders. This is relevant to private communication. Natsec really hates being cut out of any kind of communication. It will use virtually unlimited means to get inside, most of them kept secret and manifestly violent if needs be. So compriv should not be promoted as capable to exclude natsec's prying, stealing, owning, using to demolish with its opponents. OTR is futile, BTW, as comsec. Wind compriv down to comchat. Then wind comchat down to comgossip, to comwhine, comjoke, comlie, comlurk, comslur, com-social engineer. You get the point. Do nothing life-threatening or natsec defying by com-whatever. Communications is owned by those who provide its means and they are owned by extremely badass natsec ritualists willing to barbecue your beloveds to share the goodness carefully prescribed in their secret manuals of unlimited warfare. In conclusion, there you have it, com-bat, the most reliable means of communication. Anything less is com-ical.

3 2

Re: [tor-talk] About time to make BitTorrent work over Tor,
by Eugen Leitl 31 Aug '13

31 Aug '13

----- Forwarded message from grarpamp <grarpamp(a)gmail.com> ----- Date: Thu, 29 Aug 2013 04:09:35 -0400 From: grarpamp <grarpamp(a)gmail.com> To: tor-talk(a)lists.torproject.org Subject: Re: [tor-talk] About time to make BitTorrent work over Tor, Reply-To: tor-talk(a)lists.torproject.org On 8/26/13, Kostas Jakeliunas <kostas(a)jakeliunas.com> wrote: > On Mon, Aug 26, 2013 at 2:46 PM, Nathan Suchy < > theusernameiwantistaken(a)gmail.com> wrote: > >> I don't want this for piracy as I have a paid VPN account that is much >> faster for that if I decide to pirate. I think we need BitTorrent though >> to >> work on Tor so Tor Users can securely share files with one another. > > > AFAIK the most obvious issue with this (among more subtle side-channel > attack / decloaking problems) is network scalability. Total relay bandwidth > available is, while seemingly increasing in general, very limited given > such use cases. [1] How does one scale BitTorrent on top of that? > ... > But perhaps there's still some discussion to be had. I'm sure this has been > discussed myriads of times, however - maybe it's worth trying to browse > through the mailing list archives. > > [1]: https://metrics.torproject.org/network.html#bandwidth Technically, Bittorrent works fine when run completely inside Tor. The resources needed at the client are reasonable (ie: cpu). The bandwidth is currently reasonably available. And onions are secure enough for people who insist on skirting copyright. That alone makes me wonder why Tor hasn't grown any long lived torrent clouds. Probably because the entry bar is high and the slower speed is beyond the scope of the typical leeching mindset. What people should know is that Tor currently can't handle it at scale in at least two areas... Transferring 1MiB causes about 7MiB worth of reduction in Tor bandwidth, plus the CPU and state for processing the circuits. You can get that back by running relays, but the vast bulk of the above users probably won't be willing or bothered to do that, let alone be able to figure out how to do it right and in conjunction with their BT app. So Tor is likely to tank from that alone. Then assuming they did run relays, the last part is dealing with N million users worth of relay and onion descriptors. That takes out more bandwidth, the dirservers, and everyone's local cpu and ram. For those reasons, it's hard to truly push mass use of p2p over Tor. Yet I think given the greater probability of a p2p influx as time goes on [1], Tor really should have some prepared design considerations on the table beyond "please don't do that", which torrenters obviously ignore. Hopefully designs can be found that aren't restrictive. [1] Pick any hot p2p app, drop N million users worth on Tor. In this thread it's BT... being driven slowly towards anonymous systems by the anti's [today, Russian blocking], enhanced by piratebrowser giving hints to millions of users "Hey, what's this Tor thing? What are these onions I see there? Hmm..." -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

5 4