moronic monday (pst) question time. this may have been covered elsewhere, and emphatically shot down (and if so, I apologize), but I'm interested in using ssh-agent to decrypt data. ssh certificates are the most secure user auth token we have, and even though ssh certs aren't chainable, we routinely use them to assert identity to things other than ssh (eg. if you can present a cert that's signed by a known ca, and you can prove you have the private key that belongs to the cert, we know who you are). So it'd be nice to be able to give some data back to the client, encrypted with the client's pubkey, that the client could then ask the ssh-agent to decrypt using the corresponding private key. in the past, we've generated a new keypair and sent the new pubkey with the request, but that's a little clunky and it's as tightly bound to "one source of truth" as if we could just rely on the key from the cert. I'm guessing there's a dead simple reason something like this isn't supported already. like, maintenance of code that only a weenie like me would use or that it would enable some new class of cryto attacks or something. Cheers, peter
On Mon, 19 Nov 2018, Peter Moody wrote:> moronic monday (pst) question time. > > this may have been covered elsewhere, and emphatically shot down (and > if so, I apologize), but I'm interested in using ssh-agent to decrypt > data. > > ssh certificates are the most secure user auth token we have, and even > though ssh certs aren't chainable, we routinely use them to assert > identity to things other than ssh (eg. if you can present a cert > that's signed by a known ca, and you can prove you have the private > key that belongs to the cert, we know who you are). > > So it'd be nice to be able to give some data back to the client, > encrypted with the client's pubkey, that the client could then ask the > ssh-agent to decrypt using the corresponding private key. in the past, > we've generated a new keypair and sent the new pubkey with the > request, but that's a little clunky and it's as tightly bound to "one > source of truth" as if we could just rely on the key from the cert. > > I'm guessing there's a dead simple reason something like this isn't > supported already. like, maintenance of code that only a weenie like > me would use or that it would enable some new class of cryto attacks > or something.There are a few reasons: 0) AFAIK nobody has ever asked before :) 1) Not all SSH key algorithms support decryption, e.g. ECDSA and Ed25519 are signature-only. Only RSA allows decryption without abusing the key. 2) It's generally frowned upon to use the same key for encryption and signing. Given those, it would still be possible to make a SSH agent extension to support encryption, If you do this, then please consider using the extension mechanism in the ssh-agent protocol draft - https://www.ietf.org/archive/id/draft-miller-ssh-agent-02.txt It's pretty unlikely we'd include this in the upstream version though - it's very niche and probably too easy to misuse. -d
On Tue, Nov 20, 2018 at 10:35:06AM +1100, Damien Miller wrote:> 0) AFAIK nobody has ever asked before :) > 1) Not all SSH key algorithms support decryption, e.g. ECDSA and Ed25519 > are signature-only. Only RSA allows decryption without abusing the key. > 2) It's generally frowned upon to use the same key for encryption and > signing.Also note that the authentication key may be weaker than the channel encryption key; eg an RSA2048 bit key is only the equivalent of 112 bits of symetrical key strength. So it's not clear this provides any advantage over just using the existing encrypted channel. -- rgds Stephen
On Tue, 20 Nov 2018, Damien Miller wrote:> Given those, it would still be possible to make a SSH agent extension to > support encryption, If you do this, then please consider using the > extension mechanism in the ssh-agent protocol draft - > https://www.ietf.org/archive/id/draft-miller-ssh-agent-02.txtActually, you don't need any extensions to do this - you can get the pubkey from the agent directly and convert it to PEM format using "ssh-keygen -e -m PEM -f /path/key.pub > /path/key.pem">From there you can use the standard openssl API or tools to do yourcrypto. -d
On Mon, 19 Nov 2018 at 12:31, Peter Moody <mindrot at hda3.com> wrote:> > moronic monday (pst) question time. > > this may have been covered elsewhere, and emphatically shot down (and > if so, I apologize), but I'm interested in using ssh-agent to decrypt > data.Somewhat related as its not through the agent but https://github.com/jschauma/jass is a tool that lets you use ssh keys to encrypt and decrypt secrets. I did not do any evaluation of its security properties. -- Eitan Adler