Hi Mike,
KEMs can be used for key wrapping - we've actually implemented support
for this too. But they are not actually key wrapping ciphers.
Here's a simple example of using Kyber for key wrapping in BC:
SecretKey key =new SecretKeySpec(keyBytes,"AES");
w1.init(Cipher.WRAP_MODE, kp.getPublic(),new KEMParameterSpec("AES-KWP"));
byte[]data =w1.wrap(key);
Cipher w2 =Cipher.getInstance(algorithm,"BCPQC");
w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(),new KEMParameterSpec("AES-KWP"));
Key k =w2.unwrap(data,"AES",Cipher.SECRET_KEY);
The behavior in this case is in line with what is given in RFC 5990 for the RSA
KEM. How it works is by using the key generated
by the KEM to create an AES-KWP key, which is then used to wrap keyBytes. The
shortcoming is it means you have to generate the
secret key separately.
This is the problem though - a KEM can actually be used to generate a secret
key for other purposes. For example, where
someone is trying to implement a hybrid KAS scheme. But there is currently no
mechanism in the Java APIs for being able to
take advantage of this directly, hence our use of the KeyGenerator class and
other people's attempts to make use of the KeyAgreement
class. The Cipher.wrap() returns a byte[] - to be used with a KEM for secret
generation it would also have to return the
generated secret (I would probably also argue that passing a public key to wrap
in order to generate an encapsulation of a
generated encrypted secret was not the correct use of the API either, but the
fact remains a byte[] is not really going to cut it).
If you have any further questions, please feel free to ask. For what it is
worth, I have been developing providers for the JCE/JCA since
the late 90's and am actually one of the people responsible for the
introduction of the existing wrap/unwrap API in the Cipher class.
Thanks,
David
On 20/8/22 07:53, Mike StJohns wrote:
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.
