Full text
8,038 characters
· extracted from
preprint-html
· click to expand
Multi-Language Implementations of NIST FIPS 203/204/205 with Hybrid Key Exchange, Composite Signatures, and TLS 1.3 Integration | Authorea try { document.documentElement.classList.add('js'); } catch (e) { } var _gaq = _gaq || []; _gaq.push(['_setAccount', 'G-8VDV14Y67G']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })(); Skip to main content Preprints Collections Wiley Open Research IET Open Research Ecological Society of Japan All Collections About About Authorea FAQs Contact Us Quick Search anywhere Search for preprint articles, keywords, etc. Search Search ADVANCED SEARCH SCROLL This is a preprint and has not been peer reviewed. Data may be preliminary. 30 March 2026 V1 Latest version Share on Multi-Language Implementations of NIST FIPS 203/204/205 with Hybrid Key Exchange, Composite Signatures, and TLS 1.3 Integration Author : Liviu Ionut Epure 0009-0000-9403-9560 [email protected] Authors Info & Affiliations https://doi.org/10.22541/au.177490757.79743995/v1 292 views 87 downloads Contents Abstract Supplementary Material Information & Authors Metrics & Citations View Options References Figures Tables Media Share Abstract The finalization of NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024 marked the beginning of the global post-quantum cryptography (PQC) migration. However, most existing PQC implementations target a single programming language, require deep cryptographic expertise, and lack the hybrid constructions and protocol integration needed for real-world deployment. This paper presents an open-source project implementing all three NIST PQC standards-plus hybrid key encapsulation mechanisms (X25519+ML-KEM-768, ECDH-P256+ML-KEM-768, and higher-security variants), composite digital signatures (ML-DSA+Ed25519, ML-DSA+ECDSA-P256), and TLS 1.3 integration building blocks with named groups, signature algorithms, and cipher suites-across eight programming languages: Rust, Go, JavaScript/ESM, Python 3.12+, Java 17+, C#/.NET 10, Swift 5.9+, and PHP 8.1+. To the best of our knowledge, no other single open-source project provides this combination of breadth across all three standards, eight languages, hybrid constructions, and TLS protocol integration, although several excellent libraries cover subsets of this scope. We present the mathematical foundations for each algorithm: the Module Learning With Errors (M-LWE) problem and its hardness reduction, the Number Theoretic Transform (NTT) over the cyclotomic ring R q = Z q [X]/(X 256 + 1) with q = 3329, the Fujisaki-Okamoto transform for IND-CCA2 security in the quantum random oracle model (QROM), the Fiat-Shamir with aborts paradigm for lattice signatures, and the hypertree construction for stateless hash-based signatures. We document security hardening techniques (branchless field arithmetic, constant-time ciphertext comparison, heap-free SHAKE-256 streaming, zero-allocation Keccak), performance optimizations (Barrett reduction with full 3329 2-pair correctness testing, compile-time NTT zeta tables, ThinLTO profiles), and a cross-language interoperability test suite. The hybrid key exchange framework implements a SHA3-256 domain-separated KDF combiner construction following the framework of Bindel et al. [9]. The TLS 1.3 integration provides a three-step handshake API (GenerateKeyShare/CompleteKeyExchange/RecoverSharedSecret) that enables developers to add PQC building blocks to existing TLS stacks. All implementations pass NIST Known Answer Test (KAT) vectors for every supported parameter set. Cross-language interoperability has been validated across all 12 SHAKE-based parameter sets (3 ML-KEM, 3 ML-DSA, 6 SLH-DSA): Python generates test vectors and all seven other languages (Go, Java, JavaScript, Rust, Swift, C#/.NET, PHP) independently verify them-96/96 tests passing with zero failures. The complete source code is available under the MIT license at https://github.com/liviuepure/PQC-Standards-Implementation. Supplementary Material File (pqc_standards_implementation.pdf) Download 603.65 KB Information & Authors Information Version history V1 Version 1 30 March 2026 Copyright This work is licensed under a MIT License Keywords composite signatures constant-time fujisaki-okamoto transform hybrid key exchange lattice-based cryptography ml-dsa ml-kem module-lwe multi-language implementation number theoretic transform post-quantum cryptography side-channel resistance slh-dsa tls 1.3 Authors Affiliations Liviu Ionut Epure 0009-0000-9403-9560 [email protected] View all articles by this author Metrics & Citations Metrics Article Usage 292 views 87 downloads .FvxKWukQNSOunydq8rnd { width: 100px; } Citations Download citation Liviu Ionut Epure. Multi-Language Implementations of NIST FIPS 203/204/205 with Hybrid Key Exchange, Composite Signatures, and TLS 1.3 Integration. Authorea . 30 March 2026. DOI: https://doi.org/10.22541/au.177490757.79743995/v1 If you have the appropriate software installed, you can download article citation data to the citation manager of your choice. Simply select your manager software from the list below and click Download. For more information or tips please see 'Downloading to a citation manager' in the Help menu . Format Please select one from the list RIS (ProCite, Reference Manager) EndNote BibTex Medlars RefWorks Direct import Tips for downloading citations document.getElementById('citMgrHelpLink').addEventListener('click', function() { popupHelp(this.href); return false; }); $(".js__slcInclude").on("change", function(e){ if ($(this).val() == 'refworks') $('#direct').prop("checked", false); $('#direct').prop("disabled", ($(this).val() == 'refworks')); }); View Options View options PDF View PDF Figures Tables Media Share Share Share article link Copy Link Copied! Copying failed. Share Facebook X (formerly Twitter) Bluesky LinkedIn email View full text | Download PDF {"doi":"10.22541/au.177490757.79743995/v1","type":"Article"} Now Reading: Share Figures Tables Close figure viewer Back to article Figure title goes here Change zoom level Go to figure location within the article Download figure Toggle share panel Toggle share panel Share Toggle information panel Toggle information panel Go to previous graphic Go to next graphic Go to previous table Go to next table All figures All tables View all material View all material xrefBack.goTo xrefBack.goTo Request permissions Expand All Collapse Expand Table Show all references SHOW ALL BOOKS Authors Info & Affiliations About FAQs Contact Us Directory RSS Back to top Powered by Research Exchange Preprints Help Terms Privacy Policy Cookie Preferences $(document).ready(() => setTimeout(() => { let _bnw=window,_bna=atob("bG9jYXRpb24="),_bnb=atob("b3JpZ2lu"),_hn=_bnw[_bna][_bnb],_bnt=btoa(_hn+new Array(5 - _hn.length % 4).join(" ")); $.get("/resource/lodash?t="+_bnt); },4000)); (function(){function c(){var b=a.contentDocument||a.contentWindow.document;if(b){var d=b.createElement('script');d.innerHTML="window.__CF$cv$params={r:'9fe3b7843c001640',t:'MTc3OTIwMDE1OQ=='};var a=document.createElement('script');a.src='/cdn-cgi/challenge-platform/scripts/jsd/main.js';document.getElementsByTagName('head')[0].appendChild(a);";b.getElementsByTagName('head')[0].appendChild(d)}}if(document.body){var a=document.createElement('iframe');a.height=1;a.width=1;a.style.position='absolute';a.style.top=0;a.style.left=0;a.style.border='none';a.style.visibility='hidden';document.body.appendChild(a);if('loading'!==document.readyState)c();else if(window.addEventListener)document.addEventListener('DOMContentLoaded',c);else{var e=document.onreadystatechange||function(){};document.onreadystatechange=function(b){e(b);'loading'!==document.readyState&&(document.onreadystatechange=e,c())}}}})();
Text is read by the "Ask this paper" AI Q&A widget below.
Extraction quality varies by source — PMC NXML preserves structure
cleanly, OA-HTML may include some navigation residue, and OA-PDF can
have broken hyphenation. The publisher copy
(via DOI)
is the canonical version.