search

hyperledger-archives / aries-framework-go

Hyperledger Aries Framework Go provides packages for building Agent / DIDComm services.
https://wiki.hyperledger.org/display/ARIES/aries-framework-go
Apache License 2.0
240 stars 161 forks source link

Refactor JWE crypter to use Ed25519 verkey parameters #454

Closed Moopli closed 5 years ago

Moopli commented 5 years ago

DIDExchange uses keys to sign and encrypt messages, and appears to expect that the same keys be used for both purposes. A method exists in the legacy envelope format for using signing/verification keys for encryption/decryption - valid Ed25519 keypairs used for signing and verification can be converted through some ECC algebra into valid Curve25519 keypairs used for encryption/decryption.

LibIndy converts Ed25519 keys to Curve25519 keys for encryption, here, for example. As does ACA-Py in their python wallet, here, for example.

We most likely need to process Ed25519 keys and do similar conversions in the JWE crypter.

Specs are currently unclear or silent on this matter (perhaps it is assumed to be done as a matter of course) so the task should involve clarifying the relevant RFCs, figure out whether we should be doing these key conversions, or update the specs to include a different solution (for example, exchanging both signing and encryption keys in DIDexchange).

Moopli commented 5 years ago

This will allow us to expose only the signing key from the wallet, with only the Crypter using encryption keys.

Moopli commented 5 years ago

We've discussed this and won't need it - the JWE envelope can deal with only encryption keys, with signing keys only applying to payloads. The wallet will associate signing and encryption keypairs, so it can provide the correct encryption keys to the JWE crypter for communication with a particular agent.

That signing keypair <-> encryption keypair association can be done by Ed25519 -> curve25519 conversion, or by exchanging encryption keys alongside signing keys in DIDexchange, for example.