MPC ECDH support

ISO/IEC 18013-5 (mDL) requires ECDH, with P-256 or X25519 being suitable choices. I would like to request that ICP support MPC for P-256 or X25519.

In the future, ISO/IEC 18013-5 (mDL) and ISO/IEC 23220 (eID) are likely to become the de facto standards for digital certificates, potentially replacing W3C Verifiable Credentials. This is partly due to their high priority in the European Digital Identity Wallet (EUDIW).

Currently, there are no services that support MPC ECDH. If ICP were to support this, it would become a unique offering in the enterprise market.

Please consider implementing this feature.

7 Likes

I’d like to discuss the use case of MPC ECDH.

ECDH is generally used for encryption.
Alice encrypts certain content and sends it to Bob.
The encryption key is randomly generated. Since it’s used to encrypt the content, this encryption key is called CEK (Content Encryption Key).

As the CEK is sent over the internet to the recipient, the CEK itself needs to be encrypted.
The encryption key for the CEK is called KEK (Key Encryption Key).
ECDH is used as part of the process to create the KEK.

Let’s say Alice wants to encrypt and send content to Bob.
Let Alice’s private key be ‘a’, and her public key be A = aG.
Let Bob’s private key be ‘b’, and his public key be B = bG.

In ECDH, Alice and Bob first exchange their public keys (A, B).
To create the KEK, Alice and Bob calculate their private key * the other’s public key.
Alice: a * B = a * bG = abG
Bob: b * A = b * aG = abG

Alice and Bob have now shared a common secret information (KEK) without revealing their private information.
The actual KEK calculation is a bit more complex, but the basics are the same.

Alice encrypts the CEK with the KEK and sends it along with the encrypted content to Bob.
Bob calculates the KEK, decrypts the CEK, and then decrypts the encrypted content.
This is the basics of ECDH.

What I most want to do with MPC ECDH is content encryption between users and Canisters.

User A exchanges public keys with Canister B.
User A generates a random encryption key (CEK) and encrypts the content.

User A performs MPC ECDH with Canister B’s public key to obtain the KEK. They encrypt the CEK with the KEK and send it to Canister B along with the encrypted content.
Canister B stores the encrypted content and CEK in storage.

When User A wants a part of the content, they request it to Canister B.
Canister B performs MPC ECDH with User A’s public key to obtain the KEK.
It decrypts the encrypted CEK with the KEK.
It decrypts the content with the CEK, retrieves the requested part, encrypts it with a newly generated CEK, and sends it to User A.
User A similarly performs MPC ECDH with Canister B’s public key to obtain the KEK, then decrypts the encrypted CEK.
They then decrypt the part of the content with the CEK.

This is my idea of encryption and decryption between users and Canisters.
Users are not dependent on ICP-specific technology. The same can be done with regular ECDH instead of MPC ECDH.

2 Likes

The difference between MPC ECDH between users and Canisters and previous encryption methods is that Canisters can decrypt and process data without knowing the user’s secret information.

A use case well-suited for ICP is AI model training.
Users encrypt their private data using MPC ECDH and upload it to the Canister.
The Canister decrypts the data using MPC ECDH and performs AI model training. The training results are encrypted using MPC ECDH and stored.
When users need to make inferences, they download the encrypted model, decrypt it, and perform the inference.

  1. Encrypting and decrypting data within the canister seems unlikely to work, so I plan to use TEE to implement the AI scenario you described.
  2. ICPanda Message uses ECDH to exchange channel keys, but all of this happens on the client side.

Why do you think so?