search

dedis / onet

Overlay Network for distributed protocols
GNU Lesser General Public License v3.0
51 stars 28 forks source link

[Keys] Storage of private information #203

Open nikkolasg opened 7 years ago

nikkolasg commented 7 years ago

Now that a config package is being developed in onet, there needs to be a way to securely store secrets keys and other confidential informations. For the Mac OS keychain store, there seems to be a wrapper in Go: https://github.com/keybase/go-keychain But on Linux, it sounds like the "state of the art" approach is still storing them in files with the right permission settings, like ssh and pgp. One thing we could do though is to offer the possiblity of encrypting the key with a passphrase.

Anyway, there needs to be more thought on this (please, let's discuss in this issue !) as there needs to be a distincition between the (future) TLS certificates of a conode, distinct private keys of services, and the "personal" private keys of users communicating with private keys. Each one may need different storage models and so on.

nikkolasg commented 7 years ago

Link @ineiti comments: https://github.com/dedis/onet/pull/202#issuecomment-313691583

nikkolasg commented 7 years ago

@nikkolasg - when thinking of private/public keys - I think we need to differentiate two sets of private keys:

the ones coming from the apps (cisc, pop, pulsar, scmgr) the ones being used by the services

For 1. it makes sense to store them in a keyring (I would say this makes a nice [conode]-configuration option), while 2. will be run on servers and in multiple instances anyway, so no need to store those in the keychain.

What do you think?

jeffallen commented 6 years ago

Summary of latest discussion: user-facing CLI tools (e.g. cisc) should be storing keys in "proper OS key management services" as possible. conode private.toml files should not go away because it facilitates running multiple servers, Docker, etc. This is not for onet.v2 because it is a UI improvement to tools like CISC.