Live data from Hacker News

Here come the encryption apps

blog.cryptographyengineering.com

31–40 of 58 posts

Re: Here come the encryption apps

#31
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...

Re: Here come the encryption apps

#32
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…

Thanks for pointing to your low-latency-switching strategies, was an interesting read! Although I see how it is great for a high availability strategy as a side-effect, I wonder why you did not want to make use of location information on the phone. I mean having the user send his coordinates with his first request would be the obvious choice, but privacy considerations could speak against it. But if your returned list of available servers for a region would include coordinates, the app would not have to establish connections to all the servers, but maybe just the closest X. That could improve the whole process and save a tiny bit of traffic if you had a lot of servers in every region. And what about having a list of all your available servers cached with their coordinates in an encrypted sqlite database then? Firewalls that filter the single domain that is queried for server information would not be as successful. On the other hand, old or compromised servers would have to get revoked regularily. Or Have you had more problems with the idea of phone locations and local server lists?

Re: Here come the encryption apps

#33
post #27
post #19

Earlier quoted context omitted.

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

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

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

Re: Here come the encryption apps

#34

> While Cryptocat is written in Javascript (aaggh!) Is there something inherently insecure about using JavaScript or is this not meant to actually be relevant?

The problem with javascript encryption is the environment in which it runs being impossible to control... and also some features of the language. There's no strong random number generator, for instance.

http://www.matasano.com/articles/javascript-cryptography/

Re: Here come the encryption apps

#35
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…

Having tried to build a secure messaging platform, I can't agree more that, for the average user, security is so far below the bottom of the list of important things as to not exist. Unfortunately, for those of us who do care, the removes the network effects that make secure software usable.

It doesn't make how many calls or emails I encrypt if nobody I talk to can receive them. It is encouraging to hear people 1) understanding security isn't really a differentiator and 2) trying to solve the real problems securely.

Re: Here come the encryption apps

#36
post #33
post #27

Earlier quoted context omitted.

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

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

True. Is he suggesting that the closed-source implementation-unknown app is better that the others, somewhere? Or is the problem that he is failing to condemn it as any worse than the others?

Re: Here come the encryption apps

#37
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.

Re: Here come the encryption apps

#38
post #28
post #26

Earlier quoted context omitted.

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.

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?

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.

Re: Here come the encryption apps

#39
post #24
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…

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!

I am not moxie, but I'll reply. The key thing is that a short authentication string is shown to both parties. Then it is the job of the parties to also verify by talking to each other that they are talking to the right person (authentication part). That is the key part -- using some other channel (not just he algorithms and the protocol to authenticate the counter-party).

Then the boring part kicks in and the way the algorithms works is that if you are convinced that you are talking to the right person, then the way the secret key is generated won't be infer-able to an eavesdropping party.

Now, if I remember correctly NSA has published a paper where they allegedly fooled this system by using voice disguise and a voice actor to basically play a man in the middle attack. Now this is highly subjective and based on the context, so take that with a grain of salt.

Re: Here come the encryption apps

#40

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

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.

Post reply on HN