The goal of the crypto and KMS plugins is to provide a pluggable service providers interface for Cryptographic operations such as Encryption, Decryption, Signing and Verification as well as keys management operations usually offered by a KMS (Key Management Service).
...
Tink, a library created to make crypto easy for non cryptographers, is a strong candidate that offers pluggability of crypto operations and supports integration with multiple KMS solutions like AWS KMS, GCP (Google Cloud KMS), HashiCorp Vault and Android Keystore KMS. It supports multi languages including Go. Tink serves to wrap the crypto functions in a KMS, so the client cannot see secrets, and so the client works with a simpler API that makes it harder to break your crypto. It also supports key wrapping using ECDH, but it does not match ECDH-1PU which will require additional work.
The plan is to have 3 interfaces in three sub-directories under pkg/plugins, one for JWEBuilder to serialize/deserialize a JWE, another for Crypto and the other for KMS. Crypto and KMS interfaces a new shrive provider interface (SPI for short) to handle Crypto and KMS operations. These operatins will serve as wrapper to Tink operations primitive functions like Encrypt(), Decrypt(), Sign(), Verify(), etc. While JWEBuilder will use the other two to build a JWE envelope by offering a Seal (serialize) and Open (unserialize) functionsGenerateKey(), DisableKey(), etc. See Diagram below that depicts the design of this Aries Crypto framework. In this diagram, Tink's Crypto primitives are used directly in the `Crypto SPI` default implementation and will use a KMS implementation provided by Tink directly (Phase 1). The second part of the diagram provides a more generic KMS interface that is not directly tied to Tink to allow for third party KMS integrations (Phase 2). In order to maintain compatibility with Tink, an adapter is required to translate the KMS implementation with Tink's Crypto primitives (ie translate keys into *keyset.Handle instances). Phase 2 can be done at a later stage once the first phase is completed.
The introduction of Tink begins with Crypto interface for which an a, default, implementation will use Tink primitives for the crypto operations. Tink will need to be updated to use a custom AEAD cipher with key wrapping using ECDH-1PU. The implementation will somewhat resemble the Hybrid AEAD one in Tink with the difference in the key derivation function differs in 1PU (here) than the conventional and standardized HKDF (example here and defined here) mode.
...