For German, Swiss Privacy Start-Ups, a Post-Snowden Boom
blogs.wsj.com
blogs.wsj.com
Now granted, our authorities are way less heavy handed in their approach than the various US agencies, but still, if you don't trust the Swiss government (btw: lately not willing to stand up to US demands), you should not, by any means trust any Swiss company to handle data for you.
If you read german, here's the law: http://www.ejpd.admin.ch/content/dam/data/sicherheit/gesetzg...
NSA Backdoors in Crypto AG Ciphering Machines https://www.schneier.com/blog/archives/2008/01/nsa_backdoors...
Lavabit was forced to close down in August 2013, after being forced to disclose classified documents.
No it was not. They where forced to hand over the private server keys, which is much more significant than "disclosing some classified documents" and so Mr. Levison decided to shut it down.
It may be just a pet peevee of mine, but can't journalists do some minimal research before writing about a subject?
You're correct; the original is rather accurate.
Chalk it up to sloppy translation :)
There is no transition in the investigative state machine for "data relevant to our investigation to which we are lawfully entitled exists and is available to us, BUT we will not retrieve it because doing so would be invasive to other members of the service". It's possible --- we could do some research --- that that transition exists in the state machines of no western government at all. Knowing that: if it's feasible to obtain information from a secure message service, eventually, the courts will mandate its retrieval.
As of 2014, there is a fundamental tradeoff that we know for a fact exists: you can design an encrypted mail service that is trivial for users to adopt, or you can design an encrypted mail service that meaningfully resists judicial power. You can't do both.
https://www.kickstarter.com/projects/620001568/jackpair-safe...
It's an end-to-end voice encryption device using Diffie-Hellman protocol for completely-distributed key exchange, so the keys never leave the box and there's no way we can hand over any key, or traffic, to the authorities.
The user interface of JackPair is minimal; it's connected with any phone and headset through standard 3.5 mm audio jack. All you need to do is to press the button on it to set up secure line over established phone calls. It's zero configuration with no software to install, no service subscription, and it works with any phone you already have.
I see you plan to publish the source -- do you have a way that someone can verify what is running on their device, such as using common components so they can load the code themselves, or maybe a version that runs as installed software on a desktop computer? (This wouldn't be as convenient, but it could provide safety to the ecosystem if it could detect hostile clients.)
EDIT I wonder how much computational power it would take for an attacker to do a man-in-the-middle attack that recognizes each side saying "the code is 123" and change the voice to say "the code is 456."
It's a good idea to find ways for users to verify what's running on the device. Right now, the USB port on JackPair is only for user to re-charge battery. We can open it up for user to load the code themselves, but this will also make it vulnerable for USB hacks. Any suggestions here?
The encryption software of JackPair can be run on PC, except for the assembly optimization for our ARM cortex M3 based DSP core. It's ok to verify software this way; it'll be open sourced anyway. But I'm not convinced that average users can make sure their PC or smart phone secure enough to run JackPair as pure software solution.
For MitM human voice mimicking, in additional to computing power, it'll take a large database with perfect voice samples, and manual adjustment & training so far:
http://dsp.stackexchange.com/questions/7833/how-to-mimic-cop...
BTW, the Pairing Code in JackPair is 10 digits long, the 3-digit code you see in the GIF animation is for illustration purpose.
Nerds are great at baring their fangs when someone overtly suggests escrow keys. But they're terrible at spotting designs where key escrow is an emergent property rather than a goal.
It is even worse, as the same law extends to internet providers as well. Some people argue that this effectively is a government controlled man-in-the-middle infrastructure.
They don't need to implement their own, they can just subscribe to the Monitoring as a Service program the NSA offers...
The primary problem is an architecture where keys are held on third party servers and cryptographic code is secured only with an https connection.
We need to design our services to be robust and transparent in hostile jurisdictions rather than resting on the relatively weak privacy assurances of nation states.
I've been trying to navigate away from a reliance on US-based services, but at the same time I'd much prefer to move over to a service that didn't have any data to hand over rather than trust Switzerland, Germany or any other country not to just suck that data up themselves.