JRFC 31 - multikey

[jbenet]

Following in line with multihash, multiaddr, multicodec, and so on, enter multikey.

In a conversation about ipfs with @whyrusleeping and diffie, future-proofing the system came up. We noted the hashes used multihash. Then we discussed we need to do the same to keys -- in particular for avoiding catastrophe from an unexpected factoring breakthrough.[1]

Tentatively:

<varint algorithm><byte length><key bytes>

This works for both pub/private keys, as well as symmetric keys. (The algorithm code can signal whether the key is public or private, say 0xc0 for rsa private key, and 0xc1 for corresponding public key)

[1] Another note is to carefully isolate the reliance on PKI, and design systems with transitions to stronger systems (e.g. post-quantum pki systems, like this).

[dominictarr]

I have a feeling that PEM format for rsa etc, already has this?

[jbenet]

this Q&A has a good rundown of the various formats out there: http://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-it-differ-from-other-openssl-generated-key-file

ideally i'd like to make something that will work across formats. I'm not sure if it's feasible, but worth trying. Maybe even a converter, with an internal rep (like sort of like pandoc).

cat key.der | multikey convert der pem >key.pem

[ChristopherA]

Related to this is hierarchical keys. I've even been looking at lattice-based ones which are initially thought to be quantum-resistant. So if you really want to future proof ;-)

[jbenet]

Related to this is hierarchical keys. I've even been looking at lattice-based ones which are initially thought to be quantum-resistant. So if you really want to future proof ;-)

Yeah, that would be very nice!