Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA?

Sean Mullan sean.mullan at
Fri Aug 26 20:28:48 UTC 2022

John, David, Franco,

Thank you for your interest in helping define a new KEM API for Java. We 
agree that KEMs are an important mechanism and expect them to become 
more prevalent in the future. We also agree that there are challenges 
associated with retrofitting the current APIs (KeyGenerator, Cipher, 
KeyAgreement, etc) to implement KEMs, and thus we plan to define a new 
standard KEM API for Java.

Your experience will be valuable (as has your input so far) to help 
shape the direction of the API and confirm that it is flexible enough to 
meet your needs.

We will be following up with more details soon.


On 8/18/22 9:37 PM, John Gray wrote:
>   We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards.   In particular we are working on a composite KEM standard:
> See:
> However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010).
> I can add one into our toolkit (and I think David may have already added on into BC),  but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain...   Perhaps we could collaborate on extending the JCA to support KEM?      Essentially it requires methods.
> ss, ct := encapsulate(PublicKey)
> ss := decapsulate(PrivateKey, ct)
> -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards)
> -ct is a Cipher Text (a byte array would make sense)
> -Public and Private Keys would use the regular public and private key interface.
> -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct.   It could be called 'EncapsulatedKEMData' for example.
> Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc).   Calling it KEM would seem to make sense.    😊    It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct).
> Then algorithms could be registered in providers as usual:
>      put("KEM.Kyber","com.blah.Kyber")
>      put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM")
> Then the above methods (encapsulate and decapsulate) could be defined in that new object type.   Then we would be able to make use of it and not have to worry about incompatibility issues down the road...
> Cheers,
> John Gray
> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

More information about the security-dev mailing list