Add X-Wing (post-quantum) to the 3rd-party derive API#40
Open
0c-coder wants to merge 4 commits into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds post-quantum X-Wing (ML-KEM-768 + X25519) to the existing 3rd-party derive API (onlykey-3rd-party.js + index.js) as keytype 6 -- same DERIVE_PUBLIC_KEY / DERIVE_SHARED_SECRET flow as the ECC keytypes. Not age, not PGP; identity is additional_d (SHA-256'd, like the ECC paths), no slots.
Split custody: the MCU can't run ML-KEM, so the device does the X25519 half (sk_X never leaves) and returns a 64-byte reply; the browser does the ML-KEM half from a 32-byte seed. Every device round-trip is <= 64 bytes; the 1088-byte ML-KEM ciphertext never reaches the device. Decryption still requires the physical OnlyKey.
New API on onlykey(6, enc_resp): derive_xwing_public_key -> [pk_X|mlkem_seed], browser builds the 1216-byte recipient; xwing_decapsulate -> only ct_X to the device ([ss_X|mlkem_seed]), browser does ML-KEM decaps + combine (button press); xwing_encapsulate -> host-side.
Files: onlykey-3rd-party.js (X-Wing branch), index.js (keytype enum + deriveXWingExample reference, not auto-run), xwing.js (KEM core), test/xwing-split.test.mjs (npm run test:pqc, 5/5), package.json (@noble deps).
Verified: KEM path round-trips; both edited files pass node --check.
NOTE(firmware): the 64-byte reply layout ([pk_X|seed] / [ss_X|seed] after the 53-byte response header) is the one device-side seam -- confirm against libraries#30. KEM math is unit-tested; only the transport framing needs a hardware check.