Hi, Kara. Thanks for taking the time to explain your product and goals. (And for not repeating the mistakes of a certain previous project.)
On 6/28/12 8:30 PM, Kara Coppa wrote: > I'm a Wickr co-founder and I heard there was some discussion today > about our technology. As you've probably heard Dan Kaminsky is part > of our advisory board and we've worked out some additional details > about our technology that we'd like to share with you. I hope you'll > appreciate what we've been working so hard on. > > Below is what we've come up with attached with greetings from Dan. > > Hi everyone, this is Dan Kaminsky. I've been advising Wickr for some > time, and I'm relatively pleased with the nature of the product we're > offering here. > > Essentially, it's an attempt to create an environment where the best > practices of secure messaging are "always on" and "just work". There > are quite a few communities that we all agree could use an easier way > to communicate safely, and we're honored to provide this new service. While that's an admirable goal, OTR serves much the same purpose and is an open, audited system. Why have you decided to create a proprietary solution? > A couple of comments about how it all works: > > Obviously, there's no home grown crypto. It's 2012, everyone knows > how that story ends. Messages are encrypted via multiple rounds of > AES-256, Multiple rounds? 256 bits of security should be sufficient. Are you afraid of an AES break? The block cipher you use provides a nice headline piece, but it's largely irrelevant. As you noted, the story is over: nobody breaks block ciphers anymore. Can you provide more details about your cryptosystem and threat model? What about your messaging packaging and signing? What about message authentication? (Do I have any independent way of verifying that a message is from the same device that sent me a previous message, or do I have to trust your server to tell me it's so?) > with the symmetric keys transported via 4096 bit RSA. To be fair, ECC is just as secure, vastly more space-efficient, and much harder to subtly and dangerously misuse. > Private keys actually never leave the decrypting device; in fact, > Wickr goes out of its way to bind messages to a particular device as > thoroughly as feasible. It actually uses some properties of devices > that are unique from phone to phone as part of the key material > necessary to decrypt messages to a particular phone. There are many ways to implement the scheme you describe above, some secure, some not. Can you provide more details on your key generation algorithm? > We sacrifice > some usability to achieve device dependence but feel the paranoia is > justified. In what way? > There is indeed a central server in the Wickr design; it's there to > introduce peers to one another and to provide some protection against > traffic analysis while proxying messages between peers. Do you send decoy traffic? Do you introduce jitter in message delivery? If not, simple timing analysis is good enough for traffic analysis, even when an adversary can't tap your traffic at your server. (Which any reasonable adversary definitely can.) What exactly is your threat model? > Critically, > the Wickr server never sees the plaintext and does not have a backup > of the private keys. Encrypted messages are delivered to the central > server via SSL and a Wickr-specific key, and then they are proxied to > clients for decryption and display. > The central server really does as much as it can to proxy content, but > otherwise gets out of the way. No logs are kept of message delivery, > all addresses are SHA-256 hashes of keys, and each device stores a > unique cryptographic hash for each Wickr peer. And the name of each Wickr peer is a cryptographic hash of a key derived from each device's unique identifier. Is there some notion of trans-device identity? If not, I'm worried about a simple social engineering attack: Say we have Alice and Bob, and they regularly chat about Flickr, Yelp, and other disemvoweled things over Wickr. Now, each device is a completely new and untrusted security principal in your system, so Alice and Bob don't exist --- only Alice(1), Bob(1), etc., where Name(N) denotes the Nth device owned by Name. Alice and Bob are both enthusiastic and savvy users of mobile devices, so they regularly go out and purchase new mobile devices. When Bob buys a new device, he tells about it --- except that he's now Bob(2), not Bob(1), and Alice can't tell the difference between Bob(2) and Mallory(1) saying he's Bob. I suppose you have some sort of central system of accounts --- Alice, Bob, etc. --- and that users can register new devices with their account. A server could send a message to Alice saying Bob(2) represents the same user as Bob(1). But having done so, you've reduced the security of your system to the security of your server-side account management. That's not "military-grade". It's roughly Facebook-grade. I can imagine a system that forces users to use an existing device to vouch for a new one. How does a user who's dropped his phone in a toilet establish the authenticity of a replacement device under such a system? (I'm also assuming that you will always act in good faith, and that you couldn't possibly be coerced by an increasingly authoritarian government obsessed with cracking down on whistleblowers and dissidents.) > Regarding forward secrecy, as a store and forward platform there are > some challenges. Wickr's model is to use the server side key to > rotate the client side key on a regular basis, at periods longer than > the maximum supported expiration time. This is vaguely similar to the > key rotation strategy used by OpenSSH. It's not PFS but it's quite > reasonable. Can you explain how your client and server side keys interact? A more formal description of your cryptosystem would be helpful. What exactly is the technical barrier to using PFS here? Even a store-and-forward system should be able to manage the round trips necessary to establish a secure channel. > Anyway, Wickr is under active development, so please, kick the tires! > Let us know what you think! Thanks again for doing work in this area. Port it to the operating system I'm helping develop, Windows Phone 8, and I'll give it a shot.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ liberationtech mailing list liberationtech@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech
