
Here come the encryption apps - llambda
http://blog.cryptographyengineering.com/2013/03/here-come-encryption-apps.html
======
moxie
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 has been almost exclusively about
improving call quality and user experience.

I think this increased emphasis on the user might be what distinguishes the
"new wave" of crypto apps from the last. There seems to be a real consensus
between those working in the space that this is what's important now.

The things that I'm most proud of about RedPhone are typically unrelated to
the crypto, and are instead things like using push notifications for signaling
instead of persistent connections, using a lightweight mobile-oriented
signaling protocol instead of SIP, and building a low-latency calling network:
<http://www.whispersystems.org/blog/low-latency-switching/>

I think we're all starting to realize that our "competition" is the "insecure"
versions of what we're building, and security isn't an effective point of
comparison. We have to build better products, which just happen to
incidentally be really secure.

~~~
loeg
moxie, I'm curious how the "short authentication string" prevents MITM attacks
— can you shed some light on this or point me to existing documentation?
Thanks!

~~~
ams6110
It's some sort of key fingerprint. You know the key you sent to the other
party, and the other party can compute the fingerprint of the key they
received from "you." If they don't match, someone changed keys in transit.

~~~
loeg
Does this assume that the voice channel can't be doctored? But couldn't a MITM
attacker do just that — compute the "correct" fingerprint and speak it to the
recipient?

~~~
MichaelGG
Yes, it assumes an attacker cannot imitate the other person's voice without
detection. If you introduce enough latency or have a system fast enough to do
on-the-fly voice changing you'd be set. It's such a great, simple idea, I felt
stupid for not having thought of it.

To be sure, the voice channel establishes before the verbal authentication. I
see your fingerprint is "banana", you see "kitchen". We can chat and I can say
"alright so banana, right?" and you say "yep, in the kitchen". An attacker
would need to remove banana and kitchen from that voice conversation and put
their own fingerprint words in.

I think that level of realtime audio modification is pretty out of reach for
now, although I suppose if you introduced a lot of latency, you might be able
to pull it off. It'd probably be noticeable, and you can keep chatting and
confirming the phrase, so an attacker would have to be really on-the-ball.

Plus, this only happens the first time. After that, the client saves the keys,
so you know you're good.

~~~
loeg
Okay, cool. It sounds like this sort of attack is very difficult for now — but
I would rather be aware of it than not.

It sounds like RedPhone doesn't actually save the keys yet — it's a work-in-
progress. But that makes lots of sense.

------
tptacek
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 other projects. Assigning your class a code review
of Moxie's code is somewhat sadistic, and, more importantly, doesn't really
give us much of a benchmark.

~~~
rorrr
> _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.

~~~
tptacek
But that's not what he wrote. Read that part of the review again.

~~~
loeg
""" Overall code quality: Who knows

Should I use this to fight my oppressive regime? Yes -- if your fight consists
of sending dirty self-portraits to your fellow comrades-at-arms. Otherwise,
probably not. """

Am I missing something?

~~~
tptacek
His answer to "should I use this to fight my impressive regime" was the same
for all the tools, just with different wording.

~~~
matthewdgreen
My answer to that question was the same everywhere, because I think you'd be
crazy to use these tools to fight an oppressive regime. Just different levels
of crazy.

~~~
tptacek
Right! We agree strongly on that point. :)

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

~~~
dmix
I've tried using Gibberbot with some friends. It is pretty unreliable
sometimes. I think it may be an issue with OTR in general.

I feel like IM encryption still isn't a problem that has been fully solved yet
on android.

(Haven't checked out ChatSecure, looks good.)

~~~
tshtf
What problems have you had with Gibberbot? It's been rock solid for me with a
decent XMPP server, and even works reasonably well when proxied through Tor
(Orbot). I've had no issues with OTR either.

~~~
dmix
Both sides occasionally got scrambled messages. Sometimes messages wouldn't
show up at all and had to be resent.

I googled the issues a few times and there seems to be a lot of similar
complaints from other users of all OTR apps (like PigdinOTR).

I may have been some mistakenly from another gtalk app running or older
android phones.

One big UX issue is making sure both people are using it always.

~~~
tshtf
Ah, there's big issues with OTR with users who are logged in more than one
location. OTRv2 didn't work well with that, but I think OTRv3 may have
fixes...

------
jamwt
Self-promotion admitted, but the Bump app is interesting for IM/picture/file
etc capabilities (though not voice) in this arena. A few points:

    
    
      * Everything is tunneled over OpenSSL and (increasingly) NaCL.  
      * We do not use the CA infrastructure... we ship our server's public key
        in the app
      * Communication channels are established by a face-to-face "bump", and 
        the parties must mutually consent that the suggested "match" was their 
        intended counter party (they must validate name and mug).
      * Subsequent communications can happen asynchronously at a distance 
        on this channel
    

Basically, one of the things we've explored in house and with partners is that
we've "accidentally" created something with properties (though not yet
rigorously vetted to endorse for specific use cases) that lead to everyday
users having exercised some practices normally reserved for the technical and
paranoid--such as identity based on an initial in-person exchange.

------
frisco
What is the realistic risk of a hardware backdoor in mainstream smartphones? I
assume that there's nothing apps like these could do against those. Is that a
risk even worth worrying about at this point? If it is, is there anything that
can be done about it? It is safe to trust, say, Google or HTC and their
manufacturing chain?

Further, if the handset is attacked and silently owned, all bets are off, too,
right?

------
daxelrod
A minor point of curiosity: one of the captions says "Using SilentCircle on a
Huawei complete negates the point of using SilentCircle."

I appreciate that it may be somewhat tongue in cheek, but is that a riff on
the US accusing Huawei of being a national security threat[0], or do Huawei
phones have a track record of known security vulnerabilities?

[0][http://www.nytimes.com/2012/10/09/us/us-panel-calls-
huawei-a...](http://www.nytimes.com/2012/10/09/us/us-panel-calls-huawei-and-
zte-national-security-threat.html?pagewanted=all&_r=0)

~~~
rdtsc
At some point it is hard to say a system is secure if you cannot control the
hardware. That is when secure systems are certified it is not just a software
library, it has to be full hardware + software solution. If anything can
insert itself in between boot and loading the OS then it could read the memory
and just scan the memory for a key (by say emulating the memory inside a VM).
A phone manufacturer could very simply add a hardware memory read access via a
separate chip to their phone memory. The phone then could boot to an
arbitrarily 'secure' OS and application but it would still be a all for naught
as key could still be read from the memory.

Now there are these things :
<http://en.wikipedia.org/wiki/Trusted_Platform_Module> that should help with
the issue but I am not sure if there are any phones that ship with them.

~~~
AnthonyMouse
How would a TPM do anything against malicious hardware? The hardware
manufacturer could just as easily include a malicious TPM.

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

~~~
randomchars
Root is not enough either. Most drivers are closed source (on phones) so you
have no idea what the device is actually doing.

------
SODaniel
For those interested in building Encrypted/Private cloud apps Crypton.io
(<https://crypton.io>), developed by the team behind SpiderOak inc launched
proof of concept for a zero-knowledge private and secure cloud api a few weeks
ago. Also 100% open source for those who are interested.

------
e3pi
A `crypto app' I would like to have and see everyone use is to do the `......
_beep_ .....' every 10 seconds.

Until a transparently layered Redphone, etc., secure and universally used
protocol, this app assumes this and every connection is being recorded.

 _beep_ ...... _beep_ ...... _beep_ ......

------
tomkinstinch
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/>

~~~
claudius
[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>

------
B-Con
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?)

------
btipling
> While Cryptocat is written in Javascript (aaggh!)

Is there something inherently insecure about using JavaScript or is this not
meant to actually be relevant?

~~~
jacques_chester
If it's served from a webpage, then it's insecure.

Either the publishing server can replace it with a malicious version, or
another server might inject javascript that modifies or replaces it with a
malicious version.

This particular point hilariously broke a crypto protocol project of mine, so
I guess I'm touchy about it.

Shipping as a browser module is more secure.

~~~
btipling
That's not really a problem with the language.

~~~
jacques_chester
Given that javascript is the language that can be embedded in any webpage ...
yes it is.

------
dhughes
These apps remind of the guy who bought the first fax machine, nice but you
need a friend with one too for it to be of any use.

~~~
marshray
Installing an app is a lot less of an adoption hurdle than purchasing a new
piece of expensive equipment and provisioning a new dedicated landline was
back in the 1960's. Back then there were even some legal hurdles to connecting
non telco owned equipment to the phone system.

C.f., today's social networks.

<http://en.wikipedia.org/wiki/Fax#Telephone_transmission>

