Hi This implemented as part of Javax.crypto.Cipher. See the Java doc for the wrap and unwrap methods.
Mike Sent from my iPad > On Aug 19, 2022, at 12:56, John Gray <john.g...@entrust.com> 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: https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ > > 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.
