Implementation
Technical steps to implement the API
This is the ExeQuantum API for post quantum encryption. It uses ML-KEM for key encapsulation, as it was the NIST's choice for its post quantum security standardization competition.
It also utilizes its digital signature counterpart, ML-DSA, to digitally sign the key and verify its origin.
Unlike other algorithms like RSA, ML-KEM doesn't perform the encryption per se. Rather, it uses key encapsulation to generate a shared secret for symmetric encryption-decryption.
Example API Code
If you want to test the API for yourself before doing anything, feel free to clone https://github.com/samuelnsam/js-api-example and check it out. See for yourself how you can implement ML-KEM in 50 lines of code!
Example use cases for ML-KEM:
End to End Encryption
TLS
Symmetric Encryption
Example use cases for ML-DSA:
Message verification
Blockchain/Cryptocurrency proof of ownership
Below are the steps for ML-KEM and ML-DSA.
Before starting: Get your API token
PQCaaS uses an authentication token to allow calls into our API. When you sign up, you'll get a root token that does not expire (unless you reset it). It will appear in your dashboard, hidden until you choose to expose it, like so:
You can also copy it without showing it, if you need extra privacy.
It is highly recommended that you only use this token from secure environments, and only use temporary (ideally single use) tokens when making calls from more exposed environments like frontend. Steps to generate a temporary tokens will be described later in this documentation.
Below that, you'll see the dashboard that shows your API usage for the month. Keep an eye on it to track your usage.
That's basically it for the dashboard. Now we can begin the integration steps. If you want to learn a bit more the high level overview of how ML-KEM and ML-DSA work, please refer to the Getting Started page.
RECOMMENDED Step 0 (ML-KEM and ML-DSA): Generate a temporary token
In order to avoid overusing your sensitive authorization token, it's recommended to generate a temporary token that can be used for API calls.
You'll have to use the auth token for this call, so make sure to do it in a secure environment (i.e. backend)
This would be especially recommended when the API has to be called at areas where it has to be exposed to clients (i.e. frontend).
You can still use the auth token from your dashboard, at your own discretion.
You can determine how long the token should persist for (in seconds) through the expiry_time
parameter. The default is 300 seconds or 5 minutes.
It's recommended to keep it relatively short (i.e. the average length of a session on your app) and handle switching as needed.
The token also has a limited number of times that it can get called. By default it's 1 attempt per token, and it's highly recommended
to keep it at 1, just to encapsulate the key in the frontend, but if you have to, you can set the number of retries allowed with the
parameter expire_after_attempts
.
Note: examples are in Python, but the API can fit in every language.
Step 0:
The procedure to create a shared secret for symmetric encryption-decryption purposes will be as follows:
ML-KEM - Step A (by person A):
This generates a key pair that gets sent over for encapsulation and decapsulation. The secret key gets encrypted before being sent over, and can only be used by us.
The verification key and signature are necessary for the ML-DSA signature on the public key to prevent tampering. The private signature key does not need to be shared for verification.
Person A will sent the public key, verification key and verification signature to person B, while keeping the secret key secured with themselves.
ML-KEM - Step B (by person B):
This API endpoint generates a shared secret that will be used for symmetric encryption. It should not be shared.
The cipher and the encrypted secret key can be sent back for the key decapsulation.
ML-KEM - Step C (by person A):
This API point generates the same shared secret. The cipher and secret keys are used for it.
Now that both sides of the communications have a secured shared secret, the secure communication can commence.
It is recommended to use AES256 for the encryption and decryption, as they're considered Quantum secure.
AES encryption and decryption are offered as API endpoints for free (Key generation and encapsulations are $1 per 4,000 requests), but you can feel free to use your own encryption.
If you decide to use our API for AES, it will go as follows:
ML-KEM - Step D (By encryptor):
This API call encrypted the message. Now to decrypt, the decryptor can just use the shared secret created by ML-KEM to decrypt the message.
ML-KEM - Step E (By decryptor):
And that's it! You got your Quantum secure communication channel. If you want to learn more, feel free to book a demo.
Below are the steps to use ML-DSA
ML-DSA - Step A (By person A):
From the endpoint, you get the generated signature and the public key that is used to verify the signature, as well as the secret key used to generate it.
The data, public key and signature should be sent over to person B, while person A needs to keep the secret key secure.
ML-DSA - Step B (By person B):
The verified
data will indicate whether the signature is valid. It returns false
is the signature or data was tampered with and true
if it's all good.
To see the terms and conditions of our API click here.
Last updated