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 <[email protected]> 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 <[email protected]> >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 >>[email protected] >>https://moderncrypto.org/mailman/listinfo/messaging
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
