search

ipfs / specs

Technical specifications for the IPFS protocol stack
https://specs.ipfs.tech
1.15k stars 232 forks source link

Keystore Review #3

Open jbenet opened 9 years ago

jbenet commented 9 years ago

(We probably should do review with PRs?)

To have a secure, simple and user-friendly way of storing and managing keypairs for use by ipfs. As well as the ability to share these keys, encrypt, decrypt, sign and verify data.

I think this is two separate things: key management, and performing cryptographic operations. Instead of all in ipfs key, let's split it into:

ipfs key [ gen | ls | info | rm | rename | send ]
ipfs crypt [ sign | verify | encrypt | decrypt ]

Key management:

ipfs key gen

LGTM

ipfs key send

otherwise LGTM.

Crypto ops:

ipfs crypt encrypt/decrypt

We need to model this after common systems. in fact, i'd love to be able to make these tools non-ipfs specific, and do cat foo | crypt <args> | ipfs add.

We will also need to make additions to support keys in other commands, these changes are as follows:

  • [ ] No, no changing other tools! compose them (or even alias them). instead of having ipfs add -r <file> support encryption, we wrap ipfs add to do ipfs encrypt <opts> | ipfs add <other opts>.

    Structures

these are only for the ipfs crypt part, not the ipfs key

Signed DAG:

links:
  - name: @type, hash: <hash to signed dag definition>
  - name: content, hash: <hash>
  - name: key, hash: <pkhash>
data:
  <sig>

(@type is json-LD style)

Encypted DAG:

jbenet commented 9 years ago

Also:

cryptix commented 9 years ago

ipfs key send seems icky. Receiver needs to be online, no? How do you protect against unwanted incoming keys? I'd prefer a pull-ish model, maybe ipfs key find?

Also where does trust come in? You could ipfs crypt sign $key by hand but the key management should ease with that and help with verification.

jbenet commented 9 years ago

yep, @cryptix you're right. we'll also need a way to:

whyrusleeping commented 9 years ago

Agreed on the split between ipfs key and ipfs crypt.

re: ipfs key send. My aim was to keep the interface simple and functional for our users. Adding further complexity lowers security by scaring users away from using it. I think we could keep the ipfs key send the same, but require the receiving end to run ipfs key receive within a set time period. ipfs key receive could show all incoming key requests and let the user select an action for each, "accept", "reject", "ignore".

@jbenet im confused about what you mean by "wrapping ipfs add" for encryption

vitzli commented 9 years ago

May I suggest ipfs key import and ipfs key export commands for plain-text files (like gpg --export --armor)? I wrote a bit about key management in #ipfs, maybe it's not a complete garbage.

My assumptions are:

  1. Alice, Bob and Eve act as nodes in IPFS swarm;
  2. Eve is capable of capturing Alice <…> Eve <…> Bob traffic, but she cannot modify it (for now);
  3. There is no Tor/I2P-like routing between Alice and Bob;
  4. (NPK, NSK) — node's public and secret keys; (UPK, USK) — user's public and secret keys; USK could be made password-protected, but NSK is not;

When NSK or USK are compromised — how could they be revoked? How to send a revocation certificate to the distributed and decentralized network? If USK could be used to sign NPK (which is possible, since they are just RSA keys) and NSK is not password-protected - stealing NSK means giving irrevocable, marginally trusted by user's peers, secret key; Maybe this creates possibility to abuse web of trust, if it would be implemented; In my opinion, signing NPK by USK must be very explicit action.

Automatic UPK/NPK finding for signed-only objects looks good and useful, but for encrypted objects — why would IPFS give Eve a possibility to determine owner of the encrypted object? It's none of her business. Key exchange may be done in private and public key exists only on Alice's and Bob's nodes, hidden from IPFS lookups.

whyrusleeping commented 9 years ago

No, no changing other tools! compose them (or even alias them). instead of having ipfs add -r support encryption, we wrap ipfs add to do ipfs encrypt | ipfs add .

@jbenet I have to say that i disagree with this.

jbenet commented 9 years ago

Add: ipfs key show

quartzjer commented 9 years ago

Have you considered using parts or all of JOSE? There's a significant amount of solid standards work there that seems applicable :)

jbenet commented 9 years ago

@quartzjer thanks for pointing out that spec-- will take a look. probably a lot of good ideas we can use.

(note: cannot use it directly as json doesn't come into the keyspec, as we'll be supporting the most popular key encodings. if this one becomes (or threatens to be) popular can also add it)

jbenet commented 9 years ago

@whyrusleeping https://www.agwa.name/projects/git-crypt/

wking commented 9 years ago

I was looking at the WIP spec, and things like:

Note: Never store passwords as strings, strings cannot be zeroed out after they are used. using a byte array allows you to write zeroes over the memory so that the users password does not linger in memory.

make me feel skittish ;). Personally, I'd rather outsource at least human-initiated signing and private key storage to something with a few decades of history (like GnuPG). JSON Web Keys look reasonable standards for public key objects, private keys objects without passphrases, and automated signing. The more we can borrow from an existing implemenation (like GnuPG) or spec (like JWK), the less of the wheel we have to reinvent here ;). And if you're offloading human-initiated encryption/decryption to GnuPG you don't need to touch the passphrase at all, because it's acquired out-of-band via a pin-entry program.

For automated node signing that's more transactional (e.g. signing a list of IPFS objects you can provide), I think passphrase-encrypting the secret key is more trouble than its worth. Passphrase-protection (at least in the standard node implementation) should be reserved for things like ipfs name publish … or other quasi-persistent associations where violating the trust has more serious consequences than “What do you mean you don't have object ? I have a signed record saying you did! Oh well, guess I'll ask someone else…”.

wking commented 9 years ago

Why require an ephemeral symmetric key? If a particular encryption algorithm would benefit from such a key, I expect it would be part of the usual encryption/decryption algorithm and could be transmitted as part of the encrypted payload. Although the JOSE folks know a lot more about this than I do, and they mention wrapped symmetric keys in their encryption spec. But they also talk about asymmetric encryption, and I haven't read carefully enough to figure out how they handle occasionally-needed fields.

jbenet commented 9 years ago

@wking

make me feel skittish ;). Personally, I'd rather outsource at least human-initiated signing and private key storage to something with a few decades of history

Agreed. I want to use agents as much as possible. ideally we wouldn't even touch the keys.

There is a UX tradeoff, and cases where ephemeral nodes and permanent nodes differ-- meaning, nodes whose keys got generated for a temporary session, and nodes whose identity matters in the long run. In the latter case we want to delegate to agents, but it should just work. We'll follow an upgrading principle where user settings dictate what we do-- i.e. generate a key for this run or use a private key in a file or delegate to an agent.

cryptix commented 9 years ago

No ipfs key import?

How do I add keys received by mail/thumbdrive?

which kind of key will ipfs key send send?

Rest of the commands talk about keypairs. Is it a peer<>peer shared secret? (If so) why is it not the public key?

New 'Encrypt' package describes hybrid crypto.

How do I tell (multiple) people how to decrypt $hashx? Do I specify Recipients before or do I expose the corresponding key later?

whyrusleeping commented 9 years ago

We should have an ipfs key import thats a good idea.

The keys sent will be a private key of type p2p/crypto.PrivateKey encoded and encrypted (encryption beyond our default interpeer transport encryption)

BillDStrong commented 9 years ago

Have you looked at Keybase.io? It is invite only currently, but it is basically a really user friendly website to do the user interfacing aspect.

They say of themselves "Keybase is two things.

a public, publicly-auditable directory of keys and identity proofs a protocol for accessing the directory"

https://github.com/keybase/kbpgp

for their BSD licensed JS and node powered pgptools.

They have you verify you have access to your social accounts by post a signature message showing you have access to an account.

I have a few invites if someone wants to look.

jbenet commented 9 years ago

Hey @BillDStrong I appreciate the intent to help out, but please look more carefully through the repositories. this one in particular is for the specs, and not a good place to post when you don't yet know much about IPFS. See https://github.com/ipfs/specs#collaborating

Please also search github and the IRC logs, or you'll just be adding noise. While well intentioned, this post is just noise: we are well aware of keybase, and already plan to use it some ways.

BillDStrong commented 9 years ago

For an automated system, LetsEncrypt.org is a free certificate authority that is creating automated tooling around sign SSL certificates for an encrypted web. The automated nature of the tools could be a good fit for this project, as well as take the responsibility off of IPFS on storing the Certs.

https://github.com/letsencrypt/acme-spec is their spec and https://github.com/letsencrypt/node-acme is a node implementation and https://github.com/letsencrypt/boulder is a go implementation of the CA.

In case you can't tell, I am a strong fan of using standardized security tools to help prevent unintended bugs. And if you don't have to roll your own, you can work on the problems that really need to be solved.

jbenet commented 9 years ago

@BillDStrong please stop and read more before posting -- these comments are not actually related with the precise functionality the keystore has. For example, if you did, you'd know that today IPFS does not use TLS or CA certs. I again suggest you search github, IRC. I'd recommend posting in https://github.com/ipfs/faq or https://github.com/ipfs/notes while you're learning about the project.

BillDStrong commented 9 years ago

Thanks for the response. FYI, while I have seen the IRC channel posted, nowhere had I seen and IRC log, and most users would not no to look.

illya13 commented 8 years ago

Any news around ipfs key ?

whyrusleeping commented 8 years ago

@illya13 Its slated to be implemented Q3 of this year. (so, by october at the latest)

illya13 commented 8 years ago

@whyrusleeping any updates please ?

whyrusleeping commented 8 years ago

@illya13 The most interesting progress so far is that we're working on adding support for ed25519 keys into go-libp2p-crypto. I was really planning on getting to the keystore stuff sooner, but its been unfortunately pushed back. Stay tuned, and please do keep pinging us about this.

My new estimate for the beginning of this functionality is sometime in november. It will likely just entail the ability to create and store multiple keys, with no signing or encryption commands in the first release. Multiple keys will allow nodes to manage multiple ipns entries.

illya13 commented 7 years ago

@whyrusleeping any new updates ?

hackervera commented 7 years ago

Would love a way to export/import keys so that i can have shared access to an ipns key. Is this what this ticket addresses?

Lennie commented 7 years ago

The ipfs key send part seems strange to me: when each user has a keypair (private & public key) all you need is the public key of the user to encrypt the key you want to send and store it somewhere where it can be retrieved. The simplest way is to keep those files with the data that was encrypted.