Post-quantum Kriptografik Doğru Cevaplar, asimetrik tercihleri 2029 son teslim tarihiyle yeniden yazıyor

Son tarihten üç yıl önce yeni bir sürüm

Geliştiricilere tam olarak hangi kriptografik araçları kullanmaları gerektiğini söyleyen kısa dokümanlar geleneği olan "Cryptographic Right Answers", 12 Ekim 2026'da words.filippo.io blogunda yayımlanan ve Hacker News'in ana sayfasına taşınan yeni bir yazıyla zenginleşti. Colin Percival ilk sürümü 2009'da yazdı, Thomas Ptacek 2015'te devam etti, Latacora ise seriyi 2018'de ve yeniden 2024'te güncelledi.

Yeni yazı, taze bir sürümü zamanlamayla gerekçelendiriyor. Yazara göre post-quantum göçü takvimi 2026 başında ciddi biçimde değişti ve artık alanda geçişin 2029'a kadar — yayından yaklaşık üç yıl sonra — tamamlanması gerektiği konusunda fikir birliği var. Sonuç çarpıcı: 2018'den bu yana her asimetrik öneri değişti ve çoğu 2024'ten beri değişti; simetrik katman ise büyük ölçüde olduğu gibi kaldı.

Cep kılavuzu

Yazıdaki özlü tavsiyeler:

• Veri şifreleme: varsa bir cloud KMS; yoksa rastgele nonce'larla XAES-256-GCM veya XChaCha20Poly1305 ve birkaç megabaytı aşan yükler için Cobblestone-128.
• Simetrik anahtar uzunluğu: seçim yapmanız gerekiyorsa 256 bit, ama bunun için kendinizi paralamanıza gerek yok.
• Simetrik kimlik doğrulama: HMAC-SHA-256.
• Hashing: SHA-2; birden fazla değeri birlikte hash'lerken SequenceHash gibi gerçek bir multihash yapısı.
• Rastgele tanımlayıcılar: 32 rastgele bayt.
• Parolalar: Argon2id veya scrypt — daha iyi alternatif olarak passkeys öne sürülüyor.
• Anahtar değişimi: uygun bir standart protokol içinde, X25519 ile ML-KEM-768 birleşimi.
• Açık anahtarlı şifreleme: X-Wing hibriğini (MLKEM768-X25519), HKDF-SHA256 ve AES-128-GCM kullanan HPKE ya da post-quantum anahtarlarla age.
• İmzalar: ML-DSA-44.
• Web siteleri ve client-server uygulamaları: bir cloud application veya network load balancer; ya da rustls, Go'nun crypto/tls'si, BoringSSL, AWS-LC veya s2n-tls, popüler ve güncel bir ACME istemcisiyle eşleştirilerek.
• Çevrimiçi yedekler: uzun ve rastgele bir parolayla restic.

Yazı, okuyucuların katı bir uyum rejimine tabi olmadığını varsayıyor. Tercihleri büyük ölçüde FIPS 140 ile uyumlu olarak nitelendiriyor ve CNSA 2.0 gibi daha katı bir şeye tabi olanları gerektiği gibi ikame etmeye davet ediyor.

Simetrik cevaplar neredeyse yerinde sayıyor

Yazıya göre simetrik kriptografi kuantum çağından Essentially dokunulmadan geçiyor: Grover algoritması, etrafında mühendislik yapmaya değecek pratik bir avantaj sunmuyor. HMAC, SHA-2 ve 256 bit rastgelelik bu yüzden önceki sürümlerden taşınıyor; ilginç incelikler ise yanlış kullanımla ilgili.

Yerel şifreleme için yazı, en az 128 bitlik rastgele nonce alan AEAD'leri — XAES-256-GCM veya XChaCha20Poly1305 — öneriyor; NaCl'in secretbox'ını ise daha az yaygın olan XSalsa20+Poly1305'in pek bir şey katmadığı bir sarmalayıcı olarak nitelendiriyor. Düz AES-GCM veya rastgele nonce'lı ChaCha20Poly1305 yalnızca bir anahtarın yaklaşık bir milyar mesajdan azını koruyacağından emin olduğunuzda kabul edilebilir.

Büyük veri kendi kuralına sahip: tek bir dev mesajı AEAD'e vermeyin ve kimlik doğrulamasız stream cipher'lara asla dokunmayın. Bunun yerine STREAM tarzı bir yapı kullanın. Birçok rakip seçenek arasında yazı, pyca/cryptography'de halihazırda bulunan ve Go'nun standart kütüphanesine girmekte olan TLS türevli Cobblestone-128'i onaylıyor.

Anahtar boyutu tavsiyesi bilinçli olarak gevşek: 256 bitlik anahtarlar çoklu hedef saldırılarını dışlıyor, ama 128 bitlik anahtarlar da tasarım bu tehdidi hesaba kattığında — Cobblestone'un yaptığı gibi — yeterli. TLS tercihlerinde 256 bitli şifre paketlerini dayatmak gereksiz olarak nitelendiriliyor ve AES-256'nın pratikte AES-128'den yavaş olduğu not ediliyor. HMAC için tavsiye, canonicalisation ve parser uyum hatalarından kaçınmak adına koruduğunuz baytların birebir kopyasını doğrulamak — yeniden serileştirilmiş bir nesneyi değil — ve tag'leri sabit süreli fonksiyonlarla karşılaştırmak.

Hashing SHA-2'de kalıyor, mümkünse length-extension saldırılarına dirençli olduğu için SHA-512/256 tercih ediliyor. SHA-3 gereksiz ve yavaş olarak nitelendiriliyor, ama yanlış değil; ML-KEM ve ML-DSA için zaten Keccak kodunuz varsa SHAKE128'den 32 bayt çekmek kabul edilebilir. Çoklu değer hash'leme, ev yapımı şemalar yerine SHA-2 ile SequenceHash veya SHA-3 ile TupleHash üzerinden gitmeli.

Listeye yeni meta-kurallar ekleniyor

Primitive'lerin ötesinde yazı, süreç düzeyinde iki öneri ekliyor: bellek güvenli bir dilde geliştirin ve güçlü bir LLM'a kodunuzu inceletin; çünkü yazarın değerlendirmesine göre modern modeller artık hata bulmada gerçekten iyi. İkisi de opsiyonel ekler değil, daimi doğru cevaplar olarak sunuluyor.

Neden önemli

2029 son teslim tarihi asimetrik katmana — TLS el sıkışmaları, anahtar değişimi, imzalar ve açık anahtarlı şifreleme — uygulanıyor ve bu katman neredeyse her uygulamanın içinde, genellikle ekiplerin kendilerinin yazdığı kod değil kütüphaneler ve protokoller aracılığıyla yer alıyor. Bu kadar spesifik bir rehberlik erken davranmanın maliyetini düşürüyor: önerilen hibritler bugünkü klasik güvenliği korurken kuantum direnci ekliyor ve çoğu zaten bakımı yapılan kütüphanelerde mevcut. Kriptografik bağımlılıklarını şimdi envanterleyip hibrit el sıkışmalarını erken devreye alan ekipler rutin bir yükseltmeyle karşılaşacak; bekleyen ekipler ise sıkıştırılmış ve daha riskli bir göçle karşılaşacak. LLM tabanlı incelemenin dahil edilmesi, tarihsel olarak kıt ve pahalı olan güvenlik incelemesinin bile sıradan projeler için pratik hale geldiğinin sinyalini veriyor.