Keystore Review about specs HOT 27 OPEN

@whyrusleeping any new updates ?

from specs.

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.

from specs.

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.

from specs.

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

from specs.

Also:

• need to look into pgp keyrings
• outline all supported key formats

from specs.

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

• sign keys to be part of the same identity
• trust keys to let them take action in our nodes (push/pull keys, use api, etc)
• ban keys to avoid all interaction with them

from specs.

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

from specs.

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.

from specs.

Add: ipfs key show

from specs.

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

from specs.

@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)

from specs.

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…”.

from specs.

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.

from specs.

@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.

from specs.

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?

from specs.

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)

from specs.

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.

from specs.

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.

from specs.

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.

from specs.

@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.

from specs.

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.

from specs.

Any news around ipfs key ?

from specs.

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

from specs.

@whyrusleeping any updates please ?

from specs.

@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.

from specs.

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?

from specs.

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.

from specs.