Allow passing in a path for private key

[paixaop]

Allow passing in a path for private key

[abenmrad]

As of now, and as far as I know, this module doesn't this feature. However, a few months, I forked this module specifically to add such feature (that I called the "KeyRing").

Note however that the key file format is custom (but documented). I hope this will fit your needs.

(I'm not sure why I didn't file a pull request yet. But in the meantime, improvements have been made to the original repo, and I'm afraid merging the original in my fork will break things I can't afford to fix now. I hope this makes sense.)

[carlos8f]

@BatikhSouri I'm interested in your KeyRing feature but leaving the key unencrypted on the disk seems like a risk that negates the binding's benefits. PEM format with a symmetric key might be appropriate. Any thoughts on that?

[abenmrad]

@carlos8f I know that keeping the key unencrypted on the disk is a potential risk depending on the use case. I guess you're suggesting that the PEM format should be implemented in the C++ code, right? I'm planning soon to add a key encryption feature. I haven't decided on the format yet, nor at which level this should be written. I think that the fastest way to do it and allow multiple key format is to add a method to the KeyRing that will allow to load the key from a buffer/encoded string (rather than a file) that could be called from JS. Hence the key would be temporarily stored into "JS memory", which will again indeed defeat the initial purpose of KeyRing, depending on the use case. What do you think?

(I'm a bit confused. The way this needs to be implemented really depends on the threat model you have in mind. The JS thing described above would probably be sufficient in my use case and threat model, but maybe not for you)

[paixaop]

Guys this code should run on a node server, if a hacker has remote access to the memory contents of the server the battle has been lost, not matter if the keys are encrypted on file or not. I don't think it is a problem to have the keys in javascript in this context.
If you are using shared servers then it's a different story. Any comments?

[carlos8f]

A simple disk-based threat model: think of a bitcoin wallet, if you had one on your laptop and the private key was unencrypted, and the laptop was stolen or lost for whatever reason, someone could spend your bitcoins. Same thing for an SSH private key if it were left without a passphrase.

I don't think it is a problem to have the keys in javascript in this context.

I'm not that worried either, but there are those that consider JavaScript a bad choice for crypto because of its garbage-collected nature. Hacker access to memory is game over, but I thought if there was a way to secure the memory (KeyRing from @BatikhSouri 's fork) I might as well try it. What I'll probably end up doing is more along the lines of ssh-agent though.

[abenmrad]

@carlos8f, if you're interested (even though this might not be exactly what you're looking for), I'm gonna soon try to merge newer versions of libsodium in my fork and try to use crypto_pwhash_scrypt + crypto_secretbox to encrypt/decrypt key files.

Initially I didn't hurry for key encryption, since its need depends on your threat model. And as @paixaop said, in case you use this on a server (which was my initial use), the key encryption could be pointless in addition to make the sysadmin's life more complicated. But recently I'm planning on using the KeyRing on a client app as well, and here it would be a lot better to have password protection for keys.

[alexanderkjeldaas]

@mjsalinger For that type of threat, I think a more robust solution is to fork() a process that does the encryption/signing/whatever and then pass the results back. There is probably some npm package that wraps that up in a nice abstraction.

Even after wiping native sodium buffers, and read(2) to avoid copies in the C library, the kernel will still have it in the buffer cache. So if we assume an attack that compromises the kernel is outside the threat model, then fork() without caring about wiping keys is safe and robust.

[abenmrad]

Side note for @carlos8f, in case you are still interested : I have now built in the key encryption with scrypt password derivation into my fork; see the doc of the save() and load() methods in the KeyRing.

[carlos8f]

@BatikhSouri thanks, I will check it out.

I think @alexanderkjeldaas is right that the ideal would be to have the child process spawn, decrypt the key temporarily, and shut down after use. However there would be a need for an interactive prompt to enter the passphrase, which would probably have to pipe STDIN through the main process to get to the child, exposing the passphrase to garbage collected JavaScript, and thus the key itself :)

What I have in mind is a long running process, which you enter the passphrase into once, and through unix pipes it can serve as a signer/decryptor, very much like ssh-agent. Wouldn't be safe against the rare memory attack, but the socket would be limited by file permissions (prevents against chosen plaintext), and totally safe against the "offline wallet theft" threat.

[squirrelsama]

To preserve the simplicity of this project, I would advocate that the project does not include this change. Not for security reasons. Just for simplicity.

This is certainly a fun topic of conversation, but I feel it's far out of scope for this project. From my perspective, the high-level API is already too much.

[paixaop]

True I've been thinking about splitting the high level out as well.