Live data from Hacker News

Here come the encryption apps

blog.cryptographyengineering.com

11–20 of 58 posts

Re: Here come the encryption apps

#12
As Mr. Green points out, the key issue today is more about key disruption. And, in my opinion, that's an area closed source solutions are even more scary. (Without any form of transparency, why would we believe our keys aren't being archived to China?)

Re: Here come the encryption apps

#13
I don't think you can have security on a device you don't have root access. And since most of the phones are locked and untrusted does it matter how much exactly?

And almost all really nasty regimes have already somewhat liberal view of using thermorectal cryptoanalysis anyway. Tor style obfuscation and retransmission with very low SNR masked as a torrent client could be a better way to go. If your government know that you said something to someone they can just "ask" you to find exactly what. The trick is not to be found.

Re: Here come the encryption apps

#14

Looks like they skipped over two open source XMPP+OTR clients for iPhone/Android: ChatSecure ( https://chatsecure.org ) and Gibberbot https://guardianproject.info/apps/gibber/ Disclosure: I am the original author of ChatSecure.

I guess the best point about these is that they are actually (or hopefully?) somewhat standardised - XMPP with OTR works perfectly fine on the desktop, albeit only for IM. Inventing a new protocol to provide essentially the same features appears a little unnecessary - at least the IM part could have reused OTR with voice calls using some other encryption (possibly based on the keys negotiated via OTR).

Re: Here come the encryption apps

#15
post #10
post #5

I work on two of the apps Matthew reviews here (RedPhone and TextSecure). What I didn't expect when I started working on these types of projects is that the cryptography is the easy part. I'm really honored to hear that my code has the ability to make Matthew Green drool, but that ZRTP stack was a two or three day project three years ago, and hasn't changed much since. The bulk of the work over the intervening period…

I don't understand why you'd concede security to your competition; it is a genuine distinction. Most security people I know, and all the crypto people I know would choose your designs over those of the other designers in this review, not because of the quality of your application but because you're clearly a capable designer. I worry about the message we send with this "the competition is insecure apps" stuff. Some o…

I think he maybe meant that the competition is the incumbent apps that don't have encryption as their selling point.

Re: Here come the encryption apps

#16

I just Googled for a Chrome extension to add message body encryption to gmail. I found SafeGmail [1]. Does anyone have experience using it/encouraging others to try it? Is it worth using? Is there a better alternative? http://safegmail.com/

[0] has some more information – it appears to be standard OpenPGP with a random encryption key stored on the server of safegmail and then retrieved by the receiver, using a common secret as identification. Given that you have to install a (closed-source?) extension and that the key management happens on the servers of safegmail, you naturally have to trust them not to do funny things with your data.

Years ago, there was a Firefox extension to do standard GnuPG in the browser, but I think it died down. If you want really secure email at the moment, I assume there to be no other way than to use a client with PGP support, such as, uh, basically every email client.

[0] http://safegmail.com/information.html

Re: Here come the encryption apps

#17
post #9

I don't understand how Matthew can write a comparative review of encrypted chat clients and include one for which he has no technical information, not even a binary; particularly when it mixes number theoretic and conventional block crypto, thus exposing itself to a maximal subset of possible implementation errors. I'd also be interested in the kinds of flaws his class was able to generate for in-class discussion, in…

> I don't understand how Matthew can write a comparative review of encrypted chat clients and include one for which he has no technical information, not even a binary

Well that's the point. If there's no source, don't trust that crypto app.

Re: Here come the encryption apps

#18
post #10

Earlier quoted context omitted.

I don't understand why you'd concede security to your competition; it is a genuine distinction. Most security people I know, and all the crypto people I know would choose your designs over those of the other designers in this review, not because of the quality of your application but because you're clearly a capable designer. I worry about the message we send with this "the competition is insecure apps" stuff. Some o…

I think he maybe meant that the competition is the incumbent apps that don't have encryption as their selling point.

Yes, I'm clear on that. But maybe it shouldn't be. At least those unencrypted apps send a clear signal to their users about the level of assurance they provide.

Re: Here come the encryption apps

#19
post #17
post #9

I don't understand how Matthew can write a comparative review of encrypted chat clients and include one for which he has no technical information, not even a binary; particularly when it mixes number theoretic and conventional block crypto, thus exposing itself to a maximal subset of possible implementation errors. I'd also be interested in the kinds of flaws his class was able to generate for in-class discussion, in…

> I don't understand how Matthew can write a comparative review of encrypted chat clients and include one for which he has no technical information, not even a binary Well that's the point. If there's no source, don't trust that crypto app.

But that's not what he wrote. Read that part of the review again.
Post reply on HN