[guardian-dev] Parandroid Messaging: New testbuild for all platforms

Moxie Marlinspike moxie at thoughtcrime.org
Fri Jul 9 11:07:27 EDT 2010


Hey Jeffrey, I took a look at your code, and I have some concerns.  You
may not be conceptualizing it this way, but what you guys are doing here
is attempting to design a secure protocol.  A lot has been written about
this, but it's actually not entirely simple, and there are a lot of
gotchas along the way.

I don't believe that the protocol you guys have designed (really just
AES in ECB mode) is secure.  I am personally a fan of what Phillip
Rogaway, in particular, has done in terms of defining models for
provably secure protocols.  This is a situation where you'd like a
protocol that is at minimum IND-CCA secure, and any secure protocol
should be at least IND-CPA.  What you have is neither.

I'm impressed with the job you guys have done in managing the existing
"Mms" package, but not the cryptography that you have added on to it.
The fact that you were originally using DES with PBKDF2 suggests to me
that you might have just been googling for how to encrypt stuff, since
the bulk of Java cryptography "examples" (most of which are actually bad
advise posted to random forums) were written in the DES era.

I'd suggest stopping and taking some time to read about designing secure
protocols (I'd recommend the Bellare and Rogaway notes).  Alternatively,
you could implement something that other folks have spent time thinking
about (the cryptophone protocol or what we're doing with TextSecure, for
instance).  In the end, you should be able to use defined models to
write a proof of your protocol's security. In the mean time, it might be
prudent to notify your users that what they have is not secure.

- moxie

-- 
http://www.thoughtcrime.org

On 06/18/2010 04:55 PM, Jacob Appelbaum wrote:
> On 05/16/2010 02:39 PM, Jeffrey Klardie wrote:
>> Hey all,
>>
>> first of all, Jacob, thanks for your reply. It was very useful, and made us
>> think about some aspects of our application.
> 
> You're welcome. Sorry for taking a month to get back to you this time...
> 
>>
>> About cryptophone: since it is not open source, we are not really able to
>> get a good idea of how they implemented things. The only thing we can find
>> out about it is this small text on their site: "Keys [are] exchanged with
>> 4096 Bit Diffie-Hellmann, voice and data encrypted with AES 256 and
>> Twofish". If you could provide us with more info, that would help a lot.
>>
> 
> The source code for much of the project is available on their website.
> This is not free software but it should allow you to get a good feel for
> the voice crypto stuff. I suspect that they will release more in the future.
> 
>> We updated our project site, by adding a new page about the
>> implementation<http://wiki.github.com/erikwt/ParandroidMessaging/implementation>(
>> http://wiki.github.com/erikwt/ParandroidMessaging/implementation). It is not
>> perfect yet, but it will give a better idea of how we do the crypto part.
>>
> 
> Ok.
> 
>> Currently we do not have forward secrecy. Technically it's pretty easy to
>> implement this. The problem here is that it brings a lot of overhead, which
>> will cost the end user extra money. We are thinking about a solution for
>> this (like a new keypair for each person you have contact with, for each
>> conversation, etc).
> 
> I think this is an absolutely requirement. Why not take the OTR route
> and have long term identity keys and session keys per "session" that is
> running in a given time frame?
> 
> I suspect that TextSecure is probably doing all of this right - I hear
> that they're planning to release a lot about their implementation soon,
> from source code to specs - they're probably not going to be free
> software though.
> 
>>
>> We did use DES, although not for the encryption of the message that goes
>> over the air: we used it to encrypt the private key on the filesystem. Since
>> DES is no longer safe (as Jacob correctly points out), we immediately
>> changed that to AES.
> 
> Can you tell me what that means? AES in what mode? Do you use PBDFK2?
> What slows down a brute force attack on the private key?
> 
>>
>> We will have a look at OTR and discuss that in our team. We'll let you know
>> if we can use it in some way. Also, we'll try to update our wiki pages. Some
>> are a bit outdated and not very well formed.
> 
> Sounds great!
> 
> All the best,
> Jacob
> 


More information about the Guardian-dev mailing list