Closed inverted-capital closed 2 years ago
@inverted-capital: You're right. Can you please open an issue in https://github.com/ipfs/js-ipfs-repo repo on how we can better store keys? There are various usability things we need to decide so the implementation can be picked up.
@BigLep thanks for writing back - I do not believe the correct repo for a fix is the https://github.com/ipfs/js-ipfs-repo repo because the keys are stored in config as part of the js-ipfs way of doing things. js-ipfs-repo is providing the config slice as a place to store an arbitrary POJO, and it is offering the keychain slice as a way of storing password based key derived encrypted data - it forces no format or usage restrictions beyond that.
I think the fix is to modify the way js-ipfs provisions itself to store the 'self' key in the keychain slice of the repo, encrypted with a blank password, and then if the user or programmer wants to set a password, this triggers a key rotation which is already built in to the repo implementation. The salt and pbkdf parameters would still be stored in the config in plain text.
Shall I open an issue in js-ipfs that proposes this fix ?
Triage notes:
a proper place to continue is:
I am closing this one @inverted-capital, feel free to link js-ipfs issue when you create it.
Considerable effort has been put in to integrating a password based key derivation scheme in js-ipfs, and yet the primary encryption keys of the node are not stored there. The private key for the node can be read in plaintext from the config slice of the repo.