Security considerations of using SSH keys for encryption

[link2xt]

age allows to use SSH keys to encrypt messages. As far as I understand SSH itself is using keys for signatures, but not for encryption. SSH key exchange runs Diffie-Hellman key agreement protocol and resulting session key is used for encryption, but SSH keys are only used to sign key exchange messages.

OpenPGP clearly separates keys used for encryption and signatures: https://datatracker.ietf.org/doc/html/rfc6637 First have ECDH algorithm (18) and last have ECDSA (19) algorithm. It is generally discouraged to use the same key for both encryption and signing: https://security.stackexchange.com/questions/1806/why-should-one-not-use-the-same-asymmetric-key-for-encryption-as-they-do-for-sig

I am not sure if practical attack is possible, but can imagine something could be possible if attacker has a copy of encrypted message and runs SSH server that you try to connect to, potentially automatically and many times. If more tools reuse SSH keys like this, it could also be not SSH, but some other simpler protocol.

Has the possibility of such attacks been analyzed? I don't see anything in the readme or specification.

[cipriancraciun]

[First a disclaimer, I am not an age developer nor am I a cryptographer, thus I might be wrong.]

---

I'll be focusing on RSA keys. For Curve15529 keys, called ed25519 in SSH, things are quite different and thus safe from the concerns you've mentioned. (ECDSA keys, called ecdsa in SSH, don't support encryption.)

In essence, "raw" RSA has only two operations "decryption" (by using the private key) and "encryption" (by using the public key); "signing" is in fact just "decryption" and "verifying" is just "encryption". Thus, if the attacker has access to an unattended device that can run "raw" RSA "decryption" / "signing" operations, then indeed one could compromise anything that was encrypted towards that RSA public key.

However, fortunately (hopefully?) nobody uses "raw" RSA operations, because most systems employing RSA use complex constructs on-top of the raw operations; for RSA these are called "padding schemes". Thus, one can misuse two different systems using the same key pair, therefore using one system to decrypt data from another system, only if they use the same padding schemes (and other cryptographic details).

Getting back to age, if I read the code correctly

age/agessh/agessh.go

Line 78 in 29b68c2

wrappedKey, err := rsa.EncryptOAEP(sha256.New(), rand.Reader,

it uses RSA OAEP padding scheme (https://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding) with a custom label of age-encryption.org/v1/ssh-rsa. This "label" I think it's called "domain separation" in cryptographic terms. It's main purpose is to eliminate exactly the problem you are referring to, namely even if two systems reuse the same cryptographic primitive (RSA) with the same cryptographic material (our RSA key pair), if they use different "domain separation" then they should be fine, and data from one can't be decrypted with the other.

---

Attacking the same issue from another angle, namely say that the encryption system uses RSA the wrong way (i.e. without a padding scheme, or a problematic one), and that we encounter the rogue SSH server you've mentioned, that wouldn't work either because SSH clients don't just allow the server to ask for arbitrary things to be signed (and remember, for RSA "signing" is actually "decrypting"). Instead the client crafts a particular payload that it will sign (from https://datatracker.ietf.org/doc/html/rfc4252#section-7):

   The value of 'signature' is a signature by the corresponding private
   key over the following data, in the following order:

      string    session identifier
      byte      SSH_MSG_USERAUTH_REQUEST
      string    user name
      string    service name
      string    "publickey"
      boolean   TRUE
      string    public key algorithm name
      string    public key to be used for authentication

(In fact, if I remember correctly, the SSH client doesn't just sign the above, but a hash of the above with PKCS padding scheme.)

Thus, unless your encryption software happens to use a padding scheme that yields a message like the above (which shouldn't be the case as it doesn't make sense), a rogue SSH server shouldn't be able to force a SSH client to decrypt arbitrary data.

Moreover, the "session identifier" value isn't controlled solely by the server, instead it's a hash based on inputs both from the server and the client. Thus, another road-block for a rogue SSH server.

[FiloSottile]

Key reuse across signatures and encryption is indeed not safe and requires analysis.

I did the analysis when designing age, and I meant to publish my notes properly but failed to do it so far, sorry!

In the meantime, https://eprint.iacr.org/2021/509 and https://eprint.iacr.org/2011/615 are relevant. 2021/509 doesn't apply 1:1 to our use of HKDF, but can be adapted.

[wiktor-k]

I did the analysis when designing age, and I meant to publish my notes properly but failed to do it so far, sorry!

A gentle ping - I'd be very happy to see your notes published as I've seen a similar design (reusing secret key bytes for ed25519 and X25519) elsewhere.

Thanks for your time! 🙇