I'm not sure how far you can usefully protect against an adversary with access to /proc/<pid>/mem.
You could punt on the problem entirely, and use ssh-agent. That could also allow users to take advantage of HSM integration, and absolves you from the UI for prompting for passphrases. Any adversary with access to the agent socket can still sign things <https://tools.ietf.org/html/draft-miller-ssh-agent-02#section-4.5> of course. It might be worth looking at ssh-agent source code to see what precautions (if any) it takes with keys in memory - also any other well-known programs that deal with an unlocked private key in RAM, e.g. apache2 mod_ssl. Aside: I don't agree with enforcing policy on administrators (i.e. "private keys must not be passwordless"). Firstly, you don't know the execution environment or trust model / threat model of all users. If you accept a private key on stdin then you have no way of knowing how well it was protected - it could have come from a gpg pipeline for example. Even when reading a key from disk, the key could be read from an encrypted filesystem, and the entire execution environment could be super-secure and isolated. Perhaps more importantly, people who have a legitimate need for passwordless keys are just going to use a dumb passphrase like "abcd1234", so all you're doing is making them wrap your application in 'expect' scripts, while cursing under their breath. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/38feedec-748d-4eea-9a88-ce4e23ec7d2a%40googlegroups.com.
