[messaging] Wickr Protocol Description

[Matt Corallo]

I say their docs are good then realize I'm not sure the protocol docs of TextSecure were updated for the latest protocol version :/.

Anyway, the Wickr stuff seems much simpler in that it doesn't have the ratcheting stuff TextSecure spends a bunch of time getting right. Means you have to tell the server when you're communicating with someone to get a new key for them, but you were already gonna do that anyway. Really concerned about a few comments in that paper and really disappointed they didn't release a spec instead of a general overview as it leads to a bunch of confusion. Personally I'm not a big fan of anything that stores your key material encrypted with a user password on a server as users are infamously bad at picking cryptographic passwords, but I understand the appeal of doing things that way.

On November 26, 2015 6:33:00 PM EST, Matt Corallo <moderncrypto at bluematt.me> wrote:
>Except the TextSecure protocol is rather well-defined (I've personally
>nearly completely implemented a working protocol without reading the
>TextSecure code at all). This is rather unclear in a number of ways...
>
>It says, with regard to the device key, "the app provides a salt and
>padding information to prevent malicious and/or unregistered users from
>replicating the device key if the unique device identifiers were to be
>compromised". They don't seem to specify how the salt works. I assume
>they're using a random 32 bytes or so, which gives a rather misleading
>understanding of what the device key is. It's not really a
>device-specific key but a random key which uses device IDs to protect
>against a bad system RNG (why aren't they doing this for all keys, as
>it's generally good hygiene?). Otherwise, maybe they're using a small
>salt, but I don't see why they shouldn't be using a random key here.
>
>I'm interested to know what is in the message header... It seems to me,
>there is some way to prove the header was sent my the same individual
>who sent the message forward secrecy of broken. If there isn't, their
>claim that "Being able to successfully decrypt the header with the
>generated header key provides assurances to the recipient that the SMC
>was sent by the supposed sender" is bogus.
>
>Further, I'm very concerned by the ability of random users to "obtain
>the sender’s username and application ID from the Wickr server". Since
>the application ID is "generated by hashing the user’s password with
>device information", anyone who can find some part of your device
>information can probably easily (offline) brute force your password.
>Because they don't specify what is in your "device information", it's
>unclear how much data you'd have to find but, really, it'd be hard to
>have to brute force much more than a serial number if you know their
>phone model and have some knowledge of their mac address (which is
>generally trivial to find). What's worse, I've seen manufactures
>include the device serial number on receipts and if someone has access
>to your phone long enough to pop the back off and take a picture likely
>has everything they need.
>
>I only got two pages into keys and primitives, but there is no way I'm
>ever using Wickr. Don't ever trust crypto if you can't find a spec
>sufficiently detailed to be able to implement a compatible client from
>just public documentation (preferably with an open source client).
>
>On November 26, 2015 12:48:27 PM EST, Tony Arcieri <bascule at gmail.com>
>wrote:
>>Wickr has released this description of their encrypted messaging
>>protocol:
>>
>>https://www.wickr.com/wp-content/uploads/2015/11/Wickr_Whitepaper_Final.pdf
>>
>>At first glance it reminds me of this:
>>
>>https://whispersystems.org/blog/asynchronous-security/
>>
>>-- 
>>Tony Arcieri
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Messaging mailing list
>>Messaging at moderncrypto.org
>>https://moderncrypto.org/mailman/listinfo/messaging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151127/eb241551/attachment.html>