Private keys should be encrypted

[BrendanBenshoof]

You could encrypt the entire config file, but by default ipfs should password protect the private key (setup during init process) and not store the private key in the clear on disk (or ideally in memory that could be leaked, but that is a lot harder).

[whyrusleeping]

We are going to move the key out of the config file and encrypt it at some point.

[whyrusleeping]

related #783

[whyrusleeping]

This should be addressed once the keystore is implemented

[Kubuxu]

My proposal for multikey was embedding key protection schema in to the multikey itself, I don't know if we want to go with it, but it would be nice thing to have.

[jbenet]

@Kubuxu can you explain more?
On Wed, Aug 24, 2016 at 07:48 Jakub Sztandera [email protected]
wrote:

My proposal for multikey was embedding key protection schema in to the
multikey itself, I don't know if we want to go with it, but it would be
nice thing to have.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#826 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcofbJAvaf0rNCNfwDr2fnt3rElrimks5qjC-YgaJpZM4Dl4DP
.

[Kubuxu]

ipfs/specs#58
In short terms: first varint describes key protection schema which has to be applied to decrypt the key.

[AuHau]

While on my work on the #5947, which I am now porting to js-ipfs I saw that js-ipfs uses https://github.com/libp2p/js-libp2p-keychain

Is this desired way how to approach this? To my understanding, it does not use multikey/linked-data key, but it implements encrypted keys handling.

[AuHau]

Hmmm it seems like they follow this spec: https://github.com/ipfs/specs/tree/master/keystore

[Stebalien]

Eventually, yes. I have a PR that I never really finished to add pluggable keystore support to enable use-cases like this: #6069.

However, go-ipfs doesn't currently have a way to prompt the user for a passphrase.

[AuHau]

Hmm. From what I see js-ipfs does not really prompt for a passphrase either, they require (for operations that uses keystore) to pass it using parameter --pass.

What do you think is currently the right way to approach this? Or should this be postponed for now?

[Stebalien]

What do you think is currently the right way to approach this?

I'd rather not go that route. Any password passed with --pass will:

1. Get logged to some shell history somewhere.
2. Appear in ps -eF.

That just shuffles the problem around a bit.

[Kubuxu]

Same as with ssh, the password should be passed with stdin.

ssh-add goes even further and prohibits non-interactive input of a password.
The only way to automatically input password to ssh is using expect

[AuHau]

Yeah, I figured that this might be a problem and I have guessed right that similar approach to ssh should be the way.

Only I am a bit worried about the UX implications of this. As for every invocation of a command that needs keystore access, there would have to be this prompt (eq. reentering passphrase all the time). What sort of commands require keystore access?
daemon, key *, name *?

What about ssh-agent approach? Since there is already a background process ( daemon), this could be used to spawn another process that would behave as ssh-agent (eq. expose socket that all keystore dependant commands would use for key manipulations). The only problem is that it would complicate things quite a bit since to not compromise on security, the keys would have to stay in the agent process and hence all the actions with keys would have to be proxied through it.

[kimborgen]

Any updates on this problem?

Don't know if it is relevant, but maybe for inspiration, you can also have a look at how ethsigner solves this problem: https://consensys.net/docs/ethsigner/en/latest/Concepts/Overview/