Hacker News Reader

Comment by jeffrey8chang | Hacker News Reader

Yes, you can design an encryption tool that's both trivial to adopt, and resist judicial power at the same time. And this is exactly what I'm doing now:

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.

View on HN

Levison d e l i b e r a t e l y chose a model that amounted to key escrow because the alternatives all involved users installing software, and thus killing user adoption. He deliberately escrowed keys to his users, providing the illusion of security in exchange for market penetration.

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.

FYI, based on previous discussion, by "trivial to adopt" he means "you can use it in your current browser and in a new browser if you remember your password." Which is reasonable, but I totally see why you think your own solution fits your own definition of "trivial to adopt." Domains are a bit different.

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."

Got your point on "trivial to adopt". I didn't see discussions w.r.t. browser here.

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.

Reply on news.ycombinator.com