Transit support for x25519 encryption / decryption

[KrishnaPG]

Is your feature request related to a problem? Please describe.
Applications need to be able to implement Public-key authenticated encryption without having to know the private keys of the participants.

Describe the solution you'd like
x25519 encryption / decryption support on transit, that allows applications to prepare the encrypted content between two parties (similar to nacl's cryptobox) and decrypt the content

It would be good if developers can call a series of procedures, such as

Generate a random AES key.
Use the AES key to encrypt the message.
Hash the encrypted message using SHA-256.
Use the sender's secret key to sign the hash.
Use the recipient's public key to encrypt the AES key, hash, and signature etc...

to customize the protocol as they see fit for their purpose.

The goal is for two-parties to be able to securely exchange data based on public/private keys, without having to share any common secrets, or trusting any third party. And the application should not know the private keys (and public keys, if possible)

[jefferai]

If you don't trust a third party, you don't trust Vault, right? I'm not really following the actors and who you are and aren't trusting.

[jefferai]

I guess to put more of a fine point on it -- nacl is great but when using it you often don't have the advantage of a trusted intermediary. If you don't trust Vault, you shouldn't trust it to perform the actions in your list. If you are trusting Vault, why go so low level?

[KrishnaPG]

Thank you @jefferai

Vault is not a third-party. It is run by both parties separately (each party has their own vault instance).

Allow me to illustrate with an example: Consider two parties A and B

A has own secrets stored in A's vault.
B has own secrets stored in B's vault.

Now, A and B need to exchange some data, through some app. This app, they do not trust (since it is something they just downloaded from, say, playstore). On the other hand, each A and B, trust their own Vault, since it is under their control.

• The app needs to get encrypted data from A and deliver it to B, without knowing what their keys are.

Vault already has other types of keys, such as aes, rsa etc. It seems to be missing the x25519.

We tried to use RSA, but the key size immediately became a big road-block.

[xorhash]

I happen to have run into a similar use case myself recently, perhaps this can shed more light onto why this is useful: I've got a scenario in which I have key material that I need to send over a semi-trusted connection to be handled by a trusted component.

Consider a Vault instance that holds an X25519 secret key. It is used to derive keys with external, semi-trusted clients.

Each client is equipped with a secure execution environment (think: ARM TrustZone, Intel SGX). The secure execution environment will receive a signed blob of data over the network via (indirect) connection to the Vault instance. The signed blob contains the server's X25519 public key followed by a ciphertext encrypted with the key derived from the X25519 exchange. Each client has a different X25519 keypair, rather than a preshared key that is known to all units; this prevents (a) the preshared key from being leaked and breaking all the ciphertexts that way, and (b) auditability. The connection between the service and the client may be in the view of attackers (it's just a TLS connection for performance reasons), or the container holding the X25519 key may be dumped from permanent storage. The server X25519 key must be in Vault because it leaking would break all the ciphertexts.

I hope that details a concrete scenario in which this is useful.

Incidentally, it is possible to transform Ed25159 keys to X25519 keys, but the wider cryptographic community seems to be generally convinced that doing so isn't the best idea and isn't entirely sure about whether it's a good idea. FiloSottile's age tool will be doing just that, however.

[jefferai]

The problem with this scenario tends to be one of storage and identification. You need some way to tie the server's key with either the client's key or the client itself, perhaps by storing a key for a client as metadata in the client's Identity info. IOW it's not a question of utility, it's a question of scaling.

I think that since this issue was opened there is now a decent way forward: key derivation using the client public key. In Go 1.13 the stdlib finally got some native support for x25519; see https://godoc.org/golang.org/x/crypto/curve25519#X25519. If the client public key can be used as the scalar value then it essentially becomes a derived key, with the point value from the underlying secret key known only to the server. And even though any client could give a different client's public key, the shared key is not derivable without the client's secret key.

I think this could work, but I am not sure if there are any security dragons here.

[RinkalBhojani]

@jefferai
We also have similar kind of requirement
We need two-parties to be able to securely exchange data based on public/private keys, without having to share any common secrets, or trusting any third party. And the application connecting to vault should not know the private keys.

Encryption/Decryption should be done within the vault based on this(Ed25519) asymmetric keys.

Is there any plan or any existing way to support asymmetric encryption based on public/private key pair.

[hsimon-hashicorp]

I believe that this has been resolved in newer versions of Vault. Please let me know if you think this is still something that needs addressing. Thanks!

[joeshaw]

@hsimon-hashicorp It doesn't appear to be supported as of 1.15.

[hsimon-hashicorp]

@hsimon-hashicorp It doesn't appear to be supported as of 1.15.

Thank you for the confirmation! I'll add it to our cryptosec team board.