Chiffrement symétrique Symmetric encryption

Pourquoi AES-256-GCM ?

Why AES-256-GCM?

Fialka

🔒 AES-256-GCM

✓AEAD — Chiffrement + authentification en un seul passage (Encrypt-then-MAC intégré)AEAD — Encryption + authentication in one pass (built-in Encrypt-then-MAC)

✓256 bits de clé — 2²⁵⁶ combinaisons, inviolable même par les ordinateurs quantiques (Grover → 2¹²⁸)256-bit key — 2²⁵⁶ combinations, unbreakable even by quantum computers (Grover → 2¹²⁸)

✓AES-NI — Accéléré par le matériel sur la plupart des processeurs modernesAES-NI — Hardware-accelerated on most modern processors

✓Standard NIST — Approuvé FIPS 197, audité depuis 20+ ans, aucune attaque pratique connueNIST standard — FIPS 197 approved, audited for 20+ years, no known practical attack

C, Tag = AES-256-GCM(Key₂₅₆, Nonce₉₆, Plaintext, AAD)

256

bits de clé

key bits

~4 GB/s

débit (AES-NI)

throughput (AES-NI)

128

bits de tag

tag bits

🐌 RSA-2048/4096 Pas adapté Not suitable

✗Asymétrique — RSA chiffre des données, pas des messages. Limité à ~245 octets avec RSA-2048Asymmetric — RSA encrypts data, not messages. Limited to ~245 bytes with RSA-2048

✗1000× plus lent que AES pour le chiffrement bulk1000× slower than AES for bulk encryption

✗Vulnérable quantique — Algorithme de Shor casse RSA en temps polynomialQuantum vulnerable — Shor's algorithm breaks RSA in polynomial time

✗Pas d'authentification — nécessite un MAC séparé (pas AEAD)No authentication — needs separate MAC (not AEAD)

😐 AES-256-CBC Inférieur Inferior

△Pas AEAD — Vulnérable aux attaques padding oracle sans MAC externeNot AEAD — Vulnerable to padding oracle attacks without external MAC

△Séquentiel — Impossible de paralléliser le chiffrement (contrairement à GCM/CTR)Sequential — Cannot parallelize encryption (unlike GCM/CTR)

Chiffrement adaptatif · Nouveau en V3.5 Adaptive cipher · New in V3.5

Pourquoi ChaCha20-Poly1305 en alternative ?

Why ChaCha20-Poly1305 as alternative?

Sélection automatique du chiffrement

Automatic cipher selection

Fialka détecte au runtime si le processeur supporte AES-NI (accélération matérielle AES). Si oui → AES-256-GCM. Sinon → ChaCha20-Poly1305, qui est 3× plus rapide en software pur.

Fialka detects at runtime whether the CPU supports AES-NI (hardware AES acceleration). If yes → AES-256-GCM. If no → ChaCha20-Poly1305, which is 3× faster in pure software.

if CPU has AES-NI → AES-256-GCM

else no AES hardware → ChaCha20-Poly1305

AES-256-GCM avec AES-NI with AES-NI

~4 GB/s

ChaCha20-Poly1305 sans AES-NI without AES-NI

~1.5 GB/s (software)

AES-256-GCM sans AES-NI without AES-NI

~0.5 GB/s ⚠️

⚡ ChaCha20-Poly1305

✓Conçu par djb (Daniel J. Bernstein) — audité, adopté par TLS 1.3, WireGuard, GoogleDesigned by djb (Daniel J. Bernstein) — audited, adopted by TLS 1.3, WireGuard, Google

✓AEAD identique à GCM — chiffrement + authentification en un passageAEAD just like GCM — encryption + authentication in one pass

✓Pas de timing attacks — Opérations en temps constant, pas de table lookupsNo timing attacks — Constant-time operations, no table lookups

✓Idéal sur ARM — La majorité des smartphones n'ont pas d'AES-NIIdeal on ARM — Most smartphones lack AES-NI

🔐Les deux sont AEADBoth are AEAD

AES-256-GCM et ChaCha20-Poly1305 fournissent tous les deux le chiffrement authentifié (AEAD). Ils intègrent nativement un MAC (Encrypt-then-MAC) :

Both AES-256-GCM and ChaCha20-Poly1305 provide authenticated encryption (AEAD). They natively include a MAC (Encrypt-then-MAC):

AES-GCM: GHASH → Tag₁₂₈

ChaCha20: Poly1305 → Tag₁₂₈

En plus, Ed25519 ajoute une deuxième couche d'intégrité indépendante : signature sur ct ‖ convId ‖ ts.

Additionally, Ed25519 adds a second independent integrity layer: signature over ct ‖ convId ‖ ts.

Échange de clés Diffie-Hellman Diffie-Hellman key exchange

Pourquoi X25519 ?

Why X25519?

Critère	Criteria	X25519	P-256 (NIST)	RSA-2048 DH
Taille de clé publique	Public key size	32 bytes	64 bytes	256 bytes
Sécurité (bits)	Security (bits)	~128 bits	~128 bits	~112 bits
Vitesse ECDH	ECDH speed	~0.15 ms	~0.30 ms	~2.5 ms
Temps constant	Constant time	✓	◐	✗
Résistant au quantum	Quantum resistant	✗ *	✗	✗
Backdoor risk	Backdoor risk	Aucun (djb)	None (djb)	Débattu (Dual EC)	Debated (Dual EC)	Aucun	None

💡

* X25519 seul n'est pas post-quantique, c'est pourquoi Fialka utilise PQXDH : X25519 + ML-KEM-1024. La sécurité classique de X25519 est complétée par la résistance quantique de ML-KEM.

* X25519 alone is not post-quantum, which is why Fialka uses PQXDH: X25519 + ML-KEM-1024. X25519's classical security is complemented by ML-KEM's quantum resistance.

Curve25519

Courbe de Montgomery a = 486662, champ premier p = 2²⁵⁵ − 19. Conçue par Daniel J. Bernstein pour être immune aux timing attacks par design. Utilisée par Signal, WireGuard, SSH, Tor.

Montgomery curve a = 486662, prime field p = 2²⁵⁵ − 19. Designed by Daniel J. Bernstein to be immune to timing attacks by design. Used by Signal, WireGuard, SSH, Tor.

P-256 (secp256r1)

Courbe Short Weierstrass NIST. Performante mais paramètres "inexpliqués" — des chercheurs soupçonnent un choix non aléatoire (similaire à Dual_EC_DRBG). Implémentations souvent non constant-time.

NIST Short Weierstrass curve. Performant but "unexplained" parameters — researchers suspect non-random choice (similar to Dual_EC_DRBG). Implementations often not constant-time.

RSA-2048

Diffie-Hellman classique sur corps premier. Clés énormes (256+ bytes), lent, pas de PFS sauf avec des éphémères explicites. Vulnérable au quantum (Shor).

Classical prime-field Diffie-Hellman. Huge keys (256+ bytes), slow, no PFS unless using explicit ephemerals. Quantum vulnerable (Shor).

Résistance post-quantique Post-quantum resistance

Pourquoi ML-KEM-1024 ?

Why ML-KEM-1024?

🛡️

ML-KEM-1024 (Kyber)

NIST FIPS 203 — Fialka

✓Standard NIST — Premier standard PQ officiel (août 2024), basé sur la dureté du problème MLWE (Module Learning With Errors)NIST standard — First official PQ standard (August 2024), based on MLWE (Module Learning With Errors) hardness

✓Niveau 5 — Sécurité ≥ AES-256, le plus haut niveau de sécurité NISTLevel 5 — Security ≥ AES-256, the highest NIST security level

✓Rapide — Encapsulation ~0.1ms, Décapsulation ~0.1msFast — Encapsulation ~0.1ms, Decapsulation ~0.1ms

✓Compact — Clé publique 1568 bytes, ciphertext 1568 bytesCompact — Public key 1568 bytes, ciphertext 1568 bytes

Pourquoi ML-KEM-1024 et pas 768 ?

Why ML-KEM-1024 and not 768?

ML-KEM-768 offre un niveau de sécurité 3 (≈ AES-192). Nous avons choisi ML-KEM-1024 (niveau 5 ≈ AES-256) pour une marge de sécurité maximale. Le surcoût est minimal (+0.05ms, +500 bytes).

ML-KEM-768 offers security level 3 (≈ AES-192). We chose ML-KEM-1024 (level 5 ≈ AES-256) for maximum security margin. The overhead is minimal (+0.05ms, +500 bytes).

🔷 NTRU Alternatif Alternative

△Historiquement le premier KEM lattice-based. Non sélectionné par le NIST comme standard principalHistorically the first lattice-based KEM. Not selected by NIST as primary standard

△Brevets (expirés mais complexité juridique) et implémentations moins auditéesPatents (expired but legal complexity) and less audited implementations

🟢 McEliece Clés énormes Huge keys

△Sécurité prouvée depuis 1978 (code-based). Mais clé publique = 261 KB (vs 1.5 KB pour ML-KEM)Proven security since 1978 (code-based). But public key = 261 KB (vs 1.5 KB for ML-KEM)

△Impraticable sur mobile — QR code, échange réseau, stockageImpractical on mobile — QR code, network exchange, storage

🔴 SIKE/SIDH Cassé Broken

✗Était candidat NIST. Cassé en 2022 par Castryck-Decru attack (sur un laptop en 1 heure). Abandonné.Was a NIST candidate. Broken in 2022 by Castryck-Decru attack (on a laptop in 1 hour). Abandoned.

Signatures numériques Digital signatures

Pourquoi Ed25519 ?

Why Ed25519?

Critère	Criteria	Ed25519	ECDSA (P-256)	RSA-2048
Signature	Signature size	64 bytes	64 bytes	256 bytes
Clé publique	Public key	32 bytes	64 bytes	256 bytes
Vitesse signature	Sign speed	~0.05 ms	~0.15 ms	~1.5 ms
Déterministe	Deterministic	✓	✗ *	✓
Temps constant	Constant time	✓	◐	✗
Risque nonce	Nonce risk	Aucun	None	Critique !	Critical!	Aucun	None

⚠️

* ECDSA a un problème critique : si le nonce aléatoire est réutilisé ou biaisé, la clé privée est récupérable. C'est exactement ce qui a permis de pirater la PS3 en 2010. Ed25519 élimine ce risque car il est déterministe (le nonce est dérivé du message).

* ECDSA has a critical issue: if the random nonce is reused or biased, the private key becomes recoverable. This is exactly how the PS3 was hacked in 2010. Ed25519 eliminates this risk because it's deterministic (the nonce is derived from the message).

Renouvellement des clés Key renewal

Pourquoi le Double Ratchet ?

Why the Double Ratchet?

🔄Double Ratchet (Signal Protocol)Double Ratchet (Signal Protocol) Fialka

✓PFS (Perfect Forward Secrecy) — La compromission d'une clé ne révèle pas les messages passésPFS (Perfect Forward Secrecy) — Compromising one key doesn't reveal past messages

✓Self-healing — Après compromission, la sécurité se rétablit automatiquement au prochain DH ratchetSelf-healing — After compromise, security auto-restores at the next DH ratchet

✓Clé unique par message — Chaque message utilise une clé différente dérivée via HKDFUnique key per message — Every message uses a different key derived via HKDF

✓Asynchrone — Fonctionne même si le destinataire est hors ligne (prekeys)Asynchronous — Works even when recipient is offline (prekeys)

Deux ratchets imbriqués :

Two nested ratchets:

1. DH Ratchet (X25519)

→ new RootKey = HKDF(RK, DH(a,B))

2. KDF Chain Ratchet

→ MK₁ = HMAC(CK₁)

→ CK₂ = HMAC(CK₁)

→ MK₂ = HMAC(CK₂) …

✗ Clé statique Static key

WhatsApp avant 2016, Telegram (chats non-secrets). Une seule clé partagée. Si compromise → tous les messages passés ET futurs sont lisibles.

WhatsApp pre-2016, Telegram (non-secret chats). Single shared key. If compromised → all past AND future messages are readable.

△ OTR (Off-the-Record) OTR (Off-the-Record)

Précurseur du Double Ratchet. PFS mais pas de messages asynchrones — les deux parties doivent être en ligne simultanément.

Double Ratchet predecessor. PFS but no async messages — both parties must be online simultaneously.

△ MTProto 2.0

Telegram. Protocole propriétaire, pas de forward secrecy par défaut, E2E uniquement en "secret chat". Des chercheurs ont trouvé des faiblesses cryptographiques.

Telegram. Proprietary protocol, no forward secrecy by default, E2E only in "secret chat". Researchers have found cryptographic weaknesses.

Nouveau en V3.5 New in V3.5

SPQR — Le Triple Ratchet post-quantique

SPQR — The post-quantum Triple Ratchet

Le problème

The problem

Le Double Ratchet classique renouvelle les clés via X25519 uniquement. ML-KEM-1024 n'est utilisé que dans le handshake initial PQXDH. Si un ordinateur quantique casse X25519 après le handshake, les ratchets DH suivants ne bénéficient plus de protection post-quantique.

The classic Double Ratchet renews keys via X25519 only. ML-KEM-1024 is only used in the initial PQXDH handshake. If a quantum computer breaks X25519 after the handshake, subsequent DH ratchets no longer benefit from post-quantum protection.

La solution SPQR

The SPQR solution

Tous les 10 messages, Fialka effectue un nouvel échange ML-KEM-1024 (encapsulation + décapsulation) et mélange le secret partagé post-quantique dans la rootKey via HKDF. C'est le PQ Ratchet — un troisième ratchet, indépendant des deux autres.

Every 10 messages, Fialka performs a new ML-KEM-1024 exchange (encapsulation + decapsulation) and mixes the post-quantum shared secret into the rootKey via HKDF. This is the PQ Ratchet — a third ratchet, independent of the other two.

SPQR — Triple Ratchet

msg₁₋₉ → Double Ratchet classique (X25519 + KDF Chain)

msg₁₀ → SPQR Trigger!

ct = ML-KEM.Encaps(pk_partner) → (ss, ct)

newRK = HKDF(currentRK ‖ ss, info="Fialka-SPQR-pq-ratchet")

pqRatchetCounter = 0

msg₁₁₋₁₉ → Double Ratchet avec la nouvelle rootKey PQ

msg₂₀ → SPQR Trigger! → nouvel échange ML-KEM ...

... ∞

🛡️ Protection PQ continue, pas seulement au handshake 🛡️ Continuous PQ protection, not just at handshake

Dérivation de clés Key derivation

Pourquoi HKDF-SHA256 ?

Why HKDF-SHA256?

🧪

HKDF

RFC 5869

✓Extract-Expand — Deux phases : extrait l'entropie puis dérive N clésExtract-Expand — Two phases: extracts entropy then derives N keys

✓Prouvé sûr — Sécurité formelle prouvée sous le modèle PRFProven secure — Formal security proof under PRF model

✓Standard — Utilisé par TLS 1.3, Signal, WireGuardStandard — Used by TLS 1.3, Signal, WireGuard

PRK = HMAC-SHA256(salt, IKM)

OKM = HMAC-SHA256(PRK, info ‖ 0x01)

Où HKDF est utilisé dans Fialka

Where HKDF is used in Fialka

PQXDHSK = HKDF(DH₁‖DH₂‖DH₃‖DH₄‖ML-KEM.ss)

DH RatchetnewRK, CK = HKDF(RK, DH(a,B))

KDF ChainCKₙ₊₁, MK = HMAC-SHA256(CKₙ)

SPQRnewRK = HKDF(RK ‖ ss, "Fialka-SPQR-pq-ratchet")

PBKDF2

Conçu pour deriver des clés à partir de mots de passe (lent volontairement). Pas adapté pour dérivation rapide type ratchet.

Designed to derive keys from passwords (intentionally slow). Not suited for fast ratchet-style derivation.

→ Fialka utilise PBKDF2 uniquement pour le PIN (600K itérations)

→ Fialka uses PBKDF2 only for PIN (600K iterations)

Argon2

Memory-hard KDF, meilleur que PBKDF2 pour les mots de passe. Mais trop lent et memory-intensive pour un ratchet par message.

Memory-hard KDF, better than PBKDF2 for passwords. But too slow and memory-intensive for per-message ratcheting.

Menaces & résistance Threats & resistance

Résistance aux attaques quantiques

Resistance to quantum attacks

Un ordinateur quantique suffisamment puissant disposera de deux armes principales. Voici comment Fialka se défend contre chacune.

A sufficiently powerful quantum computer will have two main weapons. Here's how Fialka defends against each.

💀

Algorithme de Shor

Shor's Algorithm

MENACE CRITIQUE — casse la crypto asymétrique CRITICAL THREAT — breaks asymmetric crypto

L'algorithme de Peter Shor (1994) résout la factorisation des grands nombres et le logarithme discret en temps polynomial sur un ordinateur quantique.

Peter Shor's algorithm (1994) solves large integer factorization and discrete logarithm in polynomial time on a quantum computer.

Concrètement, il détruit tous les systèmes basés sur :

Concretely, it destroys all systems based on:

✗RSA — factorisation de n = p × qfactoring n = p × q

✗ECDSA / ECDH (P-256) — logarithme discret sur courbesdiscrete log on curves

✗X25519 / Ed25519 — même problème (courbes elliptiques)same problem (elliptic curves)

✗DSA / DHE classique — logarithme discret sur corps finidiscrete log on finite fields

⚠️ Complexité classique RSA-2048 : O(e^(n^(1/3))) ≈ 2¹¹² opérations

⚠️ Classical RSA-2048 complexity: O(e^(n^(1/3))) ≈ 2¹¹² operations

💀 Complexité quantique (Shor) : O(n³) ≈ quelques heures

💀 Quantum complexity (Shor): O(n³) ≈ a few hours

🛡️

Défense Fialka vs Shor

Fialka defense vs Shor

🔑 Échange de clés — PROTÉGÉ

🔑 Key exchange — PROTECTED

PQXDH = X25519 + ML-KEM-1024. ML-KEM est basé sur le problème MLWE (Module Learning With Errors), résistant à Shor. Même si X25519 tombe, ML-KEM tient.

PQXDH = X25519 + ML-KEM-1024. ML-KEM is based on MLWE (Module Learning With Errors), resistant to Shor. Even if X25519 falls, ML-KEM holds.

🔄 Ratchet continu — PROTÉGÉ

🔄 Continuous ratchet — PROTECTED

SPQR ré-encapsule ML-KEM tous les 10 messages. La protection PQ ne s'arrête pas au handshake — elle est continue.

SPQR re-encapsulates ML-KEM every 10 messages. PQ protection doesn't stop at handshake — it's continuous.

✍️ Signatures — EN COURS (V3.6+)

✍️ Signatures — IN PROGRESS (V3.6+)

Ed25519 est vulnérable à Shor, mais un attaquant devrait forger une signature en temps réel — pas rétroactif. Migration vers Ed25519 + ML-DSA-44 hybride prévue en V3.6.

Ed25519 is vulnerable to Shor, but an attacker would need to forge a signature in real-time — not retroactive. Migration to hybrid Ed25519 + ML-DSA-44 planned for V3.6.

🔍

Algorithme de Grover

Grover's Algorithm

MENACE MODÉRÉE — divise la sécurité symétrique par 2 MODERATE THREAT — halves symmetric security

L'algorithme de Lov Grover (1996) accélère la recherche brute-force. Il trouve une clé dans un espace de taille N en √N opérations au lieu de N.

Lov Grover's algorithm (1996) accelerates brute-force search. It finds a key in a space of size N in √N operations instead of N.

Concrètement, la sécurité de chaque clé symétrique est divisée par deux :

Concretely, every symmetric key's security is halved:

AES-256 → 256 bits → 128 bits ✓ Safe

ChaCha20 → 256 bits → 128 bits ✓ Safe

HKDF-SHA256 → 256 bits → 128 bits ✓ Safe

ML-KEM-1024 → 256 bits → ~128 bits ✓ Safe

AES-128 ⚠️ → 128 bits → 64 bits ✗ Cassable ✗ Breakable

🔍 Brute-force classique AES-256 : 2²⁵⁶ opérations (impossible)

🔍 Classical brute-force AES-256: 2²⁵⁶ operations (impossible)

⚛️ Grover sur AES-256 : 2¹²⁸ opérations (toujours impossible)

⚛️ Grover on AES-256: 2¹²⁸ operations (still impossible)

✅

Défense Fialka vs Grover

Fialka defense vs Grover

Grover n'est pas un problème pour Fialka. Toute la pile symétrique utilise des clés de 256 bits. Même divisée par 2 → 128 bits restants = astronomiquement sûr.

Grover is not a problem for Fialka. The entire symmetric stack uses 256-bit keys. Even halved → 128 bits remaining = astronomically safe.

Pour mettre en perspective 2¹²⁸ :

To put 2¹²⁸ in perspective:

•Si chaque atome de l'univers (≈ 10⁸⁰) était un ordinateur quantique...If every atom in the universe (≈ 10⁸⁰) were a quantum computer...

•Chacun testant 1 milliard de clés/seconde...Each testing 1 billion keys/second...

•Il faudrait ~10⁸ ans pour épuiser 2¹²⁸ — plus vieux que l'univers lui-même.It would take ~10⁸ years to exhaust 2¹²⁸ — older than the universe itself.

C'est précisément pourquoi AES-256 (et non AES-128) a été choisi. La marge de sécurité post-Grover est identique à la sécurité pré-quantique d'AES-128, qui est elle-même considérée incassable.

This is precisely why AES-256 (not AES-128) was chosen. The post-Grover security margin is identical to AES-128's pre-quantum security, which is itself considered unbreakable.

📡

Harvest Now, Decrypt Later

HNDL

Des adversaires (états, agences) interceptent et stockent le trafic chiffré aujourd'hui, en attendant qu'un ordinateur quantique puisse le déchiffrer dans 10-20 ans.

Adversaries (states, agencies) intercept and store encrypted traffic today, waiting for a quantum computer to decrypt it in 10-20 years.

Défense Fialka : PQXDH + SPQR. Le chiffrement est post-quantique dès maintenant. Même capturé, le trafic reste indéchiffrable dans le futur.

Fialka defense: PQXDH + SPQR. Encryption is post-quantum right now. Even if captured, traffic remains undecryptable in the future.

⚡

Attaques par canal auxiliaire

Side-channel attacks

Timing / Power / Cache

Mesurer le temps d'exécution, la consommation électrique, ou les cache-miss pour déduire la clé sans casser l'algorithme.

Measuring execution time, power consumption, or cache misses to deduce the key without breaking the algorithm.

Défense : X25519 et Ed25519 sont constant-time par design. ChaCha20 n'utilise aucune table lookup. AES-GCM bénéficie d'AES-NI (hardware, pas de cache-timing).

Defense: X25519 and Ed25519 are constant-time by design. ChaCha20 uses no table lookups. AES-GCM benefits from AES-NI (hardware, no cache-timing).

🎯

Autres menaces connues

Other known threats

✓Replay attack — Contré par nonce unique + timestamp + convId dans la signature Ed25519Replay attack — Countered by unique nonce + timestamp + convId in Ed25519 signature

✓MitM — Contré par PQXDH avec vérification d'identité Ed25519 + safety numberMitM — Countered by PQXDH with Ed25519 identity verification + safety number

✓Birthday attack — SHA-256 a 128 bits de résistance aux collisions → suffisantBirthday attack — SHA-256 has 128-bit collision resistance → sufficient

✓Padding oracle — Impossible avec GCM/Poly1305 (AEAD, pas de padding type CBC)Padding oracle — Impossible with GCM/Poly1305 (AEAD, no CBC-style padding)

✓Nonce reuse — Ed25519 est déterministe. AES-GCM utilise un nonce incrémenté par le ratchet (jamais réutilisé)Nonce reuse — Ed25519 is deterministic. AES-GCM uses a ratchet-incremented nonce (never reused)

Matrice de résistance complète

Complete resistance matrix

Composant	Component	Shor	Grover	HNDL	Side-channel	Side-channel	Sécurité post-Q	Post-Q security
AES-256-GCM	N/A	128 bits ✓	✓	AES-NI ✓	✅
ChaCha20-Poly1305	N/A	128 bits ✓	✓	Constant-time ✓	Constant-time ✓	✅
X25519	❌ Cassé	❌ Broken	N/A	+ML-KEM ✓	+ML-KEM ✓	CT ✓	✅ via PQXDH	✅ via PQXDH
ML-KEM-1024	✓ MLWE	~128 bits ✓	✓	✓	✅
Ed25519	❌ Cassé	❌ Broken	N/A	N/A	CT ✓	🟡 V3.6	🟡 V3.6
HKDF-SHA256	N/A	128 bits ✓	✓	HMAC ✓	✅
SPQR (Triple Ratchet)	✓ Continu	✓ Continuous	✓	✓	✓	✅

Roadmap post-quantique de Fialka

Fialka post-quantum roadmap

✓

V3.5 Fait Done

Chiffrement PQ complet — PQXDH (X25519 + ML-KEM-1024), SPQR Triple Ratchet, ChaCha20 adaptatif. Résistant à Shor + Grover + HNDL sur le chiffrement.

Complete PQ encryption — PQXDH (X25519 + ML-KEM-1024), SPQR Triple Ratchet, adaptive ChaCha20. Resistant to Shor + Grover + HNDL on encryption.

→

V3.6 – V3.7 Prévu Planned

Signatures hybrides — Ed25519 + ML-DSA-44 (Dilithium) sur le handshake PQXDH. Les signatures deviennent résistantes à Shor. Taille : +2420 bytes par signature hybride.

Hybrid signatures — Ed25519 + ML-DSA-44 (Dilithium) on PQXDH handshake. Signatures become Shor-resistant. Size: +2420 bytes per hybrid signature.

∞

V4.0 Recherche Research

Full PQ sur tout — Signatures hybrides sur chaque message ratcheté. Migration possible vers FN-DSA (Falcon-512, 666 bytes) si les libs Android mûrissent. 100% résistant quantique de bout en bout.

Full PQ everywhere — Hybrid signatures on every ratcheted message. Possible migration to FN-DSA (Falcon-512, 666 bytes) if Android libs mature. 100% quantum-resistant end-to-end.

La pile complète

The complete stack

Échange de clés Key exchange PQXDH = X25519 + ML-KEM-1024 (FIPS 203)

Renouvellement Key renewal Double Ratchet + SPQR = DH + KDF + PQ ratchet tous les 10 msgs = DH + KDF + PQ ratchet every 10 msgs

Chiffrement Encryption AES-256-GCM / ChaCha20-Poly1305 AEAD, sélection auto hardware AEAD, auto hardware selection

Signatures Ed25519 sur ct ‖ convId ‖ timestamp over ct ‖ convId ‖ timestamp

Dérivation de clés Key derivation HKDF-SHA256 RFC 5869

Stockage local Local storage SQLCipher (AES-256) + EncryptedSharedPreferences + EncryptedSharedPreferences

Backup clé Key backup BIP-39 24 mots = 256 bits + checksum SHA-256 24 words = 256 bits + SHA-256 checksum

PIN PBKDF2-HMAC-SHA256 600 000 itérations 600,000 iterations

Transport Transport Tor (VPN TUN → SOCKS5) 3 relais (Guard, Middle, Exit) 3 relays (Guard, Middle, Exit)

Cryptographie comparée Comparative Cryptography

La pile cryptographique

The cryptographic stack

Pourquoi AES-256-GCM ?

Why AES-256-GCM?

🔒 AES-256-GCM

🐌 RSA-2048/4096 Pas adapté Not suitable

😐 AES-256-CBC Inférieur Inferior

Pourquoi ChaCha20-Poly1305 en alternative ?

Why ChaCha20-Poly1305 as alternative?

Sélection automatique du chiffrement

Automatic cipher selection

⚡ ChaCha20-Poly1305

🔐Les deux sont AEADBoth are AEAD

Pourquoi X25519 ?

Why X25519?

Curve25519

P-256 (secp256r1)

RSA-2048

Pourquoi ML-KEM-1024 ?

Why ML-KEM-1024?

ML-KEM-1024 (Kyber)

Pourquoi ML-KEM-1024 et pas 768 ?

Why ML-KEM-1024 and not 768?

🔷 NTRU Alternatif Alternative

🟢 McEliece Clés énormes Huge keys

🔴 SIKE/SIDH Cassé Broken

Pourquoi Ed25519 ?

Why Ed25519?

Pourquoi le Double Ratchet ?

Why the Double Ratchet?

🔄Double Ratchet (Signal Protocol)Double Ratchet (Signal Protocol) Fialka

✗ Clé statique Static key

△ OTR (Off-the-Record) OTR (Off-the-Record)

△ MTProto 2.0

SPQR — Le Triple Ratchet post-quantique

SPQR — The post-quantum Triple Ratchet

Le problème

The problem

La solution SPQR

The SPQR solution

Pourquoi HKDF-SHA256 ?

Why HKDF-SHA256?

HKDF

Où HKDF est utilisé dans Fialka

Where HKDF is used in Fialka

PBKDF2

Argon2

Résistance aux attaques quantiques

Resistance to quantum attacks

Algorithme de Shor

Shor's Algorithm

Défense Fialka vs Shor

Fialka defense vs Shor

Algorithme de Grover

Grover's Algorithm

Défense Fialka vs Grover

Fialka defense vs Grover

Harvest Now, Decrypt Later

Harvest Now, Decrypt Later

Attaques par canal auxiliaire

Side-channel attacks

Autres menaces connues

Other known threats

Matrice de résistance complète

Complete resistance matrix

Roadmap post-quantique de Fialka

Fialka post-quantum roadmap

La pile complète

The complete stack

Vérifiez par vous-même

Verify it yourself