- cypherpunks - lists.cpunks.org

Re: [liberationtech] Fwd: Firefox OS with built in support for OpenPGP encryption
by Eugen Leitl 13 Sep '13

13 Sep '13

----- Forwarded message from Michael Rogers <michael(a)briarproject.org> ----- Date: Fri, 13 Sep 2013 10:56:49 +0100 From: Michael Rogers <michael(a)briarproject.org> To: liberationtech <liberationtech(a)lists.stanford.edu> CC: Eugen Leitl <eugen(a)leitl.org> Subject: Re: [liberationtech] Fwd: Firefox OS with built in support for OpenPGP encryption User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/09/13 10:04, Eugen Leitl wrote: > Baseband processors leave the system wide open to all kind of > attacks. Countermeasure would be running the 2G/3G/4G stack in an > open source SDR radio, or using an open source VoIP device that > connects by WLAN to a MiFi, which is considered part of the > untrusted Internet. > > The open source WLAN VoIP handset is more difficult than it > appears. In practice you'll have to use e.g. Jitsi with an USB > headset on a portable computer. Not exactly painless, and it opens > you up to system compromises. > > If anyone is aware of suitable dedicated hardware, I'd be thankful > for pointers. The Samsung Galaxy Player (Samsung Galaxy S WiFi in some countries) is essentially an Android phone without a baseband. I believe you can run CyanogenMod on it. Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSMuFgAAoJEBEET9GfxSfMN6MH/i9od0mmSAZAC5kxudPAfvbO fqKJ4l9dlxnn/hlBvq0K+B3FPaLuqOQlnY8bxaGi1uMhCVBqiUUBC601Nk+Bv06m MPO1sdpcYbW/cpPNxOqFthiiWpzm3ZR37ycB7gxtwx/AZDGfLGPefZHxX4Hb0Fif 7RIWS8LkYgHkc0JeFURYE/pkE1PZ088KaiTR7RRl4Ya0IZ37U3fmlvP5uahapM0N l7AQQsVog70+8JFNNh4E2PWA6mwLG3MtUfvnvNiP7PBiFYv9i9knOqzczvgU8KXf uZ5yxuLsBtmwOHQsp7KhXZ9SsJR4RkVwYMx9VYBW58lQIJ079a12RYbVAyQ0SGE= =CTO/ -----END PGP SIGNATURE----- ----- 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: [cryptography] very little is missing for working BTNS in Openswan
by Eugen Leitl 13 Sep '13

13 Sep '13

----- Forwarded message from Nico Williams <nico(a)cryptonector.com> ----- Date: Thu, 12 Sep 2013 14:04:08 -0500 From: Nico Williams <nico(a)cryptonector.com> To: Eugen Leitl <eugen(a)leitl.org> Cc: cryptography(a)randombit.net, Cryptography List <cryptography(a)metzdowd.com> Subject: Re: [cryptography] very little is missing for working BTNS in Openswan User-Agent: Mutt/1.5.21 (2010-09-15) On Mon, Sep 09, 2013 at 10:25:03AM +0200, Eugen Leitl wrote: > Just got word from an Openswan developer: > > " > To my knowledge, we never finished implementing the BTNS mode. > > It wouldn't be hard to do --- it's mostly just conditionally commenting out > code. > " > There's obviously a large potential deployment base for > BTNS for home users, just think of Openswan/OpenWRT. Note: you don't just want BTNS, you also want RFC5660 -- "IPsec channels". You also want to define a channel binding for such channels (this is trivial). To summarize: IPsec protects discrete *packets*, not discrete packet *flows*. This means that -depending on configuration- you might be using IPsec to talk to some peer at some address at one moment, and the next you might be talking to a different peer at the same address, and you'd never know the difference. IPsec channels consist of ensuring that the peer's ID never changes during the life of a given packet flow (e.g., TCP connection). BTNS pretty much requires IPsec configurations of that make you vulnerable in this way. I think it should be obvious now that "IPsec channels" is a necessary part of any BTNS implementation. Nico -- ----- 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: [Freedombox-discuss] Freedombox CA
by Eugen Leitl 13 Sep '13

13 Sep '13

----- Forwarded message from Jonathan Wilkes <jancsika(a)yahoo.com> ----- Date: Thu, 12 Sep 2013 12:19:59 -0400 From: Jonathan Wilkes <jancsika(a)yahoo.com> To: freedombox-discuss(a)lists.alioth.debian.org Subject: Re: [Freedombox-discuss] Freedombox CA User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 09/12/2013 10:06 AM, Keith wrote: > After further thought: > > With a CA on each freedombox we could have something like this > > Create a CA using (options used could be changed) > openssl genrsa -des3 -out "Freedombox CA.key" 4096 > openssl req -new -x509 -days 3650 -key "Freedombox CA.key" -out > "Freedombox CA.pem" > > Possibly replace any snakeoil keys created by Debian (Postfix uses 2048 > bits, could use 4096 bits if Postfix is the MTA used). > > Include in Plinth an option for a freedom box to obtain ssl keys with > the Freedombox CA. No interface to an external website, openssl can do > this. > > The public key of the Freedombox CA could be published, to be imported > into someone else's browser, could be a problem with multiple Freedombox > CA's with the same name. > > Possibly a paranoid option to rotate the ssl keys on the freedom box > running manually and/or as a cron job (Now doing this daily with one of > my mailservers). Hi Keith, In short, the entire white-hat security community guessed what "prohibitively expensive" meant. They guessed too low. Now we know, and everyone (including the white-hats and the surveillance industry) are scrambling to recover from the revelation. Some are thinking of it as the tinfoil hats coming off. I think of it as tinfoil hats appearing on every head of every person who has a device connected to the internet. I like it that way because "paranoid" becomes a synonym for "human", and all those previous "paranoid options" that are cordoned off with scant documentation suddenly become "bad human interfaces" which were prohibitively complicated to have actually provided security or privacy to the user when it turned out that they needed it. So to me, "paranoid option" now either means a) core feature which should be implemented cleanly, by default, or b) a dead coal mine canary that says the interface itself is too complicated, so start over and rethink it. Best, Jonathan _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- 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

[liberationtech] Inside the Effort to Crowdfund NSA-Proof Email and Chat Services | Motherboard
by Eugen Leitl 13 Sep '13

13 Sep '13

----- Forwarded message from Yosem Companys <companys(a)stanford.edu> ----- Date: Wed, 11 Sep 2013 15:29:15 -0700 From: Yosem Companys <companys(a)stanford.edu> To: Liberation Technologies <liberationtech(a)lists.stanford.edu> Subject: [liberationtech] Inside the Effort to Crowdfund NSA-Proof Email and Chat Services | Motherboard Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> http://motherboard.vice.com/blog/inside-the-effort-to-crowdfund-nsa-proof-e… Back in 1999, Seattle-based activists formed the communication collective Riseup.net. The site's email and chat services, among other tools, soon offered dissidents a means of encrypted communication essential to their work. Fourteen years later, Riseup is still going strong. In fact, they've been fighting the US state surveillance apparatus longer than most people have been aware of the NSA's shenanigans. Now, the collective is hoping to expand, given the gross privacy transgressions of the NSA and US government as a whole. "What surveillance really is, at its root, is a highly effective form of social control," reads an AugustRiseup newsletter. "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. The inability to whisper means there is no longer any speech that is truly free of coercion, real or implied. Most profoundly, pervasive surveillance threatens to eliminate the most vital element of both democracy and social movements: the mental space for people to form dissenting and unpopular views." The impetus behind the project is Riseup's struggle to keep up with new user demand for an email service that doesn't log IP addresses, sell data to third parties, or hand data over to the NSA. Riseup will also be able to expand its considerable anonymous emailing lists, which features nearly 6 million subscribers spread across 14,000 lists. Their Virtual Private Network (VPN), which allows users to securely connect to the internet as a whole, will also be made more robust. What Riseup can't do is offer its users an anonymous browsing experience, but that's not their aim. To offer Riseup to more users, Free Press's Joshua Levy, Elizabeth Stark (an open internet advocate who has taught at Stanford and Yale), as well as others at the StopWatching.Us campaign (backed by Mozilla) recently launched an Indiegogo crowd-funding effort on behalf of the group. They hope to raise $10,000 in order to provide Riseup—which is run by volunteers—with a new server, hardware, and software capabilities. In short, they want to expand their reach so that internet users have another alternative to email services such as Gmail, Yahoo, and Hotmail. To get a clearer picture of what StopWatching.Us and Riseup are doing, I spoke with Levy, Stark, and an anonymous Riseup collective member. We talked about how the crowdfunding money will be spent; how Riseup helps users avoid NSA, as well as state and local repression; and why, contrary to reports, the Tor Browser bundle is still the best option for anonymous, encrypted browsing. (As of today, the crowdfunding campaign reached it's $10,000 goal, but the organizers are hoping to exceed that total by a good margin.) [snip] -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- 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: [guardian-dev] Improving enabled TLS Cipher Suites
by Eugen Leitl 13 Sep '13

13 Sep '13

----- Forwarded message from coderman <coderman(a)gmail.com> ----- Date: Wed, 11 Sep 2013 15:13:09 -0700 From: coderman <coderman(a)gmail.com> To: David Chiles <david(a)chatsecure.org> Cc: Guardian Dev <guardian-dev(a)lists.mayfirst.org> Subject: Re: [guardian-dev] Improving enabled TLS Cipher Suites of all the suites, these look good (assuming 2k RSA keys) TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 all the rest do not provide forward secrecy, or use ECC with suspect constants, or use weak ciphers. i'm open to hearing arguments otherwise. > ... > TLS_RSA_WITH_AES_256_CBC_SHA256 > TLS_RSA_WITH_AES_128_CBC_SHA256 > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 > TLS_DH_anon_WITH_AES_128_CBC_SHA256 > TLS_DH_anon_WITH_AES_256_CBC_SHA256 > TLS_DH_anon_WITH_AES_128_CBC_SHA > TLS_DH_anon_WITH_AES_256_CBC_SHA > TLS_ECDH_anon_WITH_AES_128_CBC_SHA > TLS_DH_anon_WITH_3DES_EDE_CBC_SHA > TLS_ECDHE_ECDSA_WITH_NULL_SHA > TLS_ECDHE_RSA_WITH_NULL_SHA > TLS_RSA_WITH_NULL_MD5 > SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA > TLS_RSA_WITH_NULL_SHA256 > TLS_RSA_WITH_NULL_SHA > SSL_RSA_WITH_NULL_MD5 >> ... >> "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA", >> "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA", >> "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA", >> >> "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA", >> "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA", >> "TLS_ECDH_ECDSA_WITH_RC4_128_SHA", >> >> "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA", >> "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA", >> "TLS_ECDHE_RSA_WITH_RC4_128_SHA", >> >> "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA", >> "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA", >> "TLS_ECDH_RSA_WITH_RC4_128_SHA", >> >> "TLS_DHE_RSA_WITH_AES_256_CBC_SHA", >> "TLS_DHE_RSA_WITH_AES_128_CBC_SHA", >> >> "TLS_DHE_DSS_WITH_AES_128_CBC_SHA", >> "TLS_DHE_DSS_WITH_AES_256_CBC_SHA", >> >> "TLS_RSA_WITH_AES_256_CBC_SHA", >> "TLS_RSA_WITH_AES_128_CBC_SHA" >> ... _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/eugen%40leitl.org You are subscribed as: eugen(a)leitl.org ----- 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

Shadow Hardening
by Gutem 13 Sep '13

13 Sep '13

Someone already used this? http://www.openwall.com/tcb/ - Gutem

1 0

Backdooring Crypto
by John Young 12 Sep '13

12 Sep '13

In response to the Philip Hallam-Baker message below with his IETF draft, posted on Cryptome, these responses have been offered: 1. A 1997 paper: "Kleptography: Cryptography Against Cryptography," by Adam Young and Moti Yung. http://link.springer.com/chapter/10.1007%2F3-540-69053-0_6 "Kleptography: persuading the party to be intercepted to use a form of crypto that the attacker knows they can break." 2. "Phil's background as Verisign's principal designer is wellknown, and so are his design efforts in 'certificates, cert crypto and secure dns'. Lesser known are his friendships with the 'men-in-black'." ----- >Date: Wed, 11 Sep 2013 16:30:50 -0400 >From: Phillip Hallam-Baker <hallam(a)gmail.com> >To: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com> >Subject: [Cryptography] Summary of the discussion so far > >I have attempted to produce a summary of the discussion so far for >use as a requirements document for the PRISM-PROOF email scheme. >This is now available as an Internet draft. > ><http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt>http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt > >I have left out acknowledgements and references at the moment. That >is likely to take a whole day going back through the list and I >wanted to get this out. > >If anyone wants to claim responsibility for any part of the doc then >drop me a line and I will have the black helicopter sent round. > > >-- >Website: <http://hallambaker.com/>http://hallambaker.com/ >_______________________________________________ >The cryptography mailing list

2 1

[liberationtech] Henry Farrell for Democracy Journal: The Tech Intellectuals
by Eugen Leitl 12 Sep '13

12 Sep '13

----- Forwarded message from Yosem Companys <companys(a)stanford.edu> ----- Date: Wed, 11 Sep 2013 14:52:06 -0700 From: Yosem Companys <companys(a)stanford.edu> To: Liberation Technologies <liberationtech(a)lists.stanford.edu> Subject: [liberationtech] Henry Farrell for Democracy Journal: The Tech Intellectuals Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> http://www.democracyjournal.org/30/the-tech-intellectuals.php?page=all The Tech Intellectuals The good, bad, and ugly among our new breed of cyber-critics, and the economic imperatives that drive them. Henry Farrell A quarter of a century ago, Russell Jacoby lamented the demise of the public intellectual. The cause of death was an improvement in material conditions. Public intellectuals—Dwight Macdonald, I.F. Stone, and their like—once had little choice but to be independent. They had difficulty getting permanent well-paying jobs. However, as universities began to expand, they offered new opportunities to erstwhile unemployables. The academy demanded a high price. Intellectuals had to turn away from the public and toward the practiced obscurities of academic research and prose. In Jacoby’s description, these intellectuals “no longer need[ed] or want[ed] a larger public…. Campuses [were] their homes; colleagues their audience; monographs and specialized journals their media.” Over the last decade, conditions have changed again. New possibilities are opening up for public intellectuals. Internet-fueled media such as blogs have made it much easier for aspiring intellectuals to publish their opinions. They have fostered the creation of new intellectual outlets (Jacobin, The New Inquiry, The Los Angeles Review of Books), and helped revitalize some old ones too (The Baffler, Dissent). Finally, and not least, they have provided the meat for a new set of arguments about how communications technology is reshaping society. These debates have created opportunities for an emergent breed of professional argument-crafters: technology intellectuals. Like their predecessors of the 1950s and ’60s, they often make a living without having to work for a university. Indeed, the professoriate is being left behind. Traditional academic disciplines (except for law, which has a magpie-like fascination with new and shiny things) have had a hard time keeping up. New technologies, to traditionalists, are suspect: They are difficult to pin down within traditional academic boundaries, and they look a little too fashionable to senior academics, who are often nervous that their fields might somehow become publicly relevant. Many of these new public intellectuals are more or less self-made. Others are scholars (often with uncomfortable relationships with the academy, such as Clay Shirky, an unorthodox professor who is skeptical that the traditional university model can survive). Others still are entrepreneurs, like technology and media writer and podcaster Jeff Jarvis, working the angles between public argument and emerging business models. These various new-model public intellectuals jostle together in a very different world from the old. They aren’t trying to get review-essays published in Dissent or Commentary. Instead, they want to give TED talks that go viral. They argue with one another on a circuit of business conferences, academic meetings, ideas festivals, and public entertainment. They write books, some excellent, others incoherent. In some ways, the technology intellectuals are more genuinely public than their predecessors. The little magazines were just that, little. They were written for an elite and well-educated readership that could be measured in the tens of thousands. By contrast, TED talks are viewed 7.5 million times every month by a global audience of people who are mostly well-educated but are not self-conscious members of a cultural elite in the way that the modal reader of Partisan Review might have been. In other ways, they are less public. They are more ideologically constrained than either their predecessors or the general population. There are few radical left-wingers, and fewer conservatives. Very many of them sit somewhere on the spectrum between hard libertarianism and moderate liberalism. These new intellectuals disagree on issues such as privacy and security, but agree on more, including basic values of toleration and willingness to let people live their lives as they will. At their best, they offer an open and friendly pragmatism; at their worst, a vision of the future that glosses over real politics, and dissolves the spikiness, argumentativeness, and contrariness of actual human beings into a flavorless celebration of superficial diversity. This world of conversation and debate doesn’t float unsupported in the air. It has an underlying political economy, which is intuitively understood by many of its participants. As Jacoby emphasizes, all debates about ideas are shaped by their material conditions. The intellectual possibilities of the purported golden age of the 1950s were in part the product of bad pay, cheap rent, and a small but intensely engaged audience of readers. Those of the 1960s and ’70s were influenced by a burgeoning university system, which rewarded intellectuals for writing impenetrably for an audience of their peers. The possibilities today reflect a different set of material conditions again, which don’t determine individual choices so much as they pull on them, gently but insistently. They influence what is discussed and what isn’t, who wins and who loses. And much goes undiscussed. The working consensus among technology intellectuals depicts a world of possibilities that seems starkly at odds with the American reality of skyrocketing political and economic inequality. It glosses over the deep conflicts and divisions that exist in society and are plausibly growing worse. And the critics of this consensus fare no better. They work within the same system as their targets, in ways that compromise their rejoinders, and stunt the development of more useful lines of argument. [snip] -- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- 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-relays] Getting max bandwidth out of a relay
by Eugen Leitl 12 Sep '13

12 Sep '13

----- Forwarded message from Andy Isaacson <adi(a)hexapodia.org> ----- Date: Thu, 12 Sep 2013 02:06:13 -0700 From: Andy Isaacson <adi(a)hexapodia.org> To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Getting max bandwidth out of a relay User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: tor-relays(a)lists.torproject.org On Wed, Sep 11, 2013 at 05:13:04PM +0200, Jeroen Massar wrote: > Are boxes that are doing these speeds running at a CPU or a network cap? > Or maybe better asked, they do run at 100% usage of their cores or do > they just use two/three cores to the max? There are three main sinks of CPU usage in a well-configured large Tor relay: 1. doing AES and SHA. This scales with the network bandwidth used. 2. doing Montgomery multiplication for circuit creation requests. 3. bookkeeping. (4. kernel TCP overhead etc.) Until the August botnet hit, #1 was the primary user of CPU on most relays. A single Xeon core can do about 150 MB/sec of AES, or with AES-NI around 700 MB/sec. With the vastly increased circuit creation load currently in progress, #2 and #3 have become a larger problem. The bookkeeping, in particular, has grown significantly. On noisetor right now, 17% of all CPU cycles are being spent in a single bookkeeping routine, circuit_unlink_all_from_channel, according to "perf top". https://trac.torproject.org/projects/tor/ticket/9683 This increased circuit-create-and-destroy CPU load reduces the CPU available to do useful AES, so as a result, currently many Tor relays are showing increased CPU usage with decreased bandwidth usage. You'll have trouble getting a single Xeon core to run much more than 300 Mbps even with AES-NI, even without the botnet increasing CPU load without increasing throughput usage. In the current state, with so much extra bignum work and bookkeeping, a single daemon will have even more trouble pushing much bandwidth. Best practice for maximum bandwidth is to run one Tor daemon per physical core, each on a distinct IP address. Plan for each daemon to push about 15 MByte/sec. They can do more like 20 or 30, but planning for lower leaves some headroom. Your boxes, with 12 cores and 70 GB of RAM, are quite a bit overpowered for running 500 Mbps of Tor. If you ran a Tor daemon per core, you'd be able to push around 2 Gbps of Tor traffic, easily. -andy _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ----- 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: [Cryptography] Laws and cryptography
by Eugen Leitl 12 Sep '13

12 Sep '13

----- Forwarded message from John Gilmore <gnu(a)toad.com> ----- Date: Wed, 11 Sep 2013 13:20:13 -0700 From: John Gilmore <gnu(a)toad.com> To: Grégory Alvarez <gregory(a)alvarez-garcia.com> Cc: cryptography(a)metzdowd.com Subject: Re: [Cryptography] Laws and cryptography > ... the Wassenaar Arrangement clearly says that > material, software and technology need an authorization to be exported / > published. > > What is actually the status of the law about cryptography and publishing > new algorithms ? Is the cryptographer that publish a paper without > governmental authorization an outlaw There is a tension between fundamental freedoms and crypto controls. Often fundamental freedoms win (as they should). The Wassenaar Arrangement is a private agreement among a bunch of governments -- it is not a treaty -- and has no legal force at all. What matters are the statutes in your own country, and how they are interpreted. I don't know of any cryptographers who have been punished under crypto export controls, anywhere in the world, for publishing papers about encryption. So invent your own cryptosystem if you want, write about it, and publish! Human-written software was considered to be different from human-written papers for a while; in the US it took three court cases (Bernstein v. US being the first winner) to sort this out. In the 1990s, Europe did not control freely published ("mass-market and public-domain") software, and by 2000 that was true in the US also. Unless you want to find and pay a lawyer with relevant expertise, the best way to get a more-or-less definitive answer for your particular country is to look in Bert-Jaap Koops' "Crypto Law Survey". He has been maintaining it for decades, and actually did his PhD thesis on global regulations about encryption. See: http://cryptolaw.org/ > The department of the ministry of defense that handle this regulation > can't answer if publishing a cryptographic algorithm needs an > authorization. Can't answer, or won't? In the United States, both the NSA and the agencies responsible for the export controls (State Department and Commerce Department) have been known to lie to the public, unofficially, about what is actually allowed. Their tendency is to talk you into assuming that you have no rights, even if the law is clear that you do. Or they will tie you up in knots over how you might be able to comply with finicky regulations, without ever telling you that you are exempt from those regulations. We even caught them lying officially once or twice (e.g. refusing export of Kerberos authentication software on the bogus theory that someone, someday, might adapt it to do encryption). John _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/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