-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JRFC 31 - multikey #31
Comments
I have a feeling that PEM format for rsa etc, already has this? |
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).
|
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! |
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:
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).
The text was updated successfully, but these errors were encountered: