Skip to content

@pqc-sdk/core / generate

Function: generate()

Call Signature

generate(): Promise<KeyPair<"x-wing">>

Generates a post-quantum key pair. With no options it generates an X-Wing hybrid pair (X25519 + ML-KEM-768), ready for pqc.encrypt.

The no-argument default is hybrid because a break in either component still leaves the other standing — the same reasoning behind TLS 1.3's X25519MLKEM768, Signal's PQXDH, and the BSI and ANSSI recommendations. ML-KEM-768 is young, and a cryptanalytic result against it would leave a pure-PQ ciphertext with nothing to fall back on.

'ml-kem-768' remains fully supported and is the right choice in two cases: when FIPS certification scope matters (X-Wing is not covered by FIPS 203, so a compliance regime requiring a certified KEM needs the pure one), and when size or speed dominate (32 bytes less per envelope, and roughly 2–4× faster per operation — see docs/MIGRATION-0.8.md).

Returns

Promise<KeyPair<"x-wing">>

Example

ts
import { pqc } from '@pqc-sdk/core';

const encryption = await pqc.keys.generate(); // x-wing hybrid
const pureMlKem = await pqc.keys.generate({ algorithm: 'ml-kem-768' });
const signing = await pqc.keys.generate({ algorithm: 'ml-dsa-65' });

Call Signature

generate<A>(options): Promise<KeyPair<A>>

Generates a post-quantum key pair. With no options it generates an X-Wing hybrid pair (X25519 + ML-KEM-768), ready for pqc.encrypt.

The no-argument default is hybrid because a break in either component still leaves the other standing — the same reasoning behind TLS 1.3's X25519MLKEM768, Signal's PQXDH, and the BSI and ANSSI recommendations. ML-KEM-768 is young, and a cryptanalytic result against it would leave a pure-PQ ciphertext with nothing to fall back on.

'ml-kem-768' remains fully supported and is the right choice in two cases: when FIPS certification scope matters (X-Wing is not covered by FIPS 203, so a compliance regime requiring a certified KEM needs the pure one), and when size or speed dominate (32 bytes less per envelope, and roughly 2–4× faster per operation — see docs/MIGRATION-0.8.md).

Type Parameters

A

A extends Algorithm

Parameters

options

GenerateOptions<A> & object

Returns

Promise<KeyPair<A>>

Example

ts
import { pqc } from '@pqc-sdk/core';

const encryption = await pqc.keys.generate(); // x-wing hybrid
const pureMlKem = await pqc.keys.generate({ algorithm: 'ml-kem-768' });
const signing = await pqc.keys.generate({ algorithm: 'ml-dsa-65' });

Call Signature

generate(options?): Promise<KeyPair<Algorithm>>

Generates a post-quantum key pair. With no options it generates an X-Wing hybrid pair (X25519 + ML-KEM-768), ready for pqc.encrypt.

The no-argument default is hybrid because a break in either component still leaves the other standing — the same reasoning behind TLS 1.3's X25519MLKEM768, Signal's PQXDH, and the BSI and ANSSI recommendations. ML-KEM-768 is young, and a cryptanalytic result against it would leave a pure-PQ ciphertext with nothing to fall back on.

'ml-kem-768' remains fully supported and is the right choice in two cases: when FIPS certification scope matters (X-Wing is not covered by FIPS 203, so a compliance regime requiring a certified KEM needs the pure one), and when size or speed dominate (32 bytes less per envelope, and roughly 2–4× faster per operation — see docs/MIGRATION-0.8.md).

Parameters

options?

GenerateOptions<Algorithm>

Returns

Promise<KeyPair<Algorithm>>

Example

ts
import { pqc } from '@pqc-sdk/core';

const encryption = await pqc.keys.generate(); // x-wing hybrid
const pureMlKem = await pqc.keys.generate({ algorithm: 'ml-kem-768' });
const signing = await pqc.keys.generate({ algorithm: 'ml-dsa-65' });