-
Notifications
You must be signed in to change notification settings - Fork 1
A: I'm attempting to make Matt Green say "Oh no, not another one!"
A: For self-edification, and more so, for fun! This is rather unlikely to become the the Next Great Encrypted Messaging Application, but in other ways it can be seen as a smaller, self-contained study for approaches we would like to use in the Cryptosphere, which is a much more ambitious effort. Trying these things out in a simpler, more purpose-built program lets us work out the kinks before working on a more complicated solution.
A: Oh god no.
A: See previous question/answer.
Q: Why is this better than Moxie's TextSecure or Adam Langley's Pond?
A: It's not. It's crappier. Use TextSecure or Pond!
Q: Are you using the Axolotol Ratchet used by systems like TextSecure and Pond?
No, we are purposefully using a simpler, more limited ahead-of-time key exchange system which still provides forward secrecy, solely for the purpose of simplifying the implementation. This is because we're not concerned with inventing the next great asynchronous message ratcheting protocol (Moxie and Trevor Perrin are doing a great job of that). This project is aimed at researching techniques for providing a better crypto experience to your average user.
We're trying to push the user experience bar forward without compromising on security. If the software actually gains traction, then perhaps then we can look into implementing Moxie/Trevor's ratchet. However, this software is not necessarily being developed with the intent of gaining widespread adoption, so we'd rather skimp on frills for now.
Q: Are you using a bunch of crazy, uninformed homebrew crypto like Telegram?
A: Oh god no. We are using an off-the-shelf authenticated encryption scheme, namely NaCl's crypto_box, a.k.a. curve25519xsalsa20poly1305. This scheme uses elliptic curve Diffie-Hellman to derive a symmetric key which is used to encrypt messages. We use a unique pair of D-H keys per message to obtain forward secrecy.
Beyond that we aim to provide an easy-to-understand and easy-to-audit key exchange system to ensure participants in conversations receive appropriately authenticated D-H public keys.
Q: Why oh why is there a web browser involved in this? You're one of those confused Ruby/JavaScripty people who think that using browsers for a UI is actually a good idea, aren't you?!
A: Yes? Also I prefer to speak in the "Royal We" form. Also I'd like to rewrite the backend in Rust eventually!
Q: Have you read Matasano's JavaScript Cryptography Considered Harmful article?
A: Yes, and we think this may be among the first systems combining JavaScript and cryptography that won't make Tom Ptacek vomit with rage. Why? NO IN-BROWSER CRYPTO.
A: Well that's kind of the point
A: We love P2P! The Cryptosphere is a P2P system. Confusion is a purposefully simple system built as a research project. Maybe if we feel like it we'll integrate with things like BitMessage, but probably not.
That said, effectively providing security for a P2P system is a difficult challenge, fraught with problems like preventing Sybil attacks against things like distributed hash tables. We're treading lightly.
A: Right here
A: Tombstone requires ECDHE-RSA-AES256-GCM-SHA384. Accept no substitutes.
A: Tombstone's certificate is pinned to individual releases of Confusion. If it's compromised we'll spin a new release of Confusion with a new certificate pinned. No CA no cry.
A: It's a quadruple reference to:
- Claude Shannon's concept of confusion within cryptography as quoted in the README
- New Order's single Confusion, whose cover contains a hidden message
- Neal Stephenson's book The Confusion
- The general problem of confusion in building secure software systems
