<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Key-Exchange on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/key-exchange/</link><description>Recent content in Key-Exchange on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/key-exchange/index.xml" rel="self" type="application/rss+xml"/><item><title>Diffie-Hellman (DH / ECDH / X25519)</title><link>https://lesitedefrancois.be/en/security/diffie-hellman/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/diffie-hellman/</guid><description>&lt;p&gt;&lt;strong&gt;Diffie-Hellman (DH)&lt;/strong&gt; is a key exchange protocol published by Whitfield Diffie and Martin Hellman in 1976 — the first public description of asymmetric cryptography and one of the most consequential cryptographic publications in history. Its fundamental contribution is solving the &lt;strong&gt;key establishment problem&lt;/strong&gt;: two parties who have never communicated before, communicating over a channel that an adversary can fully observe, can nonetheless agree on a shared secret that the adversary cannot determine. The security of finite-field DH rests on the &lt;strong&gt;discrete logarithm problem&lt;/strong&gt;: given &lt;code&gt;g^a mod p&lt;/code&gt; and &lt;code&gt;g^b mod p&lt;/code&gt; (the public values exchanged), computing &lt;code&gt;g^ab mod p&lt;/code&gt; (the shared secret) requires solving for either &lt;code&gt;a&lt;/code&gt; or &lt;code&gt;b&lt;/code&gt;, which is computationally infeasible for sufficiently large groups. The 1976 original uses multiplicative groups of integers modulo a prime &lt;code&gt;p&lt;/code&gt;; the security level is determined by the size of &lt;code&gt;p&lt;/code&gt; (currently 2048-bit minimum, 3072-bit recommended) and the group&amp;rsquo;s structure. &lt;strong&gt;Finite-field DH&lt;/strong&gt; is still deployed in TLS 1.2 &lt;code&gt;DHE&lt;/code&gt; cipher suites and legacy IPsec configurations, but has been supplanted in new deployments by &lt;strong&gt;Elliptic Curve Diffie-Hellman (ECDH)&lt;/strong&gt; and specifically by &lt;strong&gt;X25519&lt;/strong&gt;, which provide equivalent security at dramatically smaller key sizes.&lt;/p&gt;</description></item><item><title>ECC (Elliptic Curve Cryptography)</title><link>https://lesitedefrancois.be/en/security/ecc/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/ecc/</guid><description>&lt;p&gt;&lt;strong&gt;Elliptic Curve Cryptography (ECC)&lt;/strong&gt; is a family of public-key cryptographic algorithms built on the mathematics of elliptic curves over finite fields. Its security rests on the &lt;strong&gt;Elliptic Curve Discrete Logarithm Problem (ECDLP)&lt;/strong&gt;: given a public point &lt;code&gt;Q = k × G&lt;/code&gt; on a curve (where &lt;code&gt;G&lt;/code&gt; is a fixed base point and &lt;code&gt;k&lt;/code&gt; is the private key scalar), recovering &lt;code&gt;k&lt;/code&gt; from &lt;code&gt;Q&lt;/code&gt; and &lt;code&gt;G&lt;/code&gt; is computationally infeasible on classical computers. The practical advantage over &lt;strong&gt;RSA&lt;/strong&gt; is dramatic key size efficiency: a 256-bit ECC key provides roughly the same classical security as a 3072-bit RSA key, because the best known classical algorithms for ECDLP (Pollard&amp;rsquo;s rho) are exponential whereas the best RSA algorithms (GNFS) are sub-exponential. This size difference has compounding benefits — smaller keys mean faster operations, smaller certificates, smaller TLS handshake messages, and lower power consumption on constrained devices. ECC is now the dominant choice for all new asymmetric cryptography deployments: TLS 1.3 mandates ECDHE for key exchange, and ECDSA or EdDSA for authentication; SSH defaults to Ed25519; code signing infrastructure increasingly uses ECDSA P-256 or Ed25519.&lt;/p&gt;</description></item><item><title>ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)</title><link>https://lesitedefrancois.be/en/security/ml-kem/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/ml-kem/</guid><description>&lt;p&gt;&lt;strong&gt;ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)&lt;/strong&gt;, standardised as &lt;strong&gt;NIST FIPS 203&lt;/strong&gt; in August 2024, is the primary post-quantum replacement for key encapsulation and key exchange. It replaces the role of &lt;strong&gt;ECDH&lt;/strong&gt; (X25519, P-256) and RSA key transport in &lt;strong&gt;TLS&lt;/strong&gt; handshakes, &lt;strong&gt;IPsec&lt;/strong&gt; IKEv2 negotiations, and any other protocol that needs two parties to establish a shared secret without prior key material. ML-KEM is derived from CRYSTALS-Kyber, the submission that won NIST&amp;rsquo;s lattice-based KEM selection, and its security rests on the &lt;strong&gt;Module Learning With Errors (MLWE)&lt;/strong&gt; problem: distinguishing a structured noisy linear system from a random one is computationally hard, and no efficient quantum algorithm for this problem is known. The &amp;ldquo;module&amp;rdquo; qualifier means the construction uses polynomial rings structured in a way that allows a good balance between security and efficiency, contrasting with pure LWE (larger keys, simpler structure) and NTRU (smaller keys, different structure).&lt;/p&gt;</description></item><item><title>RSA (Rivest–Shamir–Adleman)</title><link>https://lesitedefrancois.be/en/security/rsa/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/rsa/</guid><description>&lt;p&gt;&lt;strong&gt;RSA (Rivest–Shamir–Adleman)&lt;/strong&gt;, published in 1977, was the first widely adopted public-key cryptosystem and for decades the most deployed asymmetric algorithm in existence. Its security rests on the &lt;strong&gt;integer factorisation problem&lt;/strong&gt;: given a public modulus &lt;code&gt;n = p × q&lt;/code&gt; (the product of two large primes), recovering &lt;code&gt;p&lt;/code&gt; and &lt;code&gt;q&lt;/code&gt; is computationally infeasible on classical computers for sufficiently large &lt;code&gt;n&lt;/code&gt;. The public key is the pair &lt;code&gt;(n, e)&lt;/code&gt; and the private key is &lt;code&gt;(n, d)&lt;/code&gt;, where &lt;code&gt;e&lt;/code&gt; and &lt;code&gt;d&lt;/code&gt; are related by the modular arithmetic of Euler&amp;rsquo;s totient function. RSA enables two operations: &lt;strong&gt;encryption&lt;/strong&gt; (the sender uses the public key to encrypt a message that only the private key holder can decrypt) and &lt;strong&gt;signing&lt;/strong&gt; (the private key holder produces a signature that anyone with the public key can verify). In practice, RSA encryption is used almost exclusively for &lt;strong&gt;key encapsulation&lt;/strong&gt; — encrypting a randomly generated symmetric key — rather than encrypting arbitrary data directly, both because RSA is slow and because direct RSA encryption of large messages requires padding schemes that are historically error-prone.&lt;/p&gt;</description></item></channel></rss>