<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Primitives on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/primitives/</link><description>Recent content in Primitives 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/primitives/index.xml" rel="self" type="application/rss+xml"/><item><title>AES (Advanced Encryption Standard)</title><link>https://lesitedefrancois.be/en/security/aes/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/aes/</guid><description>&lt;p&gt;&lt;strong&gt;AES (Advanced Encryption Standard)&lt;/strong&gt;, standardised as NIST FIPS 197 in 2001, is the symmetric block cipher that underlies virtually all data encryption in modern infrastructure. It was selected through a five-year open competition that evaluated 15 candidate algorithms; the winner, &lt;strong&gt;Rijndael&lt;/strong&gt; (designed by Joan Daemen and Vincent Rijmen), became AES. A block cipher takes a fixed-size block of plaintext and a key and produces a fixed-size block of ciphertext — AES always operates on &lt;strong&gt;128-bit (16-byte) blocks&lt;/strong&gt;, regardless of key size. Three key lengths are standardised: &lt;strong&gt;AES-128&lt;/strong&gt; (128-bit key, 10 rounds), &lt;strong&gt;AES-192&lt;/strong&gt; (192-bit key, 12 rounds), and &lt;strong&gt;AES-256&lt;/strong&gt; (256-bit key, 14 rounds), providing 128, 192, and 256 bits of security respectively against classical attacks. AES-256 is the conservative choice for data with long confidentiality requirements and is mandated by CNSA 2.0 for national security systems; AES-128 is widely deployed in TLS and provides adequate security for most workloads. The internal structure — SubBytes, ShiftRows, MixColumns, AddRoundKey — is fully public and has withstood over two decades of cryptanalysis; the best known attacks against full-round AES are theoretical and computationally infeasible, requiring work far beyond brute force but not threatening practical security.&lt;/p&gt;</description></item><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>Hash Function (Cryptographic Hash Function)</title><link>https://lesitedefrancois.be/en/security/hash/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/hash/</guid><description>&lt;p&gt;A &lt;strong&gt;cryptographic hash function&lt;/strong&gt; maps an input of arbitrary length (a file, a certificate, a password, a block of network data) to a fixed-length &lt;strong&gt;digest&lt;/strong&gt; (also called a hash or fingerprint) with three security properties that distinguish it from non-cryptographic checksums. &lt;strong&gt;Preimage resistance&lt;/strong&gt;: given a digest &lt;code&gt;h&lt;/code&gt;, it is computationally infeasible to find any input &lt;code&gt;m&lt;/code&gt; such that &lt;code&gt;H(m) = h&lt;/code&gt;. &lt;strong&gt;Second preimage resistance&lt;/strong&gt;: given an input &lt;code&gt;m1&lt;/code&gt;, it is computationally infeasible to find a different input &lt;code&gt;m2&lt;/code&gt; such that &lt;code&gt;H(m1) = H(m2)&lt;/code&gt;. &lt;strong&gt;Collision resistance&lt;/strong&gt;: it is computationally infeasible to find any pair &lt;code&gt;(m1, m2)&lt;/code&gt; with &lt;code&gt;m1 ≠ m2&lt;/code&gt; such that &lt;code&gt;H(m1) = H(m2)&lt;/code&gt;. Collision resistance is the strongest property and implies second preimage resistance but not preimage resistance. These properties together make a hash function a one-way, tamper-evident fingerprint: two inputs that produce the same digest cannot be found by an adversary, and knowing the digest reveals nothing about the input beyond its length.&lt;/p&gt;</description></item><item><title>HMAC (Hash-based Message Authentication Code)</title><link>https://lesitedefrancois.be/en/security/hmac/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/hmac/</guid><description>&lt;p&gt;&lt;strong&gt;HMAC (Hash-based Message Authentication Code)&lt;/strong&gt;, standardised in RFC 2104 (1997) and FIPS 198-1, is a construction that produces a &lt;strong&gt;Message Authentication Code (MAC)&lt;/strong&gt; by combining a cryptographic hash function with a shared secret key. A plain &lt;strong&gt;hash function&lt;/strong&gt; provides integrity — any modification to a message changes its digest — but anyone can recompute the digest of a modified message, so a hash alone cannot prove that a message came from a specific party who holds a secret. HMAC adds authenticity: only a party who knows the key &lt;code&gt;K&lt;/code&gt; can produce a valid &lt;code&gt;HMAC(K, message)&lt;/code&gt;, and only a party who knows &lt;code&gt;K&lt;/code&gt; can verify it. The construction is &lt;code&gt;HMAC(K, m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m))&lt;/code&gt; — two rounds of hashing with the key XOR&amp;rsquo;d against inner and outer padding constants — a design chosen to be provably secure against length-extension attacks that affect naive &lt;code&gt;H(K ∥ m)&lt;/code&gt; constructions with Merkle-Damgård hash functions like SHA-256. HMAC is proven secure as long as the underlying hash function is a pseudorandom function, a weaker requirement than collision resistance, meaning HMAC-SHA-256 remains secure even in scenarios where SHA-256 collision resistance might be weakened.&lt;/p&gt;</description></item><item><title>SHA (Secure Hash Algorithm)</title><link>https://lesitedefrancois.be/en/security/sha/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/sha/</guid><description>&lt;p&gt;&lt;strong&gt;SHA (Secure Hash Algorithm)&lt;/strong&gt; is the name given to a series of cryptographic hash function families standardised by NIST under FIPS 180 and FIPS 202. Three generations exist with fundamentally different design lineages. &lt;strong&gt;SHA-1&lt;/strong&gt; (1995, FIPS 180-1) produces a 160-bit digest and is &lt;strong&gt;fully broken for collision resistance&lt;/strong&gt;: the SHAttered attack (Google and CWI Amsterdam, 2017) produced a chosen-prefix collision — two different PDF files with identical SHA-1 hashes — using approximately 9.2 × 10^18 SHA-1 operations, within practical reach of well-resourced attackers. SHA-1 must not be used for any security purpose; it persists only in legacy Git object identifiers (SHA-1 is being phased out in Git&amp;rsquo;s object store in favour of SHA-256 under the &lt;code&gt;sha256&lt;/code&gt; object format) and in TOTP&amp;rsquo;s HMAC-SHA-1 inner construction (where collision resistance is not the relevant security property, but migration to SHA-256 variants is still recommended). &lt;strong&gt;SHA-2&lt;/strong&gt; (2001, FIPS 180-2 and subsequent revisions) is the Merkle-Damgård family that includes SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. SHA-256 and SHA-512 are the two variants in universal production use; the others serve niche roles. &lt;strong&gt;SHA-3&lt;/strong&gt; (2015, FIPS 202) is the Keccak sponge construction — structurally independent of SHA-2 — providing algorithm diversity and including fixed-output variants (SHA3-256, SHA3-512) and extendable output functions (SHAKE128, SHAKE256).&lt;/p&gt;</description></item></channel></rss>