- cypherpunks - lists.cpunks.org

Alternatives to Lavabit
by Stakewinner00 26 Aug '13

26 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now that Lavabit is off, we should seek another server with encryption. My question are, there are another encrypted email service like Lavabit? Or we have to create a new encrypted email service? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEVAwUBUhfOC2nZMKDLC/xbAQKUMQgAjls2AY+VZpY4PEudvb5Dc5c+7SOYehHC 8GVDwkXRI+Pp09e3aTK5lYaij7fQZ/aGO3lGnr8Hm7s0xRYig7hpCPiIymJ/O9Kq i0nQibqMrgLTter/7MkIbyjsmAvO1hYE8rbct1snk2JIDjw/gkLi4kzxtMd5h2qn RZoMmAKgZlDou4MUDrpA9iTvRQY8qisB+27wAHgDYxtZzejdr0b2pNZxsaUwOLXv EjASFiBPi07DyZqrDHUArGyiIMQn2sBqEEzmKvUrp4DTm1IT/B6e7A5tUhkDAX7r ThcD2rKK43Kqog+zPogDJ8Hp3lhB7aR0QPTP3ILq7ioKmy+nvnQzOw== =YEFA -----END PGP SIGNATURE-----

2 1

Re: Who bought off Zimmermann?
by Bill Stewart 26 Aug '13

26 Aug '13

At 07:09 PM 8/25/2013, Shawn K. Quinn wrote: >On Sun, Aug 25, 2013, at 07:36 PM, John Young wrote: > > Phil probably means the infrastructure of email is the vul not the > > crypto. Crypto alone is sterile, a boy in a bubble which requires > > life support which can be assaulted. > >I think Phil is referring to traffic analysis. We solved this problem >already somewhat with Mixmaster, but it's cumbersome to impossible to >use for everyday email. It's not just traffic analysis, though that's another layer of the problem. And it's not just the issue of PGP being hard to run on some phones, though that makes it a problem for users of those phones. Phil's not just a cryptographer; he's primarily a service provider here. If you assume that the NSA can come to you with a FISA court order overriding ECPA, saying "Give us every piece of information that anybody sends you, including your subscribers and outsiders who want to send email to them, any time any new bit of information arrives, Or Else!" then you can't run a "secure" email service that accepts unencrypted email, because what you have isn't secure against that threat model. If the NSA and their rubber-stamping buddies at FISA aren't stepping way over the bright shiny constitutionality line, you could run an email service that automatically PGP-encrypts any incoming message to a public key associated with the mailbox, and build a user interface for the mailbox client's device that's not totally annoying. The fact that Phil and Jon say they can't run a service implies that the threat model includes mail in transit, not just mail delivered to a mailbox. You might be able to run an email service that scans inbound email for an X-PGP-Encrypted: header, and if it sees "From:" or "Subject:" first, bounces the email with a 503 or 550: "Sorry, Encrypted Email Only, Get PGP at www.pgp.com", but that's really more annoying than just using Gmail with a user name pgp-only-johndoe43(a)gmail.com. An alternative threat model is that the NSA declares anybody sending encrypted mail to be a target (s/target/weasel-word-of-the-week/g), so any ISP that sends data to silentcircle.com has to allow the NSA to wiretap their connections, just in case they might be encrypted email. The effects are similar, though it wouldn't provide access to the contents of encrypted SMTP sessions; Phil and Jon might also be refusing to handle email because of this slightly less aggressive threat model. Bill Stewart

4 4

Re: [liberationtech] Why_can't_email_be_secure
by Bill Stewart 26 Aug '13

26 Aug '13

At 01:40 PM 8/25/2013, coderman wrote: >and to StealthMonger's point about latest generation mix networks for >best privacy, why not instead focus on building low latency protocols >that are resistant to traffic analysis and confirmation? Because "low latency protocols that are resistant to traffic analysis" is a really really hard problem. Even doing "high latency protocols that are resistant to traffic analysis" is a really hard problem. "Building" them is a mere application of sufficiently advanced technology, right? >make them datagram based; utilize user space stacks Datagrams don't give you any useful anonymity, because any decent ISP is going to block forged-source packets, but they do give you a bit more flexibility about timing, which is important for defending against traffic analysis. The standard warning about using them for an application is that it's extremely tempting to use them to reinvent TCP badly, because TCP really does a lot of things you want, and in a security context it's tempting to also reinvent TLS badly. Some other problems with them are that you need to get firewalls to allow them through, unless you disguise them as other protocols like the horribly evil things Dan Kaminsky regularly does to DNS, and if you don't disguise them then they stick out like a sore thumb on any IDS or netflow analyser. And if you're the only person using that protocol, you're not hiding from traffic analysis. It's a lot easier to hide if you implement your datagrams as http/https transactions of some kind, but building a bunch of relay nodes to pass those transactions along ends up reinventing Tor. Putting them in user space is just fine and mostly more portable. It's hard to get millisecond-level latency if you do that, but you can't hide from traffic analysis with latency that low anyway.

2 1

Re: Who bought off Zimmermann?
by Bill Stewart 26 Aug '13

26 Aug '13

At 10:45 PM 8/25/2013, Shawn K. Quinn wrote: >Though I think the following poster who >suggested scanning the email itself for the PGP identifier might be more >useful and less prone to being fooled by someone who just puts the >header in there without actually encrypting. Anybody who's putting in the header without doing the encryption is going out of their way to ask for trouble, and presumed to be doing it on purpose, whether for entrapment or denial of service or whatever. As long as you don't make it easy to do by accident, it's not a problem. >Also, headers don't have to >be in a specific order, it's possible that "From:" or "Subject:" >accidentally get moved ahead of "X-PGP-Encrypted:" by mistake and that >would result in a false bounce. The threat model I was worrying about was that if you get to From: or Subject:, and you're subject to an NSA Vacuum Cleaner Order, you've got potentially sensitive information about your users or their contacts that you could be forced to retain and turn over. You need to reject the message before you see that, which means checking the header keyword before you accept any characters past the :. And yeah, that means you could get false bounces, but hopefully anybody who's trying to hide their identity from the NSA will leave those headers out of the cleartext part of the message anyway. Ideally you don't even want the SMTP-level FROM keyword, but it's probably hard to get most MTAs not to send that one.

1 0

Re: [liberationtech] Why_can't_email_be_secure
by coderman 26 Aug '13

26 Aug '13

On Sun, Aug 25, 2013 at 12:26 PM, Ali-Reza Anghaie <ali(a)packetknife.com> wrote: > ... > And herein lies the problem - Silent Circle isn't talking to "us" - > they are talking to the other 99.99% of email users in the world. and to StealthMonger's point about latest generation mix networks for best privacy, why not instead focus on building low latency protocols that are resistant to traffic analysis and confirmation? make them datagram based; utilize user space stacks and latest research. solving the low latency datagram anonymity problem enables existing usable private communication with the additional benefit of endpoint and peer anonymity. i believe this possible to make useful, even if never infallible. certainly more possible than the odds of making truly scalable, available, and _usable_ mix mailer networks and clients for the masses. most important: make this low latency infrastructure usable and cross platform, so the implementations are easily adopted... like Napster and BitTorrent back in the day. ;)

2 1

Avaaz in "grave danger" due to GMail spam filters
by rysiek 26 Aug '13

26 Aug '13

OHAI, I happen to be on Avaaz's info distribution list, and I got an e-mail lately that Avaaz is in "grave danger" as GMail will now filter mailings like that out to a separate folder for similar spam-ish (yet not spam per se) mailings. So what they're asking people to do is to reply directly to that e-mail, so that GMail will note that Avaaz's mailings are not to be messed around with. Instead of telling people, you know, to decentralise and use other, smaller providers. I facepalmed so hard I could cry. It's Stockholm Syndrome if I ever saw one. "GMail fucks us in the arse, so let's ask them politely to use some lubricant". My question is: does *anybody* on this list have some kind of contact within Avaaz? I'd *love* to talk to them about it. It's simply disingenuous to do such a campaign and *not* at least signal "oh and by the way, had we all been still using different, dispersed, decentralised e-mail services we wouldn't get even close to having this problem". -- Pozdr rysiek

14 36

Equilibrium 51% Attack Cost of Bitcoin Network
by Rich Jones 26 Aug '13

26 Aug '13

Nifty little tool showing the estimated cost of controlling the majority of the Bitcoin network: https://www.resallex.com/bitcoin/brix Would love to see something similar for the Tor network - my guess is that the cost there is probably at least an order-of-magnitude lower, but that's just my intuition. R >From the site.. > Introduction > > *Equilibrium 51% Attack Cost:* This is a metric attempting to calculate > the total present value cost required to attack the Bitcoin network through > majority hashing power (51% attack). The metric is meant to be viewed as a > snapshot in time as if an attacker decided to invest in attacking the > network under the current conditions. > *BRIX Score:* "Bitcoin Robustness Index" - The relative rank of Bitcoin's > 51% attack cost compared to annual military expenditures among all nations. > Method This metric is, in essence, equal to 51% of the present value > ("PV") of all future revenues derived from bitcoin mining using current Mt. > Gox prices. Revenues include both block rewards and transaction fees. The > purpose behind using PV as a measuring tool is to approximate the > incentives to miners to build upon the Bitcoin network. The measure can be > viewed as an aggregate of all the cost-benefit analyses done by individual > miners. We believe this is superior to other methods of calculating the > attack cost, including variables such as current hash rates and current > capital costs, because the model is independent of technology advancements. > Under the equilibrium model, miners will continue to invest in equipment > until they reach the point where marginal cost equals marginal revenue (the > point of profit maximization). Under perfect competition (of which bitcoin > mining is effectively), this point will also be where aggregate cost equals > aggregate revenue. If we assume the variables that can affect mining > revenue are held constant ($/btc & transaction fees), then it is easy to > calculate aggregate revenue and therefore also aggregate cost. Since we > know aggregate revenue equals aggregate cost, by calculating 51% of > aggregate revenue we effectively calculate 51% of the aggregate cost to > miners. > > > We calculated this metric by discounting each block reward (210,000 > blocks) as if it were an annuity and then discounting it further to its > present value. Then, we added estimated transaction fees based off > historical records. > Assumptions > > This metric is meant to represent a model at equilibrium. Therefore it > represents a snapshot of 51% of the incentive to miners at the current > price and current transaction fee levels. The idea is that miners are > willing to invest in the network as long as it is profitable to continue > doing so. We assume the following: > > - * Rational Actors: * We assume all mining participants are rational > actors and strictly pursue profit maximization. We ignore all other > motivations, including political, emotional, and reputational. All other > heuristics and biases are ignored. > - * Static Variables: * We assume that the variables in the model are > static, and therefore represent a 'snapshot in time'. There are no growth > forecasts for either price or transaction fees. > - * Perfect Competition: * We assume that all miners and potential > attackers have access to the same technology, resources, and information. > There is no technological advantage for any party that would exclusively > decrease mining costs or otherwise acquire mining equipment faster. > - * Discount Rate: 8% * Our model discounts future cash flows by 8%. > >

2 1

Re: [FoRK] [liberationtech] Fwd: [riseup] Space for dissent
by dan＠geer.org 25 Aug '13

25 Aug '13

[ cross-posting will fail unless someone else wants to do it ] The leading snippet of the forwarded piece, > What surveillance really is, at its root, is a highly effective > form of social control. The knowledge of always being watched > changes our behavior and stifles dissent. The inability to associate > secretly means there is no longer any possibility for free > association.... is called "anticipatory compliance," a term due to Shoshana Zuboff who said "[W]e anticipate surveillance and we conform, and we do that with awareness. ... Once anticipatory conformity becomes second nature, it becomes progressively easier for people to adapt to new impositions on their privacy, their freedoms. The habit has been set," and that quotation is from a couple of decades ago. More recent and more relevant to this topic is this: http://www.faz.net/aktuell/feuilleton/the-surveillance-paradigm-be-the-fric… which is too long to quote and too good to abridge. Speaking for myself, I touched on this in my column for IEEE S&P of last January, Identity as Privacy http://geer.tinho.net/ieee/ieee.sp.geer.1301b.pdf In the meantime, and with allowances for approximation, as of 2013, it is possible to: recognize your face at 500 meters recognize your iris at 50 meters recognize your heartbeat at 5 meters recognize your gait by your smartphone via its accelerometer read your keystrokes on your smartphone via its accelerometer identify your car from its Bluetooth tire pressure sensors geo-locate you indoors via Wifi interaction with other devices know what you are doing via your Smartgrid elec meter identify you even if you never post photos; someone else has read 1" block letters from orbit etc. Disconnecting as a purposive decision is no longer a mere reaction to the demise of some "expectation of privacy" but rather the realization that the Internet is more and more a tool of control, not emancipation. As the source of risk is dependence, risk reduction goes straight to dependence reduction. --dan _______________________________________________ FoRK mailing list http://xent.com/mailman/listinfo/fork

1 0

Re: [cryptography] urandom vs random
by Eugen Leitl 25 Aug '13

25 Aug '13

----- Forwarded message from Peter Gutmann <pgut001(a)cs.auckland.ac.nz> ----- Date: Thu, 22 Aug 2013 23:05:50 +1200 From: Peter Gutmann <pgut001(a)cs.auckland.ac.nz> To: cryptography(a)randombit.net Subject: Re: [cryptography] urandom vs random Just appeared on the GnuPG list: NeuG 0.11 was released. NeuG is an implementation of True Random Number Generator based on quantization error of ADC of STM32F103. It is basically intended to be used as a part of Gnuk, but we also have standalone USB CDC-ACM version (you can get random stream from /dev/ttyACM0). Standalone version is useful to feed entropy to /dev/random on GNU/Linux. Its generation speed is >= 50kB/sec, and it's more when connected to USB 2.0 Hub. The output is tested NIST STS 2.1.1 and Dieharder 3.31.1. Highlights are: * Replacement of kernel (thread library) Instead of ChibiOS/RT, we now use Chopstx. * Improved performance The output of random numbers got faster than the previous implementation by 30% or so. * Unsupported targets CQ_STARM, STBEE, STBEE Mini, and STM32_PRIMER2 are not supported in this release, but porting should be easy. Here are some links for NeuG, Gnuk and FST-01 (the hardware). NeuG (under Gnuk Repository): http://gitorious.org/gnuk/neug Gnuk News: http://www.fsij.org/gnuk/ FST-01 introduction: http://www.seeedstudio.com/wiki/index.php?title=FST-01 FST-01 Q&A site: http://no-passwd.net/askbot/questions/ Japanese Documentation for FST-01 and Gnuk Token: http://no-passwd.net/fst-01-gnuk-handbook/index.html Enjoy, _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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: [tor-talk] Appearing American and VPNs writ large
by Eugen Leitl 25 Aug '13

25 Aug '13

----- Forwarded message from Griffin Boyce <griffinboyce(a)gmail.com> ----- Date: Fri, 23 Aug 2013 13:51:09 -0400 From: Griffin Boyce <griffinboyce(a)gmail.com> To: tor-talk(a)lists.torproject.org Subject: Re: [tor-talk] Appearing American and VPNs writ large User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 Reply-To: tor-talk(a)lists.torproject.org On 08/23/2013 12:41 PM, Nathan Suchy wrote: > I'd beg to differ. There are very good VPN providers that keep absolutely > no logs so you would have anonymity in that case. I think a commercial vpn > without logs is the best way to go but you could also handpick nodes (tor > needs to have a auto feature which can auto pick nodes by country. Covert > Browser for IOS allows you to pick your exit node. You're assuming that there's endpoint anonymity and that no one could correlate you connecting to Server A and a piece of traffic coming from Server A at the same time. At a basic level, this type of correlation is responsible for Jeremy Hammond's arrest (his VPN disconnected from IRC right as he lost internet -- deniability is useless here). And any iOS device is likely keeping track of your recent server connections. If I had a week, I couldn't list all the cases where someone mislaid their trust in a service provider to protect them. Deniability is dead. What Tor provides is unlinkability. best, Griffin -- "Cypherpunks write code not flame wars." --Jurre van Bergen #Foucault / PGP: 0xAE792C97 / OTR: saint(a)jabber.ccc.de My posts, while frequently amusing, are not representative of the thoughts of my employer. -- 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

1 0