Post Quantum Provider

Post Quantum Provider 2.1

The IAIK-PQ (Post-Quantum) library is based on Java 8 and offers easy to use Post-Quantum signature and Public-key Encryption and Key-establishment algorithms (KEMs). With the advance of Quantum Computers such algorithms will gain in importance in the future.

Main Features

  • ML-DSA (Dilithium): One of the selected algorithms of the NIST Post-Quantum Cryptography competition in the sector “Digital Signature Algorithms”.
  • ML-KEM (Kyber): The selected algorithm of the NIST Post-Quantum Cryptography competition in the KEM category of the NIST Post-Quantum competition
  • Classic McEliece: One of the 4 Finalists of the NIST Post-Quantum Cryptography competition in the sector “Public-key Encryption and Key-establishment Algorithms” (KEMs). McEliece is recommended by the German Bundesamt für Sicherheit in der Informationstechnik (BSI).

 

More algorithms will follow.

Pricing and Licensing

For current prices of the IAIK Post Quantum Cryptography library, please see our price list and license conditions.

See Prices

Webshop

To order the product please visit our Shop

See Webshop

  • Written entirely in the Java™ language guaranteeing cross platform portability
  • Works on all JDK versions; Java 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21 and compatible.
  • Implementation of the Diltihium Signature Algorithm:
    • KeyPairGenerator, KeyFactory, AlgorithmParameters, Signature engines
    • Parameter Sets for all defined security levels: level 2, 3 and 5
    • Supports randomized and deterministic signing
    • Optional use of AES instead of SHAKE for seed expansion
  • Implementation of the Kyber Public-key Encryption and Key-establishment (KEM) algorithm:
    • KeyPairGenerator, KeyFactory, AlgorithmParameters, KEM engines
    • Parameter Sets for all defined security levels: level 1 (kyber512), 3 (kyber768) and 5 (kyber1024)
  • Implementation of the Classic McEliece Public-key Encryption and Key-establishment (KEM) algorithm:
    • KeyPairGenerator, KeyFactory, AlgorithmParameters, KEM engines
    • Parameter Sets for all defined security levels: level 1 (mceliece348864,  mceliece348864f), 3 (mceliece460896, mceliece460896f) and 5 (mceliece6688128, mceliece6688128f, mceliece6960119, mceliece6960119f, 8192128, 8192128f)

The NIST PQ-Competition is still in progress, so the algorithms are subject to change. Final versions of the standards are expected for 2024. In parallel, the IETF is working on the specification of key formats and algorithm identifiers for using PQ algorithms in X.509 certificates and IETF based protocols like TLS, CMS or S/MIME. Although initial versions of key and algorithm identifier specifications already exist they are also subject to change.

Online Javadoc for IAIK-PQ.

Wheras signing and verifying with Dilithium can be done in the accustomed way by using a JCA Signature engine, at the moment no API for an Key Encapsulation Mechanism is provided by the Java™ Cryptography Architecture (JCA). Therefore the IAIK-PQ Provider uses the KeyEncapsulationMechanism API of the IAIK-JCE toolkit for implementing the McEliece algorithm.

In both examples below we start by creating a KeyPair for the desired security level (take also a look at the demo sources included in the IAIK-PQ distribution).

Dilithium

After registrating the IAIK Post-Quantum Provider within the JCA Security framework we first create a Level 2 parameter set and use it to generate a Dilithium KeyPair:

IaikPq.addAsProvider();
AlgorithmParameterSpec parameterSpec = new Dilithium2AlgorithmParameterSpec();
KeyPairGenerator kpg KeyPairGenerator.getInstance("Dilithium");
kpg.initialize(parameterSpec);
KeyPair kp = kpg.generateKeyPair();
PrivateKey privateKey = kp.getPrivate();
PublicKey publicKey = kp.getPublic();

Then we create a Dilithium Signature engine and initialize it with the private key for signing:

Signature sig = Signature.getInstance("Dilithium");
sig.initSign(privateKey);

Finally the data to be signed is supplied to the Signature engine and the signature is calculated:

sig.update(msg);
byte[] sigVal = sig.sign();

For verifying the signature value the Signature engine has to be initialized with the public key:

Signature sig = Signature.getInstance("Dilithium");
sig.initVerify(publicKey);

After supplying the data the signature value can be verified:

sig.update(msg);
boolean ok = sig.verify(sigVal);
if (ok) {
  System.out.println("Signature successfully verified!");
} else {
  throw new SignatureException("Signature verification failed!");
}

McEliece

In the following example we use the McEliece Key Encapsulation Mechanism (KEM) as an alternative to the traditional key transport to create and transmit keying material in a secure and confidential way.

In contrast to traditional Key Transport techniques, where the symmetric session key is generated completely independently from (and represents an input to) the Key Transport method, the derivation of the session key is an inherent part of an Key Encacpsulation Mechansim (KEM). The KEM produces two outputs: the derived session key and the — simply spoken — encapsulated session key which is delivered to the receiving party who decapsulates it to derive the session key. The sending party uses the session key to encrypt the data, the receiving party uses it to decrypt the encrypted data.

Similar to the Dilithium example above we again start by generating a McEliece KeyPair for the desired security level (we use level 1 in our example):

IaikPq.addAsProviderWithJCE();
AlgorithmParameterSpec parameterSpec = new McElieceParameterSpec(SecurityLevel.LEVEL1);
KeyPairGenerator generator = KeyPairGenerator.getInstance("McEliece");
generator.initialize(parameterSpec);
KeyPair kp = generator.generateKeyPair();
PrivateKey privateKey = kp.getPrivate();
PublicKey publicKey = kp.getPublic();

The public key is published to the sender who uses it to derive and encapsulate a symmetric (AES in our example) session key. For that purpose the sender creates a KeyEncapsulationMechanism and initializes it with the public key of the receiver:

KeyEncapsulationMechanism kem = KeyEncapsulationMechanism.getInstance("McEliece");
kem.init(publicKey);

Now we create an empty byte array and pass it to the KEM engine to be filled with the AES session key material derived by the key encapsulation mechanism:

int aesKeyLength = 16;
byte[] sessionKey = new byte[aesKeyLength];
byte[] encSessionKey = kem.encapsulate(sessionKey);

From the derived session key material we can create the AES session key and use it for encrypting the data:

SecretKey secretKey = new SecretKeySpec(sessionKey, "AES");
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
GCMParameterSpec gcmParamSpec = ...;
cipher.init(Cipher.ENCRYPT_MODE, secretKey, gcmParamSpec);
byte[] cipherText = cipher.doFinal(plainText);

Cipher text, encapsulated session key and (in our example) GCM parameters have to be provided to the receiver who creates a KeyEncapsulationMechanism and initializes it with the private key:

KeyEncapsulationMechanism kem = KeyEncapsulationMechanism.getInstance("McEliece");
kem.init(privateKey);

Similar to the sender the receiver creates an empty byte array of the length of the expected session key. During decapsulating the given session key array is filled with the derived key material:

int aesKeyLength = 16;
byte[] sessionKey = new byte[aesKeyLength];
kem.decapsulate(encSessionKey, sessionkey);

From the derived session key material we can create the AES session key and use it for finally derypting the encrypted data:

SecretKey secretKey = new SecretKeySpec(sessionKey, "AES");
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
cipher.init(Cipher.DECRYPT_MODE, secretKey, gcmParamSpec);
byte[] plainText = cipher.doFinal(cipherText);
IAIK-PQ 2.1 – 15. October 2024
Class or Package Bug / Change / New Feature Description and Examples
ML-DSA B

Fixed randomized signing.

IAIK-PQ 2.0 – 30. September 2024
Class or Package Bug / Change / New Feature Description and Examples
iaik.security.pq.mldsa NF

Updated according to FIPS 204 (formerly Dilithium); pre-hash variant not included yet (will come soon)

iaik.security.pq.mlkem NF

Updated according to FIPS 203 (formerly Kyber)

iaik.security.pq.dilithium C

Changed to iaik.security.pq.mldsa

iaik.security.pq.kyber C

Changed to iaik.security.pq.mlkem

IAIK-PQ 1.3 – 13. June 2024
IAIK-PQ 1.2 – 19. December 2023
IAIK-PQ 1.1 – 25. September 2023
IAIK-PQ 1.0 – 15. July 2023

Any questions?

Don‘t hestitate to ask us about our products.

Contact us