RFC : Integrate automated RSA key distribution that reinforces all our elliptic curve based crypto

[burdges]

At present, pond.imperialviolet.org still warns :

Dear God, please don't use Pond for anything real yet. I've hammered out nearly 20K lines of code that have never been reviewed. Unless you're looking to experiment you should go use something that actually works.

Is it worth implementing a kind of "fallback" to RSA?

Thought : In the state file, we could store an 8192 bit RSA public key pair, and the RSA public keys for every contact. RSA key exchange would occur by attaching public key requests and/or the public keys themselves to messages. Pond messages would then carry an RSA signature of the ratchet values and users would be notified if a signature failed for a contact to whom they knew the RSA key. A user's RSA public key pair would be generated automatically, presumably by using libgcrypt, but conceivably they could import their existing GnuPG key or export the pond generated one for use with GnuPG or SSH.

Advantages : Safer against hick ups in elliptic curve cryptography. Improves security in the absence of good code review. Always nice to have a securely distributed GnuPG key lying around.

Disadvantages : Confuses users. Adds libgcrypt dependency. Adds complexity, making full review and other implementations harder. Cannot create an air gapped GnuPG key which might encourage insecurity through laziness.

What do people feel about this or similar? I have not succeeded in convincing myself that this would be worth doing, but I wanted to ask publicly for comments.

[bnagy]

From a security point of view I think this is unrelated to the reasons people would be uncomfortable with Pond. In my mind it's nothing to do with the primitives used for signing, it's just the fact that it's new code, has a couple of new protocol approaches and an (optional) new key exchange paradigm.

I honestly don't think you've thought this through. It would be a huge amount of work, effectively double the complexity of the core protocols, moots what I would argue are insane-person key sizes, and still doesn't address the bootstrapping issue of adding a contact. (Tying identities at the pondserver to GPG keys means a server compromise would be a security consideration.) Communicating with Pond has very different linkability characteristics when compared with communicating via GPG, which is a design goal. IMHO nothing good can come of blurring that line.

It definitely wouldn't require a libgcrypt dependency, though. Everything you talked about is trivial with native Go.

[burdges]

I'm still mulling this all over myself, thanks for weighing in and pointing out that crypto/rsa and crypto/x509 make libgcrypt irrelevant. :)

It would be a huge amount of work, effectively double the complexity of the core protocols,

Not really. The protocol would remain mostly the same. And must remain completely backwards compatible.

There are three options for the protocol modification :

• An optional RSA signature on the ratchet values in a message.
• An optional second set of ratchet values encrypted with RSA and corresponding second ratchet in the contact.
• Roughly both of the above.

In all cases, the RSA protections on a message must be entirely optional for backwards compatibility, but if they ever appear and then later disappear, then a warning would be displayed on the messages and the disappearance would be logged as a contact event.

Tying identities at the pondserver to GPG keys means a server compromise would be a security consideration.
Communicating with Pond has very different linkability characteristics when compared with communicating via GPG, which is a design goal.

The new RSA data would be transmitted inside pond messages, making it encrypted using pond's ratchet key and invisible to the server. No changes to the server code are proposed here.

[bnagy]

Sorry, but now this seems to make even less sense. If people want to RSA sign inside a pond message they're completely free to do so ( just use a PEM signature block ). I can't see any upsides to connecting RSA keys OR "public" identities to the protocol itself.

[burdges]

Yes, a user could protect individual pond message's text and attachments with GPG, the point is to protect the ratchet.

One candidate workflow :

1. Alice and Bob key up.
2. Alice messages Bob, her pond attached Alice's RSA public key.
3. Alice messages Bob again, her pond includes an RSA signature of a ratchet value.
4. Bob's pond verifies that Alice's message in (3) was signed by the the public key she sent him in (2).

There is a lot more that Alice and Bob could do with this RSA key that they maybe should not do with their pond identity keys.

• Alice is safer revealing the fingerprint of her pond's RSA key, rather than her pond identity key, since the pond server does not know it. See Create fingerprint() method and display its results #147
• Bob could start worrying about some aspects of ECC without worrying about Alice's pond messages.

I'm happy to close this up now because (a) it does need more thought as you say and (b) I've learned what I wanted from it for now. I'm happy to hear if anyone else has comments of course.