MODÜL 2 — İleri simetrik kriptografi ve AEAD

Modül özeti

AES’i kara kutu olmaktan çıkarıp AEAD seçimini nonce yönetimi, tag ve saldırı sınıfları üzerinden okumayı hedefler.

Modül 2 — İleri Simetrik Kriptografi ve AEAD

Temel kriptografi eğitiminde AES’i bir kara kutu, şifreleme modlarını ise birbirinin yerine geçebilen seçenekler olarak öğrenmek mümkündür. Bu modülün amacı o bakışı değiştirmektir. AES’in iç yapısını anlamak, bir saldırganın nerede avantaj arayacağını ve tasarımcının bu saldırıları nasıl engellediğini görmek demektir. Confusion ve diffusion gibi tasarım ilkeleri soyut kavramlar değil; SubBytes, ShiftRows, MixColumns, AddRoundKey ve Key Schedule gibi somut dönüşümlerle karşılık bulan güvenlik kararlarıdır.

Bu modülde AEAD yapıları derinlemesine ele alınacaktır. AES-GCM, AES-GCM-SIV ve ChaCha20-Poly1305 yalnızca isim olarak değil; güvenlik hedefleri, nonce yönetimi, bütünlük mekanizmaları ve kullanım senaryolarına göre tercih gerekçeleriyle birlikte incelenir. Nonce tekrarının AES-GCM’yi nasıl felç ettiğini, AES-GCM-SIV’in bu sorunu nasıl farklı bir güvenlik garantisiyle ele aldığını ve ChaCha20-Poly1305’in yazılım ortamlarında neden öne çıktığını anlamak, modern kriptografik sistem tasarımında doğru seçim yapabilmenin temelidir.

Padding oracle, bit-flipping ve meet-in-the-middle saldırı sınıfları bu modülde savunma ve hata tanıma perspektifinden analiz edilir. Simetrik kriptografideki bu uygulama risklerinin büyük bölümü algoritmanın zayıflığından değil, yanlış mod seçiminden, hatalı IV/nonce yönetiminden, bütünlük kontrolünün eksik kurulmasından veya kriptografik hata mesajlarının dışarıya sızdırılmasından kaynaklanır. Bu modülü tamamlayan öğrenci, NIST test vektörlerini okuyabilir, kütüphane çıktılarını yorumlayabilir ve simetrik kriptografik kararları güvenlik modeli açısından değerlendirebilir.

Kazanımlar

Bu modül sonunda öğrenci:

AES’in SubBytes, ShiftRows, MixColumns ve AddRoundKey dönüşümlerini güvenlik sezgisi açısından açıklar; her adımın confusion veya diffusion hedefine nasıl katkıda bulunduğunu yorumlar.

AES Key Schedule yapısının güvenlik açısından önemini, round key üretiminin amacını ve anahtar genişletme hatalarının kriptografik etkisini değerlendirir.

AES-GCM, AES-GCM-SIV ve ChaCha20-Poly1305 yapılarını güvenlik hedefleri, nonce yönetimi gereksinimleri, kullanım sınırları ve uygulama senaryoları açısından karşılaştırır.

Nonce tekrarının AES-GCM üzerindeki etkisini teknik düzeyde açıklar; AES-GCM-SIV’in bu riski nasıl farklı bir güvenlik modeli ile ele aldığını yorumlar.

ChaCha20-Poly1305’te nonce tekrarının yalnızca gizliliği değil, Poly1305 one-time key tekrarından dolayı bütünlük/otantiklik güvenliğini de tehlikeye attığını açıklar.

Padding oracle, bit-flipping ve meet-in-the-middle saldırılarını savunma odaklı analiz eder; bu saldırı sınıflarının kaynak aldığı uygulama hatalarını tespit eder.

Hata mesajlarının kriptografik sızıntıya nasıl dönüştüğünü açıklar; bu riski azaltmak için güvenli API tasarımı, doğrulanmamış plaintext’i işlememe ve sabit zamanlı karşılaştırma gereksinimini değerlendirir.

NIST AES ve AEAD test vektörlerini okur; ciphertext, authentication tag, nonce/IV ve associated data alanlarını doğru biçimde ayrıştırır ve kütüphane çıktısıyla karşılaştırır.

OpenSSL ve libsodium gibi kütüphanelerin varsayılan parametrelerini sorgular; güvenli API ile düşük seviye tehlikeli API ayrımını tanır.

Eski algoritma desteğinin DES, 3DES/TDEA, RC4 ve ECB gibi yapılarda kurumsal sistemlere nasıl risk oluşturduğunu standart ve protokol çıktısı üzerinden gerekçelendirir ve güvenlik ekibine aktarır.

AES’in Derinlemesine Yapısı

AES, 128-bitlik bloklar üzerinde çalışan bir substitution-permutation network, yani SPN yapısına sahip blok şifredir. 128, 192 veya 256 bitlik anahtar uzunluklarına göre sırasıyla 10, 12 veya 14 tur uygular. NIST FIPS 197, AES-128, AES-192 ve AES-256 olmak üzere üç AES üyesini tanımlar; her biri 128-bit bloklar üzerinde çalışır ve isimdeki sayı anahtar uzunluğunu belirtir.

AES’in her turunda birkaç temel dönüşüm birlikte çalışır. Bu dönüşümler tek tek bakıldığında basit görünebilir; fakat birlikte uygulandıklarında düz metin, anahtar ve şifreli metin arasındaki ilişkiyi hesaplamalı olarak analiz edilmesi zor bir hâle getirirler. AES’in gücü tek bir karmaşık adımdan değil, iyi tasarlanmış basit adımların tur yapısı içinde tekrar edilmesinden gelir.

SubBytes, 16 baytlık durum matrisinin her baytını bağımsız olarak doğrusal olmayan bir S-box dönüşümüyle değiştirir. AES S-box’ı, GF(2⁸) sonlu alanında çarpımsal ters alma işleminden sonra uygulanan afin dönüşümle elde edilir. Burada “afin dönüşüm” ifadesi önemlidir; çünkü dönüşüm yalnızca doğrusal bir matris işleminden ibaret değildir, sabit terim de içerir. SubBytes’in doğrusal olmama özelliği, diferansiyel ve lineer kriptoanaliz saldırılarına karşı direncin temel parçalarından biridir. Bu nedenle SubBytes, AES içinde confusion’ın en belirgin kaynağıdır.

ShiftRows, durum matrisinin dört satırını farklı miktarlarda sola kaydırır. Birinci satır sabit kalır, ikinci satır bir bayt, üçüncü satır iki bayt, dördüncü satır ise üç bayt kaydırılır. Bu işlem tek başına güçlü bir kriptografik karıştırma sağlamaz; asıl etkisini MixColumns ile birlikte gösterir. ShiftRows olmasaydı MixColumns her sütunu kendi içinde karıştırır, fakat sütunlar arası yayılım yeterince kurulamazdı. Bu da blok şifrenin yapısal olarak daha kolay analiz edilebilen parçalara ayrılmasına neden olurdu.

MixColumns, her sütunu GF(2⁸) üzerinde tanımlı sabit bir matris çarpımıyla dönüştürür. Bu adım diffusion sağlar; yani bir giriş baytındaki değişimin çıktı üzerinde daha geniş bir alana yayılmasına katkıda bulunur. ShiftRows ve MixColumns birlikte uygulandığında, bir turda oluşan yerel değişim sonraki turlarda blok geneline taşınır. Bu yapı AES’in Wide Trail stratejisiyle ilişkilidir: amaç, düşük sayıda aktif S-box ile ilerleyen zayıf diferansiyel veya lineer yolların oluşmasını zorlaştırmaktır.

AddRoundKey, durum matrisini o tura ait round key ile XOR’lar. Yapısal olarak en basit adımdır; fakat anahtarın şifreleme sürecine doğrudan karışmasını sağlar. SubBytes, ShiftRows ve MixColumns anahtarsız dönüşümlerdir; AddRoundKey olmadan AES yalnızca herkesin hesaplayabileceği sabit bir permütasyon olurdu. Bu nedenle AddRoundKey, güvenliği anahtara bağlayan temel işlemdir.

Key Schedule, orijinal anahtardan turlara özgü round key’lerin türetildiği süreçtir. AES-128 için başlangıç anahtarıyla birlikte 11 round key kullanılır; AES-192 ve AES-256’da tur sayısı arttığı için round key sayısı da artar. Key Schedule’ın amacı, ana anahtarı turlara yaymak ve her turda kullanılacak alt anahtarları üretmektir. Round key’ler de ana anahtar gibi gizli kabul edilir; bunların sızması ciddi bir anahtar sızıntısıdır. Bu yüzden Key Schedule, “round key ele geçirilse bile ana anahtarı koruyan” bir yapı olarak değil, anahtar materyalini turlara kontrollü biçimde yayan bir mekanizma olarak anlaşılmalıdır.

AES Key Schedule üzerine yapılan bazı analizler, özellikle AES-192 ve AES-256’da ilişkili-anahtar modellerinde teorik zayıflıklar göstermiştir. Ancak bu saldırılar genellikle saldırganın birbiriyle özel ilişkiye sahip anahtarlar altında şifreleme yaptırabildiği kısıtlı modeller gerektirir. Gerçek dünya sistemlerinde bu koşullar çoğu zaman sağlanmadığı için tam tur AES’e karşı pratik bir kırma yöntemi olarak değerlendirilmezler.

Round sayıları güvenlik marjını doğrudan etkiler. AES’in 10, 12 ve 14 turluk yapısı, bilinen pratik saldırılara karşı geniş bir güvenlik alanı bırakacak şekilde seçilmiştir. Akademik çalışmalarda azaltılmış tur sayıları üzerinde saldırılar gösterilebilir; fakat bu sonuçlar tam tur AES’in pratikte kırıldığı anlamına gelmez. İleri seviye analizde bu ayrımı doğru kurmak önemlidir: azaltılmış tur saldırısı, tasarımın hangi bölgesinde marj olduğunu anlamaya yarar; doğrudan üretim sisteminin kırıldığı anlamına gelmez.

AES-NI donanım hızlandırması, modern işlemcilerde AES turlarını özel CPU talimatlarıyla uygular. Bu yalnızca performans avantajı sağlamaz; tablo tabanlı yazılım AES implementasyonlarında görülebilen cache timing risklerini de büyük ölçüde azaltır. Ancak AES-NI kullanımı tüm yan kanal ve uygulama güvenliği risklerini tek başına ortadan kaldırmaz. Tag doğrulama, hata mesajı tasarımı, bellek erişimleri, anahtar yönetimi ve protokol entegrasyonu hâlâ ayrıca değerlendirilmelidir.

AES’in iç yapısını anlamak, öğrenciye algoritmanın “neden güvenli kabul edildiğine” dair sezgi kazandırır. Bu sezgi olmadan AEAD yapılarındaki güvenlik hedeflerini, nonce yönetiminin neden kritik olduğunu veya mod seçiminin neden algoritma seçiminden ayrı düşünülemeyeceğini tam anlamak güçtür.

Blok Şifre Tasarım Mantığı

Shannon’ın confusion ve diffusion ilkeleri blok şifre tasarımının temel düşünce çerçevesini oluşturur. Confusion, şifreli metin ile anahtar arasındaki ilişkiyi karmaşık ve doğrusal olmayan hâle getirmeyi hedefler. Diffusion ise düz metindeki istatistiksel özelliklerin şifreli metin boyunca yayılmasını amaçlar. AES bu iki ilkeyi SubBytes ile confusion, ShiftRows ve MixColumns ile diffusion sağlayacak şekilde sistematik biçimde uygular.

S-box tasarımı blok şifrenin güvenliğinde belirleyici bir rol oynar. İyi tasarlanmış bir S-box, yüksek doğrusal olmama değerine ve düşük diferansiyel olasılığa sahip olmalıdır. AES S-box’ı bu hedefleri karşılamak üzere cebirsel bir yapı kullanılarak inşa edilmiştir. Cebirsel yapının avantajı analiz edilebilirlik, tutarlılık ve optimize edilebilirliktir. Bazı analistler, bu cebirsel düzenin gelecekte farklı saldırı teknikleri için yüzey oluşturup oluşturmayacağını tartışmıştır; ancak bugün için tam tur AES güvenliğini pratikte tehdit eden somut bir yol bulunmamaktadır.

Permütasyon ve lineer dönüşüm aşamasında ShiftRows ve MixColumns, S-box çıktılarının blok geneline yayılmasını sağlar. MixColumns için kullanılan matris, Maximum Distance Separable, yani MDS özelliğiyle güçlü bir difüzyon hedefler. Bu yapı, az sayıda giriş farkının tur geçişlerinde hızla daha fazla aktif bayta yayılmasına katkı sağlar.

Anahtar genişletme güvenliği bağlamında Key Schedule’ın yeterli yapısal karmaşıklığa sahip olması, round key’ler arasında saldırganın kullanabileceği basit ve zayıf ilişkilerin oluşmaması açısından önemlidir. Fakat tekrar vurgulamak gerekir: Round key’ler gizli materyaldir. Bir implementasyonda round key bellekte açıkta kalıyor, dump edilebiliyor veya yan kanal üzerinden sızıyorsa bu durum doğrudan anahtar güvenliği problemidir.

Blok boyutu ve güvenlik ilişkisi doğrudan birthday sınırıyla bağlantılıdır. 64-bit blok boyutuna sahip şifreler, örneğin 3DES/TDEA, aynı anahtar altında yüksek miktarda veri şifrelendiğinde blok çakışması ve istatistiksel ayırt edilebilirlik riski taşır. SWEET32 saldırısının temelinde bu 64-bit blok boyutu kaynaklı birthday-bound problemi vardır. AES’in 128-bit blok boyutu bu sınırı pratik düzeyde çok daha uzağa taşır. Buna rağmen AES-GCM gibi modlarda da nonce ve blok sayısı sınırlarına dikkat etmek gerekir; çünkü güvenlik yalnızca blok boyutuna değil, modun kullanım kurallarına da bağlıdır.

Analiz edilebilirlik iyi bir şifre tasarımının önemli özelliklerinden biridir. Şifrenin yapısını açık tutmak, tasarım gerekçelerini yayımlamak ve güvenlik iddiasını kriptografik topluluğun incelemesine açmak, modern kriptografinin temel yaklaşımıdır. Güvenliğini gizliliğe dayandıran tasarımlar, yani security through obscurity, akademik ve kurumsal düzeyde güvenilir kabul edilmez.

“AES kırıldı” gibi manşetler zaman zaman akademik çalışmalara dayandırılır. Bu çalışmaların büyük bölümü azaltılmış tur sayısı, ilişkili-anahtar modeli veya pratikte sağlanması zor varsayımlar altında geçerlidir. Tam tur AES’in pratikte kırılabilir olduğu yönünde güncel ve kabul görmüş bir sonuç bulunmamaktadır.

AEAD Yapıları

AEAD, yani Authenticated Encryption with Associated Data, hem gizlilik hem de bütünlük/otantiklik sağlayan şifreleme yaklaşımını ifade eder. RFC 5116, AEAD’i şifreleme ile mesaj doğrulamayı tek bir kriptografik algoritma altında birleştiren bir yapı olarak tanımlar ve associated data’nın şifrelenmeden bütünlük/otantiklik korumasına alınabildiğini açıklar.

Simetrik kriptografide AEAD şemaları, gizlilik ve şifreli metin bütünlüğünü birlikte sağlayarak CCA tarzı pratik saldırılara karşı güçlü bir savunma zemini oluşturur. Ancak her AEAD şemasının güvenlik garantisi kendi modeli, nonce varsayımı, kullanım sınırları, tag uzunluğu ve doğrulama davranışıyla birlikte okunmalıdır. “AEAD kullanılıyor” demek doğru yönde güçlü bir adımdır; fakat nonce tekrar ediyorsa, tag doğrulaması hatalıysa veya doğrulanmamış plaintext uygulamaya veriliyorsa güvenlik garantisi bozulabilir.

AEAD’ın temel güvenlik hedefleri üç başlıkta toplanabilir. Birincisi, plaintext gizliliğini korumaktır. İkincisi, ciphertext’in değiştirilmediğini authentication tag ile doğrulamaktır. Üçüncüsü, associated data olarak verilen fakat şifrelenmeyen ek bilgiyi bütünlük korumasına dahil etmektir. Associated data, paket başlığı, protokol sürümü, mesaj tipi, oturum kimliği veya yön bilgisi gibi şifrelenmesi gerekmeyen ama değiştirilmemesi gereken alanlar için kullanılır.

AES-GCM, yani Galois/Counter Mode, AES’in CTR benzeri şifreleme davranışı ile GHASH adlı polinom tabanlı authentication mekanizmasını birleştirir. CTR tabanlı yapı paralel çalışmaya ve yüksek performansa uygundur. GHASH ise AAD ve ciphertext üzerinden authentication tag üretir. NIST SP 800-38D, GCM ve GMAC’i onaylı simetrik blok şifreleri üzerinde çalışan authenticated encryption ve MAC modları olarak tanımlar.

AES-GCM’nin AEAD güvenliği, aynı anahtar altında nonce’un tekrar kullanılmamasına, authentication tag’in doğru doğrulanmasına, kullanım limitlerine uyulmasına ve hata davranışının güvenli tasarlanmasına bağlıdır. RFC 5116, GCM’de aynı key ve nonce ile farklı plaintext değerlerinin şifrelenmesinin gizliliği bozduğunu ve ilgili anahtar altındaki authentication/integrity korumasını da zayıflattığını açıkça belirtir. Aynı kaynak, bu durumda iki plaintext’in XOR bilgisinin elde edilebileceğini ve iç hash anahtarının kurtarılmasının sonraki sahtecilikleri kolaylaştırabileceğini ifade eder.

Authentication tag uzunluğu da güvenlik analizinin parçasıdır. Modern tasarımlarda 96 bitten kısa GCM tag uzunlukları genel amaçlı kullanım için uygun görülmemeli; kısa tag tercihleri ancak çok özel, sınırlı ve iyi gerekçelendirilmiş protokol bağlamlarında değerlendirilmelidir. Genel amaçlı sistemlerde en az 96-bit, mümkünse yaygın varsayılan olan 128-bit authentication tag kullanımı tercih edilmelidir.

Nonce tekrarının AES-GCM’de yıkıcı olmasının nedeni iki katmanlıdır. İlk olarak CTR benzeri şifreleme nedeniyle aynı key+nonce çifti aynı keystream’in tekrar kullanılmasına yol açar. İki ciphertext XOR’landığında keystream iptal olur ve saldırgan plaintext’lerin XOR’unu elde eder. İkinci olarak GHASH tarafında kullanılan authentication yapısı da nonce tekrarından etkilenir; yeterli bilgi oluştuğunda saldırgan authentication tag üretme kabiliyetine yaklaşabilir. Bu nedenle AES-GCM’de nonce reuse yalnızca gizlilik problemi değil, bütünlük/otantiklik problemidir.

AES-GCM’de 96-bit nonce kullanımı yaygın ve önerilen pratik yapıdır. RFC 5116, AEAD algoritmalarının nonce uzunlukları için algoritmaya özgü sınırlar tanımladığını ve 12 oktetlik nonce desteğinin beklenen bir özellik olduğunu belirtir. Eğer nonce rastgele üretiliyorsa birthday paradox nedeniyle yüksek hacimli sistemlerde tekrar riski dikkate alınmalıdır. Bu nedenle yoğun mesajlaşma sistemlerinde sayaç tabanlı veya protokol tarafından benzersizliği garanti edilen nonce üretimi çoğu zaman daha denetlenebilir bir yaklaşımdır. Burada kritik olan nonce’un gizli olması değil, aynı anahtar altında tekrar etmemesidir.

AES-GCM-SIV, RFC 8452’de tanımlanan nonce misuse-resistant bir AEAD yapısıdır. Bu sınıftaki AEAD’ler, AES-GCM gibi nonce tekrarında felaket biçimde çökmez. RFC 8452, nonce tekrar ettiğinde bu tür yapılarda temel sızıntının, aynı nonce ile şifrelenen mesajların eşit olup olmadığının anlaşılması olduğunu belirtir. Bu güvence, klasik AES-GCM’nin sunduğu güvenlik modelinden farklıdır; amaç nonce tekrarını teşvik etmek değil, nonce benzersizliğinin garanti edilemediği ortamlarda hasarı sınırlamaktır.

AES-GCM-SIV, nonce ve ana anahtardan türetilen geçici authentication ve encryption anahtarlarıyla çalışır. AAD ve plaintext üzerinde POLYVAL tabanlı bir authentication değeri hesaplanır; bu değer sentetik IV/tag olarak kullanılır ve ardından CTR benzeri şifreleme uygulanır. Aynı anahtar, aynı nonce, aynı plaintext ve aynı AAD tekrar kullanılırsa deterministik yapı nedeniyle aynı çıktı oluşabilir; bu da mesaj tekrarını veya eşitliğini sızdırır. Buna karşılık aynı nonce farklı mesajlarla kullanıldığında AES-GCM’deki gibi bütün güvenlik yapısı çökmez. Bu nedenle AES-GCM-SIV, özellikle nonce yönetiminin güvenilir biçimde denetlenemediği dağıtık sistemlerde anlamlı bir güvenlik marjı sağlar.

AES-GCM-SIV’in bedeli, şifrelemenin iki geçişli bir yapıya sahip olmasıdır. Önce authentication değeri hesaplanır, ardından şifreleme yapılır. Bu nedenle streaming uygulamalarda veya çok büyük veri akışlarında AES-GCM kadar doğal bir kullanım sağlamaz. Ayrıca GCM kadar kolay paralelleştirilemeyen noktaları vardır. Buna rağmen durum bilgisi tutmayan istemciler, çoklu üretici sistemleri veya nonce çakışmasının mimari olarak zor önlendiği ortamlarda değerlendirilmesi gereken güçlü bir seçenektir.

ChaCha20-Poly1305, ChaCha20 stream cipher ile Poly1305 MAC’in birleşimidir. RFC 8439, AEAD_CHACHA20_POLY1305 yapısında 256-bit anahtar, aynı anahtar altında her kullanım için farklı 96-bit nonce, plaintext ve AAD kullanıldığını belirtir. AES donanım hızlandırması olmayan ortamlarda, özellikle bazı mobil ve gömülü sistemlerde, yazılım performansı açısından AES-GCM’e güçlü bir alternatif olabilir.

ChaCha20-Poly1305’te nonce benzersizliği şarttır. Nonce tekrarı aynı keystream’in tekrar kullanılmasına yol açar; bu da plaintext’lerin XOR bilgisini açığa çıkarabilir. Ayrıca Poly1305 bir one-time MAC olarak tasarlandığı için aynı key+nonce tekrarlandığında Poly1305 one-time key de tekrar kullanılır. Bu durum yalnızca gizliliği değil, bütünlük/otantiklik güvenliğini de tehlikeye atar. Dolayısıyla ChaCha20-Poly1305 için nonce reuse etkisi “yalnızca gizlilik zayıflar” şeklinde anlatılmamalıdır; gizlilik ve authentication güvenliği birlikte risk altına girer.

Poly1305 MAC mantığı, her mesaj için farklı bir one-time key kullanılmasına dayanır. ChaCha20-Poly1305 bu anahtarı, şifreleme anahtarı ve nonce üzerinden türetir. Bu yapı doğru kullanıldığında güvenlidir; ancak aynı key+nonce kombinasyonu tekrarlandığında Poly1305’in bir kerelik kullanım varsayımı ihlal edilir. Bu nedenle nonce yönetimi, ChaCha20-Poly1305 için de AES-GCM kadar kritiktir.

AEAD seçiminin performans ve güvenlik etkisi açısından genel yol haritası şöyledir: AES-NI veya benzeri donanım hızlandırması bulunan ortamlarda AES-GCM güçlü bir tercih olmaya devam eder; ancak nonce yönetimi kesin biçimde kontrol edilmelidir. Nonce tekrar riskinin güvenilir biçimde yönetilemediği durumlarda AES-GCM-SIV değerlendirilmelidir. AES donanım hızlandırması bulunmayan veya yazılım performansının öne çıktığı ortamlarda ChaCha20-Poly1305 güçlü bir alternatiftir.

TLS 1.3 bağlamında da ayrım doğru kurulmalıdır. TLS 1.3, AES-GCM ve ChaCha20-Poly1305 tabanlı cipher suite’leri tanımlar; AES-GCM-SIV, TLS 1.3’ün standart cipher suite listesinde yer almaz. RFC 8446’ya göre TLS uyumlu bir uygulama TLS_AES_128_GCM_SHA256 cipher suite’ini uygulamak zorundadır; TLS_AES_256_GCM_SHA384 ve TLS_CHACHA20_POLY1305_SHA256 ise uygulanması önerilen cipher suite’lerdir. Aynı RFC, TLS 1.3 için AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, AES-128-CCM ve AES-128-CCM-8 cipher suite’lerini listeler.

Yapı Nonce reuse etkisi AES-NI bağımlılığı Streaming uyumu Temel kaynak

AES-GCM Yıkıcı: gizlilik + bütünlük/otantiklik riski AES hızlandırmasıyla çok avantajlı Evet RFC 5116, NIST SP 800-38D

AES-GCM-SIV Sınırlı sızıntı: aynı nonce altında mesaj eşitliği açığa çıkabilir; klasik GCM gibi felaket çöküş beklenmez AES hızlandırmasıyla avantajlı İki geçişli yapı nedeniyle sınırlı RFC 8452

ChaCha20-Poly1305 Yıkıcı: gizlilik + bütünlük/otantiklik riski Yok Evet RFC 8439

Simetrik Kripto Saldırıları

Padding oracle saldırıları, CBC modunda şifrelenmiş verinin sunucu tarafından nasıl doğrulandığına dair bilgi sızdırmasından yararlanır. PKCS#7 padding kullanılan bir sistemde, son bloğun padding’inin geçerli olup olmadığını farklı hata yanıtlarıyla ayırt eden bir API veya yanıt davranışı oracle işlevi görebilir. Saldırgan bu oracle’ı kullanarak şifreli metni blok blok ve byte-by-byte çözebilir; bunun için anahtarı bilmesi gerekmez.

Bu saldırı özellikle bütünlük kontrolünün eksik olduğu, doğrulamanın şifre çözmeden sonra yapıldığı veya hata türlerinin dışarıya farklı biçimde yansıtıldığı sistemleri hedef alır. Salt CBC şifreleme, hatalı MAC-then-Encrypt tasarımları veya anahtarsız hash ile bütünlük sağlamaya çalışan yapılar bu açıdan risklidir.

Savunma tarafında iki temel yaklaşım vardır. Birincisi, doğrulama hatası, padding hatası, format hatası ve şifre çözme hatası gibi ayrımlar kullanıcıya veya saldırgana farklı şekilde yansıtılmamalıdır. Hata yanıtları birleştirilmeli ve işlem süresi farkları da oracle oluşturmayacak şekilde tasarlanmalıdır. İkincisi ve daha güçlü çözüm, modern AEAD şemalarına geçmektir. AEAD yapılarında doğrulama başarısızsa plaintext uygulamaya verilmemeli ve hiçbir iş mantığı tarafından işlenmemelidir. Güvenli API tasarımı bunu geliştiricinin yanlışlıkla ihlal edemeyeceği şekilde zorunlu kılmalıdır.

Örneğin CBC modunda çalışan bir uygulama, geçersiz padding durumunda 400 Bad Request, başka bir doğrulama hatasında ise 500 Internal Server Error döndürüyorsa saldırgan bu fark üzerinden oracle kurabilir. Buradaki asıl ders, hata mesajlarının yalnızca kullanıcı deneyimi meselesi olmadığıdır. Kriptografik işlem zincirinde hata davranışı, doğrudan bilgi sızıntısı kanalına dönüşebilir.

Bit-flipping saldırıları, bütünlük koruması olmayan şifreli metinlerde bir veya daha fazla biti değiştirerek karşı tarafın şifre çözdükten sonra manipüle edilmiş plaintext’i işlemesini sağlar. CBC modunda C[i] bloğunun belirli bir bitini değiştirmek, P[i+1] bloğunda aynı bit konumunu kontrollü biçimde değiştirir. Ancak bu işlem aynı zamanda C[i] bloğunun çözüldüğü P[i] bloğunu da bozar. Bu nedenle saldırgan genellikle hedeflediği alanın bir sonraki blokta olmasını ister veya ilk blok için IV manipülasyonu gibi yöntemlerle çalışır.

CTR modunda bit-flipping daha doğrudan etkilidir. Stream cipher benzeri yapı nedeniyle ciphertext’te çevrilen bit, plaintext’te aynı konumdaki biti değiştirir. Eğer bütünlük kontrolü yoksa saldırgan şifreli metni değiştirebilir ve karşı taraf bunu fark etmeden manipüle edilmiş plaintext’i işleyebilir. Bu nedenle CTR, CBC, CFB veya OFB gibi salt şifreleme modları modern protokollerde tek başına yeterli görülmemelidir.

AEAD kullanımı bit-flipping saldırılarını yapısal olarak engeller. Şifreli metin üzerinde yapılan değişiklik authentication tag doğrulamasını başarısız kılar. Burada kritik nokta, uygulamanın doğrulama başarısız olduğunda plaintext’i hiçbir şekilde kullanmamasıdır. Tag doğrulaması başarısız olmasına rağmen plaintext’i loglamak, ayrıştırmak veya kısmen işlemek güvenlik modelini bozar.

Meet-in-the-middle saldırısı, çifte şifrelemenin güvenliğinin neden beklenenden çok daha düşük olabileceğini açıklar. İki bağımsız 56-bit DES anahtarıyla yapılan Double DES şifreleme, sezgisel olarak 112-bit güvenlik sağlıyor gibi görünebilir. Ancak saldırgan bir yönden tüm olası K1 değerleriyle ara sonuçları hesaplayıp depolayabilir, diğer yönden K2 değerleriyle geri yönde arama yaparak eşleşme bulabilir. Bu nedenle Double DES, beklenen 112-bit güvenlik seviyesine ulaşamaz.

Triple DES, yani TDEA/3DES, Double DES’e göre bu sorunu güçlendirilmiş bir yapıyla ele alır; fakat 64-bit blok boyutu ve modern güvenlik beklentileri nedeniyle artık yeni sistemler için uygun değildir. NIST, SP 800-67 Rev. 2’yi 1 Ocak 2024 itibarıyla geri çekmiş ve TDEA’nın yeni kriptografik koruma uygulamak için artık onaylı bir blok şifre olmadığını belirtmiştir; mevcut eski verilerin çözülmesi, key unwrapping veya MAC doğrulaması gibi legacy işlemler ayrı değerlendirilir.

Mode misuse problemleri, doğru algoritmanın yanlış modda veya yanlış güvenlik hedefiyle kullanılmasından kaynaklanır. ECB modu bağımsız blok şifrelemesi yaptığı için aynı plaintext bloğunu her seferinde aynı ciphertext bloğuna dönüştürür. Bu özellik semantik güvenliği ortadan kaldırır ve veri desenlerinin sızmasına neden olur. Klasik bitmap görselleştirmesi bu sorunu açıkça gösterir.

CFB ve OFB gibi modlar bazı eski sistemlerde hâlâ görülebilir. Bu modlar doğru koşullarda gizlilik sağlayabilir; fakat bütünlük garantisi sunmazlar. Hata yayılımı özellikleri, IV gereksinimleri ve protokol entegrasyonu dikkatli analiz edilmelidir. Modern yeni tasarımlarda çoğu durumda AEAD kullanımı daha güvenli, daha standart ve daha az hata yaptıran yaklaşımdır.

Seçilmiş şifreli metin saldırıları bağlamında simetrik yapıların zayıflıkları temel olarak bütünlük katmanı eksikliğinden beslenir. Salt şifreleme, saldırganın değiştirilmiş ciphertext’i sisteme göndermesine ve sistemin davranışını gözlemlemesine kapı aralayabilir. Bu nedenle modern tasarımda gizlilik ve bütünlük birlikte düşünülmelidir.

Simetrik Kriptoda Uygulama Riskleri

Yanlış mod seçimi en sık karşılaşılan uygulama risklerinden biridir. ECB modunu seçmek, bütünlük kontrolü olmadan CBC kullanmak veya stream cipher modunu yanlış bağlamda uygulamak; algoritmanın kendisi güçlü olsa bile sistemi güvensiz kılabilir. Modern sistemlerde yeni bir tasarım yapılacaksa varsayılan cevap çoğu zaman AEAD kullanımıdır. Bunun dışındaki her mod seçimi özel gerekçe, standart uyumluluğu ve güvenlik analizi gerektirir.

Yanlış IV/nonce yönetimi AES-GCM ve CTR gibi yapılarda gizliliği, GCM söz konusu olduğunda ayrıca bütünlük/otantiklik güvenliğini doğrudan tehdit eder. Nonce üretiminde sabit değer kullanmak veya aynı anahtar altında tekrar edebilecek değerler seçmek kritik hatadır. Buna karşılık sayaç tabanlı nonce üretimi, doğru tasarlanır ve tekrar etmeyecek şekilde yönetilirse güvenli bir yöntem olabilir. Nonce’un tahmin edilebilir olması çoğu nonce tabanlı modda tek başına sorun değildir; asıl sorun aynı anahtar altında tekrar etmesidir.

Dağıtık sistemlerde nonce yönetimi mimari düzeyde ele alınmalıdır. Birden fazla servis örneği aynı anahtarı kullanıyor ve kendi içinde sayaç tutuyorsa, yeniden başlatma, snapshot geri dönüşü veya yatay ölçekleme sırasında aynı nonce’un yeniden üretilmesi mümkündür. Bu risk merkezi sayaç, instance kimliğiyle ayrılmış nonce alanı, anahtar türetme ayrımı veya nonce misuse-resistant AEAD seçimi gibi yöntemlerle azaltılabilir.

Şifreleme ve bütünlüğü ayrı düşünme hatası, “şifreleme veriyi gizler, bütünlük ayrıca istenirse eklenir” şeklindeki eksik zihinsel modelden kaynaklanır. Teknik olarak şifreleme ve MAC ayrı katmanlar olarak tasarlanabilir; fakat bu katmanların sırası, anahtar ayrımı ve hata davranışı doğru kurulmalıdır. Doğru tasarlanmış Encrypt-then-MAC yapıları güçlü güvenlik sağlayabilir. Buna rağmen modern sistemlerde standart AEAD şemaları daha az hata yaptıran, daha kolay analiz edilebilen ve daha güvenli varsayılanlar sunan tercih olarak öne çıkar.

MAC-then-Encrypt yaklaşımı tarihsel protokollerde görülmüştür, fakat hata davranışı ve padding doğrulaması yanlış tasarlandığında padding oracle saldırılarına açık hâle gelebilir. Encrypt-then-MAC yaklaşımı genel olarak daha sağlam bir güvenlik gerekçesine sahiptir; çünkü ciphertext işlenmeden önce bütünlüğü doğrulanabilir. Ancak bu yaklaşım bile anahtar ayrımı, sabit zamanlı doğrulama ve hata mesajlarının birleştirilmesi gibi ayrıntılar doğru yapılmazsa sorun üretebilir.

Eski algoritmaları desteklemenin riski kurumsal sistemlerde somut bir tehlike oluşturmaya devam eder. RC4 zayıflıkları uzun süredir bilinmektedir ve TLS bağlamında RC4 cipher suite’lerinin kullanımı RFC 7465 ile yasaklanmıştır. Bu RFC, TLS istemci ve sunucularının RC4 cipher suite’lerini müzakere etmemesi gerektiğini belirtir. 3DES/TDEA ise 64-bit blok boyutu ve geçiş takvimi nedeniyle yeni veri koruma için uygun değildir. Bu algoritmaların protokol düzeyinde açık bırakılması downgrade riskini artırabilir ve güvenlik taramalarında yalnızca “uyarı” değil, gerçek saldırı yüzeyi olarak değerlendirilmelidir.

Hata mesajlarının kriptografik sızıntıya dönüşmesi padding oracle saldırısında açıkça görülür. Bu risk yalnızca HTTP yanıt kodlarıyla sınırlı değildir. İşlem süresi farklılıkları, exception mesajları, log seviyesine göre değişen hata ayrıntıları veya API’nin farklı hata nesneleri döndürmesi de oracle oluşturabilir. Kriptografik doğrulama başarısız olduğunda uygulamanın dışarıya döndürdüğü hata mümkün olduğunca tek tip olmalı, doğrulama karşılaştırmaları sabit zamanlı yapılmalı ve doğrulanmamış plaintext uygulamanın hiçbir katmanında kullanılmamalıdır.

Güvenli varsayılanların önemi kütüphane seçiminde belirleyicidir. libsodium gibi kütüphaneler güvenli varsayımları API tasarımına gömmeye çalışır; geliştiricinin yanlış parametre seçme alanını daraltır. Buna karşılık OpenSSL EVP veya Python cryptography hazmat gibi düşük seviye API’lar daha fazla esneklik sağlar, fakat bu esneklik daha fazla sorumluluk anlamına gelir. Python cryptography kütüphanesindeki “hazmat” isimlendirmesi bu yüzden anlamlıdır: düşük seviye işlemlere erişim verir, fakat kullanıcının tehlikeli alana girdiğini açıkça belirtir.

Simetrik Kripto Test Vektörleri ve Uygulama Kontrol Araçları

Test vektörleri, bir kriptografik implementasyonun belirli standart giriş-çıkış çiftleriyle uyumunu kontrol etmek için temel doğrulama araçlarından biridir. Ancak test vektörleri, implementasyonun tüm güvenliğini tek başına kanıtlamaz. Yan kanal direnci, hata işleme, nonce yönetimi, API yanlış kullanımı, bellek güvenliği ve protokol entegrasyonu ayrıca değerlendirilmelidir.

AES test vektörlerinin okunması genellikle Key, Plaintext, Ciphertext ve modun gerektirdiği ek parametrelerin ayrıştırılmasıyla başlar. CBC, CTR, CFB ve OFB gibi modlarda IV veya counter bilgisi önemlidir. Bir kütüphane kullanılırken standart bir test vektörü seçilip kütüphane çıktısıyla karşılaştırılır. Çıktı eşleşiyorsa bu, seçilen test koşulu için implementasyonun beklenen sonucu ürettiğini gösterir.

AEAD test vektörleri daha fazla alan içerir. AES-GCM için tipik bir test vektöründe Key, IV veya nonce, Plaintext, AAD, Ciphertext ve Tag bulunur. Bazı vektörlerde plaintext boş olabilir; bu durumda yapı yalnızca AAD’nin bütünlüğünü test ediyor olabilir. Bazı vektörlerde AAD boş olabilir; bu da yalnızca plaintext şifreleme ve tag üretimini sınar. Öğrencinin bu alanları doğru ayırması, gerçek protokol paketlerini analiz ederken kritik beceridir.

NIST test vektörleri genellikle hex formatında verilir. Bir kütüphanenin çıktısını hex’e çevirip test vektörüyle karşılaştırmak doğrulama sürecinin ilk adımıdır. Ancak tag uzunluğu, IV/nonce boyutu ve çıktı serileştirme biçimi dikkatle kontrol edilmelidir. RFC 5116’da tanımlanan AEAD_AES_GCM algoritmaları 16 oktet, yani 128-bit authentication tag kullanır. NIST ayrıca SP 800-38D revizyon sürecinde GCM için 96 bitten kısa authentication tag desteğini kaldırmayı planladığını duyurmuştur.

Nonce reuse etkisini yorumlarken dikkatli olmak gerekir. Eğer iki ciphertext’in aynı anahtar ve nonce ile üretildiği biliniyorsa, CTR tabanlı yapılarda ciphertext’lerin XOR’u plaintext’lerin XOR’unu verir. Ancak yalnızca iki ciphertext’i XOR’layıp sonucun sıfırdan farklı olduğunu görmek, nonce reuse olduğunu kanıtlamaz. Nonce reuse tespiti için metadata, protokol alanları, log kayıtları veya nonce değerlerinin doğrudan karşılaştırılması gerekir. XOR analizi eğitim amaçlı ve izinli lab ortamında gösterilebilir; gerçek sistemlerde yetkisiz ciphertext analizi yapılmamalıdır.

OpenSSL ve libsodium çıktılarının karşılaştırılması hem implementasyon doğruluğunu hem de API kullanım farklarını anlamak için değerlidir. OpenSSL’de AES-GCM gibi AEAD modları doğru biçimde genellikle EVP API üzerinden kullanılmalıdır. openssl enc komutu GCM ve CCM gibi authenticated encryption modlarını desteklemez; OpenSSL dokümantasyonu bunun sebebini authentication tag doğrulanmadan streaming çıktı üretmenin güvenlik riski oluşturmasıyla açıklar. Bu nedenle AES-GCM test vektörü doğrulaması anlatılırken openssl enc -aes-256-gcm gibi bir yol önerilmemelidir.

libsodium tarafında AEAD API’ları daha yüksek seviyeli ve güvenli varsayımları teşvik eden bir yapı sunar. Ancak nonce yönetimi yine de kullanılan algoritmaya göre uygulamanın bilinçli sorumluluğudur. AES-GCM ve ChaCha20-Poly1305 gibi 96-bit nonce kullanan yapılarda sayaç veya protokol tarafından benzersizliği garanti edilen nonce üretimi dikkatle tasarlanmalıdır. XChaCha20-Poly1305 gibi geniş nonce alanlı yapılarda rastgele nonce kullanımı daha güvenli bir pratik hâline gelir; fakat bu modülün ana odağı klasik ChaCha20-Poly1305 ve AES-GCM olduğundan, nonce benzersizliği kuralı özellikle vurgulanmalıdır.

Ciphertext, tag, nonce ve associated data alanlarının ayrıştırılması gerçek sistemlerde çoğunlukla bu alanların tek bir byte dizisine serileştirilmesiyle oluşan paketi okumayı gerektirir. Hangi baytların nonce, hangilerinin ciphertext, hangilerinin tag olduğunu bilmeden paketi doğru çözmek mümkün değildir. Protokol belgeleri veya kütüphane dokümantasyonu bu yapının biçimini açıkça tanımlamalıdır.

Üretim ortamında test vektörü ile gerçek anahtarların karıştırılmaması kritik bir operasyonel kuraldır. Test vektörlerinde kullanılan anahtarlar doğrulama için bilinen değerlerdir; bu değerlerin üretim ortamına taşınması ciddi bir güvenlik açığı oluşturur. Test ve üretim ortamları arasındaki anahtar yalıtımı, anahtar yönetim politikasının ayrılmaz bir parçası olmalıdır.

Komut & Araç Okuryazarlığı

Bu bölümde AES-GCM test vektörü doğrulaması ve libsodium API güvenlik analizi iki ayrı odak noktası olarak ele alınmaktadır. Amaç, öğrencinin yalnızca algoritma adını bilmesi değil, bir kütüphane çıktısını standart alanlarla ilişkilendirebilmesi ve API tasarımının güvenlik etkisini okuyabilmesidir.

AES-GCM Test Vektörü Doğrulaması — OpenSSL EVP ile Çıktı Yorumlama

AES-GCM test vektörü doğrulaması OpenSSL’in EVP API’siyle veya AEAD destekleyen uygun bir test koduyla yapılmalıdır. openssl enc komutu GCM ve CCM gibi AEAD modlarını desteklemediği için bu işlemde doğru araç değildir. Bu ayrım önemlidir; çünkü yanlış araç seçimi, öğrencinin standartla uyumlu doğrulama yaptığını sanmasına ama aslında AEAD davranışını hiç test etmemesine neden olabilir.

Platform / Araç: OpenSSL EVP API, izinli yerel test ortamı — LOCAL-CRYPTO01.

Amaç: Bilinen bir test vektörünün Key, IV/nonce, Plaintext ve AAD değerleriyle şifreleme yapıp üretilen Ciphertext ve Tag değerlerini NIST veya RFC test vektörüyle karşılaştırmak.

Bu işlem yalnızca izinli yerel veya lab ortamında, tamamen uydurma anahtarlar ve test vektörleriyle gerçekleştirilmelidir. Gerçek üretim anahtarları komut satırına, script dosyasına, terminal geçmişine, shell history’ye veya log sistemlerine taşınmamalıdır. Kriptografik testlerde en sık yapılan operasyonel hatalardan biri, gerçek anahtarları “geçici olarak” test ortamına kopyalamaktır.

Beklenen çıktı, ciphertext ve authentication tag değerlerinin hex formatında ayrıştırılmasıdır. Kullanılan test vektörüne göre tag uzunluğu çoğu modern GCM kullanımında 128-bit olarak beklenir; farklı tag uzunlukları varsa bunun standart, protokol ve güvenlik politikası açısından gerekçesi ayrıca incelenmelidir. IV’nin 96-bit olup olmadığı da kontrol edilmelidir; 96-bit dışı IV değerlerinde GCM farklı bir IV işleme yoluna gidebilir ve çıktı test beklentisinden farklı olabilir.

Öğrenci çıktıda özellikle şu alanlara bakmalıdır: Üretilen ciphertext test vektörüyle birebir eşleşiyor mu? Authentication tag beklenen değerle aynı mı? AAD doğru biçimde işleme dahil edilmiş mi? IV/nonce doğru uzunlukta mı ve doğru byte sırasıyla mı verilmiş? Test vektöründeki hex değerleri binary olarak mı kullanılmış, yoksa yanlışlıkla ASCII metin olarak mı işlenmiş?

Doğru durumda ciphertext ve tag test vektörüyle tam olarak eşleşir. Bu, seçilen test koşulu için implementasyonun beklenen AES-GCM davranışını ürettiğini gösterir. Fakat bu sonuç, uygulamanın tüm güvenliğini kanıtlamaz. Nonce yönetimi, anahtar ömrü, hata davranışı, yan kanal direnci ve protokol entegrasyonu ayrıca incelenmelidir.

Riskli durumda tag uzunluğu beklenenden kısa olabilir, AAD hiç işlenmemiş olabilir veya IV yanlış uzunlukta verilmiş olabilir. Daha sinsi bir hata, test vektöründeki hex değerlerin binary veri yerine ASCII karakter dizisi olarak şifrelenmesidir. Bu durumda kütüphane teknik olarak çalışır, fakat test vektörüyle eşleşmez.

OpenSSL tarafında API versiyonu ve kullanılan çağrı sırası dikkatle okunmalıdır. AEAD modlarında tag üretimi, tag ayarı, AAD işleme ve finalization adımları sıraya duyarlıdır. Bu nedenle yalnızca “şifreleme başarılı” çıktısı yeterli değildir; parametrelerin doğru verildiği ve tag’in doğru şekilde alınıp doğrulandığı ayrıca kontrol edilmelidir.

libsodium API Güvenlik Analizi — Güvenli ve Tehlikeli API Ayrımı

libsodium, AES-GCM ve ChaCha20-Poly1305 için yüksek seviye AEAD API’ları sağlar. Bu API’ların güvenli kullanım sınırlarını anlamak, OpenSSL EVP veya Python cryptography hazmat gibi daha düşük seviye kütüphanelerle karşılaştırmalı değerlendirme yapmak için önemlidir.

Komut / Araç Görünümü: crypto_aead_chacha20poly1305_ietf_encrypt, crypto_aead_aes256gcm_encrypt ve benzeri AEAD fonksiyon imzaları.

Platform / Araç: libsodium kütüphanesi API dokümantasyonu ve uygun dil bağlantıları.

Amaç: Nonce parametresinin fonksiyon imzasında nasıl konumlandırıldığını, kütüphanenin nonce benzersizliğini uygulamaya bırakıp bırakmadığını, tag uzunluğunun sabit mi yapılandırılabilir mi olduğunu ve AAD’nin nasıl işlendiğini anlamaktır.

Bu inceleme gerçek anahtar veya gerçek kullanıcı verisi kullanmadan yapılmalıdır. Kod örnekleri yalnızca API yapısını anlamak için öğretici biçimde hazırlanmalı; üretim anahtarları veya hassas mesajlar test kodlarına taşınmamalıdır.

Öğrenci çıktıda nonce parametresinin zorunlu olup olmadığına, nonce boyutunun sabitlerle nasıl tanımlandığına, tag uzunluğunun değiştirilip değiştirilemediğine ve AAD’nin fonksiyon çağrısında açıkça yer alıp almadığına bakmalıdır. crypto_aead_chacha20poly1305_IETF_NPUBBYTES gibi sabitler, nonce boyutunun kütüphane tarafından nasıl belirlendiğini gösterir.

Güvenli kullanımda kütüphane nonce boyutunu ve tag uzunluğunu net biçimde tanımlar; uygulama bu değerleri keyfi şekilde değiştiremez. Ancak nonce’un benzersiz olmasını sağlamak çoğu zaman uygulamanın sorumluluğundadır. Bu sorumluluk sayaç, oturum kimliği, cihaz kimliği, mesaj sırası veya daha geniş nonce alanına sahip bir algoritma seçimiyle yönetilebilir.

“libsodium güvenli kütüphanedir, dolayısıyla her kullanımda nonce otomatik yönetilir” çıkarımı yapılmamalıdır. Kütüphane güvenli API tasarımı sunabilir, fakat nonce üretiminin mimari olarak nasıl garanti edildiği uygulama tasarımının parçasıdır. Bu ayrım, güvenli kütüphane ile güvenli kullanım arasındaki farkı gösterir.

İleri Seviye Güvenli Analiz / Kontrol Listesi

Hazırlık

Bir sistemde simetrik şifreleme değerlendirmesi yaparken ilk adım hangi algoritmanın, hangi modun ve hangi kütüphanenin kullanıldığını tespit etmektir. Bu bilgi çoğunlukla cipher suite, API çağrısı, yapılandırma dosyası, protokol dokümanı veya kaynak kodu incelenerek elde edilir. Yalnızca “AES kullanıyoruz” bilgisi analiz için yetersizdir; mod, IV/nonce yönetimi, tag uzunluğu, AAD kullanımı ve hata davranışı da sorgulanmalıdır.

Kontrol Edilecek Noktalar

Kullanılan mod AEAD mı, yoksa salt şifreleme mi? Eğer AEAD değilse bütünlük kontrolü ayrıca nasıl yapılıyor? Bu yapı Encrypt-then-MAC mi, MAC-then-Encrypt mi, yoksa anahtarsız hash gibi güvenlik sağlamayan bir yöntem mi?

Nonce veya IV her şifreleme işleminde doğru koşulu sağlıyor mu? CBC için IV tahmin edilemez biçimde mi üretiliyor? GCM, CTR veya ChaCha20-Poly1305 için nonce aynı anahtar altında kesinlikle tekrar etmeyecek şekilde mi yönetiliyor? Sayaç tabanlı nonce kullanılıyorsa sayaç yeniden başlatma, snapshot geri dönüşü veya çoklu instance çakışması durumunda tekrar riski var mı?

Authentication tag uzunluğu güvenlik politikasıyla uyumlu mu? GCM’de kısa tag kullanımı varsa bunun protokol gerekçesi, standart uyumu ve saldırı yüzeyi değerlendirilmiş mi? AAD kullanılıyor mu? Kullanılmıyorsa, mesaj tipi, protokol sürümü, yön bilgisi veya oturum bağlamı gibi şifrelenmeyen ama bütünlüğü korunması gereken alanlar başka şekilde korunuyor mu?

Hata mesajları şifre çözme hatası, padding hatası, tag doğrulama hatası ve format hatası arasında ayrım yapıyor mu? Yanıt süresi farklılıkları timing oracle oluşturuyor mu? Doğrulanmamış plaintext herhangi bir aşamada loglanıyor, ayrıştırılıyor veya iş mantığına iletiliyor mu?

Güvenli Doğrulama

NIST CAVP veya ilgili RFC test vektörleriyle kütüphane çıktısını karşılaştırmak temel doğrulama adımlarından biridir. Ciphertext, tag, nonce ve AAD alanları protokol belgesindeki serileştirme biçimiyle karşılaştırılmalıdır. Ancak test vektörü uyumu güvenli kullanımın tamamını kanıtlamaz. Nonce üretimi, anahtar yönetimi ve hata davranışı ayrıca test edilmelidir.

Kütüphanenin AES-NI veya eşdeğer donanım hızlandırmasını kullanıp kullanmadığı da kontrol edilebilir. Performansın beklenenden çok daha düşük olması, AES-NI’ın devre dışı kaldığının veya yazılım tabanlı tablo kullanan bir implementasyona düşüldüğünün işareti olabilir. Bu durum hem performans hem de yan kanal riski açısından incelenmelidir.

Not Alınacak Gözlemler

ECB modu kullanan bir sistem güvenlik bulgusu olarak not edilmeli ve değiştirilmesi güçlü biçimde önerilmelidir. Bu yalnızca “daha iyi bir mod var” meselesi değildir; ECB semantik güvenliği sağlamadığı için veri desenlerini sızdırır.

Tag uzunluğunun 128-bit altında yapılandırılmış olması, uygulama tarafındaki bilinçli ve standartla gerekçelendirilmiş bir karar mı, yoksa hatalı varsayılan mı olduğu açısından araştırılmalıdır. GCM’de kısa tag kullanımı sahtecilik direncini düşürür ve modern NIST revizyon eğilimleri de kısa tag kullanımına daha temkinli yaklaşmaktadır.

3DES/TDEA kullanan sistemler yeni kriptografik koruma açısından kullanımdan kaldırılmış kabul edilmeli; RC4 kullanan TLS sistemleri ise RFC 7465 kapsamında ciddi uyumsuzluk olarak raporlanmalıdır. Bu bulgular, yalnızca tarama aracının verdiği düşük seviye uyarılar gibi değil, gerçek protokol ve standart riski olarak ele alınmalıdır.

Yanlış Yorumlama Riskleri

“Şifreleme var, dolayısıyla sistem güvenlidir” çıkarımı bu modülde ele alınan her saldırı sınıfıyla çürütülür. Şifreleme algoritmasının güçlü olması, modun doğru seçildiği, nonce’un doğru yönetildiği, bütünlük kontrolünün doğru yapıldığı veya hata davranışının güvenli olduğu anlamına gelmez.

AEAD kullanılıyor olması da tek başına yeterli değildir. Nonce tekrar ediyorsa, tag doğrulaması atlanıyorsa, doğrulanmamış plaintext işleniyorsa veya AAD’ye konması gereken bağlam bilgisi dışarıda bırakılıyorsa AEAD’nin güvenlik garantisi zayıflar.

Kütüphanenin “güvenli” olarak etiketlenmesi, kullanım biçiminin güvenli olduğu anlamına gelmez. Güvenli API, hatalı kullanım ihtimalini azaltır; fakat mimari düzeyde nonce çakışması, anahtar yeniden kullanımı veya yanlış protokol tasarımı hâlâ uygulama sorumluluğundadır.

Geliştirici / Güvenlik Ekibi / Mimari Ekip İçin Öneri Dili

Bir sistemin CBC+MAC veya CBC+hash yapısından AEAD’ye geçiş önerisi şöyle aktarılabilir:

“Mevcut yapıda şifreleme ve bütünlük kontrolü ayrı katmanlarda uygulanıyor. Bu yapı doğru implemente edilmediğinde padding oracle, bit-flipping ve hata mesajı kaynaklı oracle riskleri doğuruyor. Modern AEAD şemaları gizlilik ve bütünlük kontrolünü tek bir standart arayüzde birleştirerek uygulama karmaşıklığını azaltır. Geçiş yapılacaksa AES-GCM veya ChaCha20-Poly1305 gibi bir AEAD seçilmeli; nonce yönetimi, tag uzunluğu, AAD alanları ve hata mesajı davranışı birlikte tanımlanmalıdır.”

Bu dil, “mevcut sistem tamamen kırık” gibi abartılı bir ifade kullanmadan, riskin hangi teknik karardan kaynaklandığını ve önerilen değişikliğin neyi düzelttiğini açıklar.

Analitik Senaryo

Durum

Bir dahili API servisi, istemcilerden gelen şifreli veriyi çözdükten sonra işliyor. Sistem belgelerine göre AES-256-CBC kullanılıyor. Bütünlük kontrolü için paketin yanında anahtarsız SHA-256 hash değeri saklanıyor. Güvenlik değerlendirmesi sırasında servis yanıtlarının incelenmesi, padding hatası durumunda farklı bir HTTP yanıt kodu döndürdüğünü ortaya koyuyor.

İlk Değerlendirme

Bu yapıda iki ayrı risk katmanı vardır. Birincisi, anahtarsız hash bütünlük sağlamaz. Saldırgan ciphertext’i değiştirebiliyorsa hash değerini de yeniden hesaplayabilir. Bu nedenle SHA-256 gibi güçlü bir hash fonksiyonu kullanılmış olsa bile, anahtarsız kullanım MAC yerine geçmez.

İkinci risk, padding hatasının farklı bir HTTP yanıt kodu üretmesidir. Bu davranış oracle oluşturabilir. Saldırgan, farklı ciphertext varyasyonları göndererek padding’in geçerli olup olmadığını gözlemleyebilir ve bu bilgiyi plaintext kurtarma sürecinde kullanabilir.

Kontrol Edilecek Noktalar

Padding hatası ile başka bir şifre çözme hatası arasındaki yanıt farkı tutarlı mı? Hata kodunun yanı sıra yanıt süresi de farklı mı? Uygulama exception mesajlarını dışarıya yansıtıyor mu? Log sistemi hassas hata ayrıntılarını erişilebilir bir yere yazıyor mu?

IV nasıl iletiliyor? Sabit mi, her mesaj için ayrı mı, ciphertext’in başına mı ekleniyor, yoksa başka bir kanaldan mı geliyor? IV tahmin edilebilir veya tekrar edebilir mi? CBC için IV’nin doğru üretimi, IND-CPA güvenliği açısından önemlidir.

Hash doğrulaması hangi sırada yapılıyor? Hash anahtarsız olduğu için zaten güvenilir bir bütünlük mekanizması değildir; fakat akış sırası yine de saldırı yüzeyini etkiler. Uygulama önce şifre çözme yapıyor, padding kaldırıyor, sonra hash kontrol ediyorsa padding oracle riski daha belirgin hâle gelir.

İncelenecek Yapı

API dokümantasyonu ve kaynak kodu üzerinden şifre çözme akışının sırası incelenmelidir. Paket alındıktan sonra IV ayrıştırılıyor mu? Ciphertext doğrudan decrypt ediliyor mu? Padding kaldırma işlemi nerede yapılıyor? Hash neyin üzerinden hesaplanıyor? Hata türleri hangi HTTP durum kodlarına bağlanmış?

Ayrıca hash’in neden MAC gibi kullanıldığı sorgulanmalıdır. Eğer amaç bütünlükse HMAC gibi anahtarlı bir MAC gerekir. Eğer amaç yalnızca hata tespitiyse bile kriptografik saldırgan modeli altında anahtarsız hash’in güvenlik sağlamadığı açıkça belirtilmelidir.

Güvenli Doğrulama Yaklaşımı

Mevcut yapının riskini doğrulamak için yalnızca izinli lab ortamında aynı mimari kurulabilir. Uydurma anahtarlar ve test verileriyle farklı padding değerleri denenerek yanıt kodu ve yanıt süresi farkları gözlemlenebilir. Bu test gerçek üretim sistemine uygulanmamalıdır; çünkü üretim sistemine çok sayıda hatalı ciphertext göndermek hem etik hem operasyonel risk oluşturabilir.

Doğrulama sırasında amaç saldırıyı istismar etmek değil, sistemin oracle davranışı üretip üretmediğini kanıtlamaktır. Eğer hata yanıtları ayrışıyorsa ve bu ayrım tutarlıysa, bulgu güvenlik ekibine “padding oracle riski” olarak aktarılmalıdır.

Yanlış Yorumlama İhtimali

“SHA-256 kullanılıyor, dolayısıyla bütünlük korunuyor” çıkarımı hatalıdır. SHA-256 güçlü bir hash fonksiyonu olabilir; fakat anahtarsız hash, saldırganın veriyi değiştirip yeni hash hesaplamasını engellemez. Bütünlük ve otantiklik için HMAC gibi anahtarlı MAC veya doğrudan AEAD gerekir.

“AES-256 kullanıyoruz, bu yüzden güvenliyiz” yorumu da eksiktir. AES-256 güçlü bir blok şifredir; fakat CBC modunda bütünlük sağlamaz, padding oracle riskini tek başına engellemez ve hatalı IV/hata yönetimi sorunlarını çözmez.

Riskin Pratik Karşılığı

Padding oracle mantığı üzerinden plaintext kurtarma, anahtar bilgisi gerektirmeden gerçekleştirilebilir. Saldırgan hedef ciphertext’in bloklarını manipüle eder, sistemin hata davranışını gözlemler ve bu yanıtları kullanarak plaintext hakkında bilgi çıkarır. Bu yalnızca gizlilik değil, API güvenliği açısından da ciddi bir problemdir.

Bütünlük koruması olmadığı için bit-flipping saldırıları da gündeme gelebilir. Saldırgan belirli ciphertext bitlerini değiştirerek çözülen plaintext içinde kontrollü değişiklikler oluşturabilir. Uygulama bu plaintext’i doğrulamadan işliyorsa yetki, rol, tutar, bayrak veya yapılandırma alanları manipüle edilebilir.

Önerilen Güvenli Yaklaşım

Servis mimarisine AES-256-GCM veya uygun başka bir AEAD şemasına geçiş önerilmelidir. Bu değişiklik, şifreleme ve bütünlük kontrolünü tek bir standart yapıda birleştirir. Nonce yönetimi için her istek başına benzersiz 96-bit nonce politikası tanımlanmalı; bu benzersizlik CSPRNG, sayaç veya protokol tarafından garanti edilen bir yöntemle sağlanmalıdır. Yüksek hacimli veya dağıtık sistemlerde yalnızca rastgele nonce’a güvenmek yerine sayaç/instance ayrımı veya anahtar türetme stratejisi ayrıca değerlendirilmelidir.

Nonce, ciphertext, tag ve AAD alanlarının servis protokolünde nasıl taşınacağı açıkça belgelenmelidir. Mesaj tipi, protokol sürümü, istemci kimliği veya oturum bağlamı gibi şifrelenmeyen ama bütünlüğü korunması gereken alanlar AAD’ye dahil edilmelidir.

Tüm şifre çözme ve doğrulama hataları tek bir genel hata yanıtında birleştirilmelidir. Uygulama, tag doğrulaması başarısızsa plaintext’i hiçbir şekilde işlememeli, ayrıştırmamalı ve loglamamalıdır. Böylece padding oracle, bit-flipping ve anahtarsız hash kullanımından kaynaklanan riskler yapısal olarak azaltılır.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

SubBytes AES’in doğrusal olmayan byte dönüşüm adımı; S-box aracılığıyla confusion sağlar.

ShiftRows AES durum matrisinin satırlarını kaydıran permütasyon adımı; MixColumns ile birlikte diffusion’ı destekler.

MixColumns Her sütunu GF(2⁸) üzerinde matris çarpımıyla dönüştüren adım; difüzyonun ana kaynaklarından biridir.

AddRoundKey Durum matrisini round key ile XOR’layan adım; anahtarı şifreleme sürecine dahil eder.

Key Schedule Ana anahtardan tur anahtarlarını türeten süreç.

Round key Her AES turunda kullanılan alt anahtar; ana anahtar gibi gizli kabul edilir.

Confusion Anahtar ile şifreli metin arasındaki ilişkiyi karmaşık ve doğrusal olmayan hâle getirme ilkesi.

Diffusion Düz metin istatistiklerini şifreli metin boyunca yayma ilkesi.

S-box Substitution box; doğrusal olmayan byte yer değiştirme tablosu.

Afin dönüşüm Doğrusal dönüşüme sabit terim eklenmiş dönüşüm; AES S-box yapısında kullanılır.

MDS matrisi Maximum Distance Separable matris; MixColumns’un güçlü difüzyon özelliğini destekler.

AES-NI Intel/AMD işlemcilerde AES işlemlerini donanım talimatlarıyla hızlandıran komut seti uzantısı.

AEAD Authenticated Encryption with Associated Data; gizlilik ve bütünlüğü tek yapıda sağlayan şifreleme yaklaşımı.

Authentication tag AEAD şemalarının verinin değiştirilmediğini doğrulamak için ürettiği doğrulama etiketi.

Associated data (AAD) Şifrelenmeyen ama AEAD kapsamında bütünlüğü/otantikliği korunan ek veri alanı.

Nonce misuse Nonce değerinin aynı anahtar altında hatalı biçimde tekrar kullanılması veya yanlış yönetilmesi.

Nonce reuse Aynı nonce değerinin aynı anahtar altında birden fazla şifreleme işleminde kullanılması.

AES-GCM AES Counter Mode ile GHASH authentication mekanizmasını birleştiren yaygın AEAD modu.

GHASH AES-GCM’nin Galois alanı üzerindeki polinom tabanlı authentication bileşeni.

AES-GCM-SIV Nonce misuse-resistant AEAD yapısı; RFC 8452’de tanımlanmıştır.

SIV Synthetic IV; veri ve nonce üzerinden türetilen sentetik başlangıç değeri/tag yaklaşımı.

POLYVAL AES-GCM-SIV’de kullanılan polinom tabanlı authentication fonksiyonu.

ChaCha20-Poly1305 ChaCha20 stream cipher ile Poly1305 MAC’in birleşimi olan AEAD yapısı.

Poly1305 One-time key kullanımına dayanan kriptografik MAC.

Padding oracle Şifre çözme veya padding hatalarının saldırgana oracle işlevi görmesi; CBC modunda plaintext kurtarmaya olanak tanıyabilir.

Bit-flipping Ciphertext bitlerinin değiştirilmesiyle plaintext üzerinde kontrollü değişiklik üretmeye çalışan saldırı sınıfı.

Meet-in-the-middle Çoklu şifreleme yapılarında ara değerleri kullanarak güvenlik kazanımını düşüren saldırı tekniği.

Mode misuse Şifreleme modunun yanlış veya güvenlik hedefine uygun olmayan bağlamda kullanılması.

Encrypt-then-MAC Önce şifreleyip ardından ciphertext üzerinden MAC hesaplama yaklaşımı.

MAC-then-Encrypt Önce MAC hesaplayıp ardından mesajı ve MAC’i şifreleme yaklaşımı; hatalı kullanımda oracle riskleri doğurabilir.

Anahtarsız hash SHA-256 gibi hash fonksiyonlarının anahtar olmadan kullanımı; tek başına otantiklik sağlamaz.

HMAC Anahtarlı hash tabanlı MAC yapısı; bütünlük ve otantiklik için kullanılır.

CAVP Cryptographic Algorithm Validation Program; NIST’in kriptografik algoritma doğrulama programı.

SWEET32 64-bit blok şifrelere karşı birthday-bound etkisini kullanan saldırı sınıfı; 3DES/TDEA riskini görünür kılmıştır.

Constant-time comparison Karşılaştırma sonucundan bağımsız olarak aynı sürede tamamlanması hedeflenen işlem; timing oracle riskini azaltır.

hazmat API Python cryptography kütüphanesinin düşük seviye ve dikkat gerektiren kriptografik işlemler için kullandığı API kategorisi.

EVP API OpenSSL’in yüksek seviye kriptografik işlem arayüzü; AEAD modları için doğru kullanım noktalarından biridir.

openssl enc OpenSSL komut satırı aracı; GCM/CCM gibi AEAD modlarını desteklemediği için AES-GCM doğrulaması için uygun değildir.

RC4 TLS bağlamında kullanımı RFC 7465 ile yasaklanmış eski stream cipher.

TDEA / 3DES Triple DES; NIST tarafından yeni kriptografik koruma için kullanımdan kaldırılmış eski blok şifre.

Kendini Değerlendir — İleri Kriptografi Modül 2

Bu Modülde Neler Öğrendik?

Bu modül simetrik kriptografiyi kara kutu seviyesinden çıkararak tasarım kararları, güvenlik modeli ve uygulama riski düzeyine taşıdı.

AES’in iç yapısını anlayan öğrenci artık confusion ve diffusion kavramlarını somut adımlarla ilişkilendirebilir. SubBytes’in doğrusal olmayan S-box yapısıyla confusion sağladığını, ShiftRows ve MixColumns’un diffusion hedefini desteklediğini, AddRoundKey’in anahtarı şifreleme sürecine bağladığını ve Key Schedule’ın round key üretimi için neden önemli olduğunu açıklayabilir.

AES-NI’ın yalnızca performans avantajı değil, tablo tabanlı cache timing risklerini azaltan bir uygulama avantajı sunduğunu; buna rağmen tüm yan kanal ve uygulama güvenliği risklerini tek başına ortadan kaldırmadığını değerlendirebilir.

AEAD güvenlik hedeflerini kavrayan öğrenci, AES-GCM, AES-GCM-SIV ve ChaCha20-Poly1305 arasındaki seçimi “hangisi daha popüler” sorusuna göre değil, “hangi güvenlik garantisi gerekiyor, nonce yönetimi nasıl kontrol ediliyor ve uygulama ortamı hangi performans koşullarına sahip” sorularına göre yapabilir hâle gelir.

Nonce tekrarının AES-GCM’de yalnızca gizliliği değil, authentication tag güvenliğini de yıktığını teknik düzeyde açıklayabilir. AES-GCM-SIV’in nonce tekrarını teşvik etmediğini, fakat nonce benzersizliğinin garanti edilemediği ortamlarda hasarı sınırlayan farklı bir güvenlik modeli sunduğunu anlayabilir. ChaCha20-Poly1305’te nonce tekrarının hem keystream tekrarına hem de Poly1305 one-time key tekrarına yol açtığını ve bu nedenle gizlilik ile bütünlük/otantiklik güvenliğini birlikte tehlikeye attığını ifade edebilir.

Padding oracle ve bit-flipping saldırılarının mekanizmasını anlayan öğrenci, bu saldırıların kaynak aldığı tasarım hatalarını tanıyabilir: bütünlük kontrolünün eksik olması, doğrulanmamış plaintext’in işlenmesi, farklı hata türlerini ayırt eden yanıtların dışarıya sızdırılması veya anahtarsız hash’in MAC gibi kullanılması. Bu hataların üretim sistemlerinde ne anlama geldiğini ve neden AEAD geçişinin savunma açısından temiz bir cevap olduğunu gerekçelendirebilir.

Test vektörü okuma becerisini edinen öğrenci, NIST veya RFC tabanlı vektörlerde Key, IV/nonce, Plaintext, AAD, Ciphertext ve Tag alanlarını ayırabilir. Kütüphane çıktısıyla standart çıktı arasındaki farkları yorumlayabilir; hex verinin yanlışlıkla ASCII olarak işlenmesi, tag’in eksik alınması veya AAD’nin unutulması gibi uygulama hatalarını fark edebilir.

OpenSSL ve libsodium API’larını okuyan öğrenci, güvenli API ile düşük seviye tehlikeli API ayrımını tanır. OpenSSL enc aracının AES-GCM/CCM gibi AEAD modları için uygun olmadığını, AES-GCM testlerinin EVP API veya AEAD destekleyen uygun test kodu üzerinden yapılması gerektiğini bilir. libsodium gibi güvenli varsayımları teşvik eden kütüphanelerde bile nonce yönetiminin uygulama sorumluluğu olduğunu anlar.

Son olarak öğrenci, eski algoritmaların kurumsal riskini standart diliyle aktarabilir. 3DES/TDEA’nın yeni kriptografik koruma için uygun olmadığını, RC4’ün TLS bağlamında yasaklandığını, ECB’nin semantik güvenlik sağlamadığını ve bu bulguların yalnızca “eski algoritma kullanılmış” şeklinde değil, gerçek saldırı yüzeyi ve standart uyumsuzluğu olarak raporlanması gerektiğini açıklayabilir.

MODÜL 3 — İleri hash, MAC, KDF ve parola güvenliği

Modül özeti

Hash ve MAC seçimini güvenlik özelliği ve kullanım bağlamıyla birlikte; parola tarafında ise offline saldırgan modeli ve maliyet parametreleriyle değerlendirmeyi öğretir.

Modül 3 — İleri Hash, MAC, KDF ve Parola Güvenliği

Temel kriptografi eğitiminde hash fonksiyonları, MAC ve KDF yapıları çoğunlukla “ne işe yarar?” sorusunun cevabı olarak öğretilir. Bu modül o soruyu aşar ve konuyu “hangi güvenlik özelliği ne zaman bozulur, hangi yapısal seçim hangi saldırı yüzeyini açar, parametre seçimi güvenliği nasıl etkiler?” düzeyine taşır. Birthday paradox’tan length extension’a, HMAC güvenlik mantığından HKDF’nin extract/expand ayrımına, bcrypt’ten Argon2id’e kadar bu modülde her yapı hem saldırı modeli hem de güvenli tasarım bakışıyla ele alınır.

Hash güvenliği yalnızca “çıktı ne kadar uzun?” sorusuna indirgenemez. Collision direnci, preimage direnci ve second preimage direnci üç ayrı özellik olarak anlaşılmadan güvenlik modeli doğru okunamaz. Benzer biçimde MAC seçimi ve parametre belirleme yalnızca doğru algoritmanın seçilmesini değil, timing-safe doğrulama ve zamanlama sızıntısı risklerini de kapsayan bir kararı temsil eder. KDF yapılarında domain separation, salt kullanımı, info parametresi ve çıktı uzunluğu gibi detaylar yanlış ele alındığında anahtar malzemenin bağlamlar arasında karışmasına zemin hazırlayabilir.

Modül, parola güvenliği tarafında memory-hard yapıların neden ortaya çıktığını ve Argon2id’in neden güçlü bir modern tercih olduğunu güvenlik modeli ve saldırgan modeli açısından açıklar. OWASP Argon2id için güncel minimum başlangıç olarak 19 MiB bellek, 2 iterasyon ve 1 paralellik değerini önerirken, RFC 9106 daha yüksek güvenlik için Argon2id’de 2 GiB/t=1 seçeneğini ve bellek kısıtlı ortamlar için 64 MiB/t=3 seçeneğini verir; bu ayrım modülde özellikle netleştirilmiştir.

Son bölümde araç çıktılarını okuma ve parametre yorumlama pratiği, bu konunun gerçek sistemlerdeki karşılığını somutlaştırmak için kullanılır. Öğrenci yalnızca “Argon2id kullanılıyor” veya “HMAC var” gibi yüzeysel sonuçlarla yetinmez; salt, cost, memory, iteration, info, tag doğrulaması ve hata yönetimi gibi güvenliği belirleyen ayrıntıları birlikte değerlendirir.

Kazanımlar

Bu modül sonunda öğrenci:

Birthday paradox ve birthday attack’ın hash güvenlik seviyesiyle matematiksel ilişkisini açıklayabilir; n-bit hash fonksiyonu için collision ve preimage güvenlik düzeylerini doğru ifade edebilir.

Collision direnci, preimage direnci ve second preimage direncini birbirinden ayırabilir; bu özelliklerin dijital imza, belge bütünlüğü, parola doğrulama ve sertifika senaryolarındaki etkisini değerlendirebilir.

Length extension saldırısının Merkle-Damgård yapısından nasıl kaynaklandığını ve SHA-2 ile SHA-3’ün bu konuda nasıl farklılaştığını güvenlik modeli bağlamında karşılaştırabilir.

HMAC, CMAC, Poly1305 ve KMAC yapılarını güvenlik varsayımları, bağımlı oldukları ilkel, anahtar yönetimi ve timing-safe doğrulama gereklilikleri açısından değerlendirebilir.

HKDF’nin extract ve expand aşamalarının hangi amaçla ayrıldığını, salt ve info parametrelerinin hangi güvenlik rollerini üstlendiğini ve domain separation için neden kritik olduklarını analiz edebilir.

PBKDF2, bcrypt, scrypt ve Argon2id yapılarını saldırgan modeli, özellikle GPU/ASIC destekli çevrimdışı parola tahmini açısından karşılaştırabilir.

Argon2id parametre üçlüsünü — zaman maliyeti, bellek maliyeti ve paralellik — hem güvenlik hem de performans açısından yorumlayabilir; yetersiz parametre seçiminin doğurduğu riski ifade edebilir.

Hash ve parola hashing araçlarının ürettiği çıktıda salt, cost, memory, iteration, hash ve format alanlarını ayırt edebilir; bu çıktıyı standart belgeler ve güncel rehberlerle ilişkilendirebilir.

XOF kavramını ve SHAKE fonksiyonlarının geleneksel sabit uzunluklu hash fonksiyonlarından hangi senaryolarda ayrıldığını açıklayabilir.

MAC doğrulama başarısızlıklarının nasıl ele alınması gerektiğini ve hata mesajlarının kriptografik sızıntı riskini tartışabilir.

Bir sistemde hash, MAC, KDF veya parola hashing seçimi yapılırken güvenlik modeli, performans, standart uyumu, migration planı ve uzun vadeli agility gereksinimlerini birlikte değerlendiren teknik bir öneri hazırlayabilir.

Hash Güvenliği Analizi

Kriptografik hash fonksiyonlarının üç temel güvenlik özelliği vardır: preimage direnci, second preimage direnci ve collision direnci. Bu üç özellik birbirine benzese de aynı şey değildir. Bu ayrımı yüzeysel geçmek, “güçlü hash kullanıyoruz” cümlesinin pratikte ne anlama geldiğini belirsizleştirir.

Preimage direnci, bir hash çıktısı h verildiğinde H(m) = h olacak şekilde bir m girdisi bulmanın hesaplama açısından zor olmasıdır. n-bit çıktı üreten ideal bir hash fonksiyonu için preimage araması yaklaşık 2ⁿ deneme seviyesinde değerlendirilir. Ancak parola saklama senaryosunda bu teorik seviye tek başına yeterli bir güvenlik açıklaması değildir. Parolalar genellikle düşük entropilidir; saldırgan 2ⁿ büyüklüğünde rastgele bir uzayı değil, sızıntı listeleri, sözlükler, kalıplar ve brute-force adayları üzerinden gerçek parola uzayını dener. Bu yüzden parola saklamada sıradan hızlı hash yerine salt’lı, maliyet parametreli ve tercihen memory-hard parola hashing yapıları kullanılmalıdır. NIST SP 800-63B de parola doğrulayıcılarının offline saldırılara dirençli olacak şekilde salt ve cost factor içeren uygun parola hashing şemalarıyla saklanmasını ister.

Second preimage direnci, bir mesaj m₁ verildiğinde m₁ ≠ m₂ olacak ve H(m₁) = H(m₂) sağlayacak farklı bir m₂ bulmanın zor olmasıdır. Önceden imzalanmış belirli bir belgeye aynı hash’i veren başka bir belge bulmaya çalışmak second preimage problemidir. Buna karşılık saldırganın iki farklı belgeyi baştan birlikte tasarlayıp aynı hash değerine getirmesi collision veya daha güçlü biçimde chosen-prefix collision bağlamına girer. Dijital imzalarda özellikle collision direnci kritiktir; çünkü imza çoğu zaman belgenin kendisi yerine belgenin hash’i üzerinde üretilir.

Collision direnci, H(m₁) = H(m₂) sağlayan herhangi bir m₁ ≠ m₂ çiftini bulmanın zor olmasıdır. Burada saldırgan herhangi iki mesajı seçme özgürlüğüne sahip olduğu için işi preimage aramasına göre daha kolaydır. Birthday paradox bu farkın matematiksel kaynağıdır.

Birthday paradox, sezgiye aykırı görünen ama kriptografide çok önemli olan bir olasılık sonucudur. n farklı değerin yer aldığı bir uzaydan rastgele seçilen yaklaşık √n elemandan oluşan bir örnekte çakışma olasılığı anlamlı düzeye çıkar. Hash güvenliğine uyarlarsak, n-bit çıktı üreten ideal bir hash fonksiyonunda collision araması yaklaşık 2^(n/2) karmaşıklığındadır. Bu yüzden 128-bit collision güvenliği hedefleniyorsa yaklaşık 256-bit hash çıktısı gerekir. 128-bit hash çıktısı collision açısından yaklaşık 64-bit güvenlik sunar.

Güvenlik özelliği n-bit ideal hash için yaklaşık maliyet Pratik etki

Preimage direnci 2ⁿ Hash çıktısından girdiyi bulmayı zorlaştırır; parola senaryosunda parola entropisi ve KDF maliyeti ayrıca belirleyicidir.

Second preimage direnci 2ⁿ Önceden bilinen belirli bir mesaja aynı hash’i veren başka mesaj bulmayı zorlaştırır.

Collision direnci 2^(n/2) İki farklı girdiye aynı hash’i bulmayı zorlaştırır; dijital imza ve sertifika senaryolarında özellikle kritiktir.

SHA-256, collision açısından yaklaşık 128-bit güvenlik düzeyi sunar. SHA-384 ve SHA-512 daha geniş çıktı uzunluklarıyla daha yüksek collision güvenlik marjı sağlar. NIST SP 800-131A Rev. 2, SHA-224, SHA-256, SHA-384, SHA-512 ve SHA-3 ailesini hash uygulamaları için kabul edilebilir olarak listelerken SHA-1 için kullanım amacına göre ayrımlar yapar. SHA-1 dijital imza üretimi için genel olarak kullanılmamalıdır; dijital imza doğrulamada legacy kullanım ayrı değerlendirilir ve collision resistance gerektirmeyen bazı non-digital-signature bağlamlar farklı ele alınır. Bu yüzden “SHA-1 her bağlamda aynı şekilde yasaktır” demek yerine, kullanım amacı ve standart gereksinimi üzerinden değerlendirme yapılmalıdır.

Güncel değerlendirmelerde SP 800-131A Rev. 2 temel geçiş rehberlerinden biri olarak okunabilir; ancak yeni taslaklar, geçiş takvimleri ve algoritma kullanım kısıtları da takip edilmelidir. Bu nedenle SHA-1, kısa güvenlik gücü sunan eski algoritmalar, ECB gibi güvenli olmayan kullanım biçimleri ve legacy uyumluluk kararları değerlendirilirken yalnızca algoritma adına değil, belgenin revizyonuna, kullanım amacına ve geçiş takvimine de bakılmalıdır.

SHA-1 ve MD5, collision resistance gerektiren güvenlik kullanımlarında kabul edilebilir değildir. Kod imzalama, sertifika üretimi, belge imzalama ve güvenlik açısından anlamlı bütünlük doğrulaması gibi senaryolarda bu algoritmaların varlığı ciddi bir geçiş ihtiyacıdır. Buna karşılık legacy identifier, eski kayıt karşılaştırması veya collision resistance gerektirmeyen bazı parmak izi senaryolarında risk bağlama göre değerlendirilir. İleri seviye kriptografi analizi, algoritma adını görür görmez otomatik hüküm vermek yerine hangi güvenlik özelliğinin hedeflendiğini sorar.

MD5 ve SHA-1 üzerinde gösterilen gerçek dünya çakışmaları, collision riskinin yalnızca teorik olmadığını göstermiştir. Bu saldırılar, saldırganın iki farklı içeriği aynı hash değerine getirebildiği durumlarda geçerli bir imzanın veya bütünlük doğrulamasının başka bir içerik için kabul edilmesine yol açabilir. Özellikle chosen-prefix collision saldırıları, iki farklı başlangıç yapısına sahip girdinin aynı hash değerine yönlendirilmesi açısından pratik güvenlik tarihinde önemli bir yere sahiptir.

Hash Tabanlı Saldırılar

Length extension saldırısı, Merkle-Damgård yapısına dayanan hash fonksiyonlarında görülen yapısal bir risktir. MD5, SHA-1, SHA-256 ve SHA-512 gibi fonksiyonlar bu aileye dahildir. Saldırının doğru formülasyonu önemlidir: saldırgan H(m) değerini ve m’nin uzunluğunu biliyor veya tahmin edebiliyorsa doğrudan H(m ‖ ek_veri) değil, H(m ‖ padding(m) ‖ ek_veri) değerini hesaplayabilir. Buradaki padding, Merkle-Damgård yapısının mesajı blok sınırına tamamlamak için eklediği standart dolgudur.

Pratik tehdit şu biçimde ortaya çıkar: bir uygulama kimlik doğrulaması için SHA256(secret ‖ mesaj) gibi naif bir yapı kullanıyorsa, saldırgan secret’ı bilmeden mesaj sonuna ek veri ekleyebilir ve uygun padding ile geçerli görünen yeni bir hash üretebilir. Burada saldırgan gizli iç durumu “geri kazanmaz”; hash çıktısını, Merkle-Damgård yapısındaki son chaining state gibi kullanarak ek veriyi işlemeye devam edebilir.

Bu nedenle H(key ‖ mesaj) biçimindeki prefix-MAC yapısı Merkle-Damgård length extension saldırılarına açıktır. H(mesaj ‖ key) aynı saldırı biçimine doğrudan açık olmasa da standart, analiz edilmiş ve önerilen bir MAC tasarımı değildir; başka yapılandırma riskleri taşır ve güvenli MAC yerine kullanılmamalıdır. Doğru yaklaşım HMAC, CMAC, KMAC veya uygun AEAD yapıları gibi standart ve analiz edilmiş mekanizmalardır.

SHA-2 ailesi Merkle-Damgård yapısını kullandığı için length extension açısından naif kullanımlarda dikkat gerektirir. Fakat SHA-256 veya SHA-512 doğrudan “H(secret ‖ mesaj)” gibi bir MAC yerine HMAC içinde kullanılıyorsa bu açık pratikte devreye girmez. HMAC’in iç ve dış hash yapısı, saldırganın elde ettiği değeri basitçe devam ettirilebilir bir iç durum gibi kullanmasını engeller.

SHA-3 ise Merkle-Damgård yerine sponge construction üzerine kuruludur. FIPS 202, SHA-3 ailesinin dört sabit uzunluklu hash fonksiyonu ve iki XOF fonksiyonundan oluştuğunu; bu fonksiyonların sponge construction yapısını paylaştığını belirtir. Sponge yapısında çıktı, Merkle-Damgård hashlerindeki gibi doğrudan devam ettirilebilir bir chaining state sağlamaz; capacity kısmı ve padding/domain separation yapısı nedeniyle klasik length extension saldırısı uygulanamaz.

SHA-3 çerçevesinin bir parçası olan SHAKE128 ve SHAKE256, sabit uzunlukta değil istenilen uzunlukta çıktı üreten genişletilebilir çıktı fonksiyonlarıdır. Bu yapılara XOF, yani Extendable Output Function denir. SHAKE, değişken uzunluklu çıktı gereken hash-benzeri senaryolarda esneklik sağlar. Ancak anahtarlı türetme, MAC veya açık domain separation gerektiren durumlarda doğrudan “SHAKE ile istediğim kadar byte üretirim” yaklaşımı yerine cSHAKE, KMAC veya standart KDF yapıları tercih edilmelidir. NIST SP 800-185, cSHAKE, KMAC, TupleHash ve ParallelHash’i SHA-3 türev fonksiyonları olarak tanımlar.

SHAKE128 yaklaşık 128-bit, SHAKE256 yaklaşık 256-bit güvenlik seviyesi hedefleyen XOF ailesi üyeleridir. Ancak XOF güvenliği yalnızca kaç byte çıktı alındığına indirgenmez; sponge kapasitesi, fonksiyon seçimi ve kullanım bağlamı belirleyicidir. Çıktı uzunluğu gereksiz yere kısa seçilirse uygulamanın hedeflediği güvenlik özelliği zayıflayabilir.

SHA-3 ve SHAKE’in SHA-2’ye göre pratik avantajı her zaman doğrudan performans değildir. Donanım hızlandırma desteği, standart uyumu, protokol ekosistemi ve kütüphane desteği seçimde belirleyici olur. TLS ve PKI dünyasında SHA-2 hâlâ çok yaygındır; SHA-3 ise farklı yapı, XOF esnekliği veya SHA-3 türev fonksiyonlarına ihtiyaç duyulan tasarımlarda önem kazanır.

MAC Yapıları

MAC, yani Message Authentication Code, bütünlük ve kimlik doğrulamasını birlikte sağlayan kriptografik ilkeldir. Temel kriptografi eğitiminde MAC çoğu zaman “anahtarlı hash” gibi anlatılır; bu başlangıç için yararlı olsa da ileri düzeyde yetersizdir. Asıl soru hangi MAC yapısının hangi güvenlik varsayımlarına dayandığı, anahtarın nasıl yönetildiği, doğrulamanın nasıl yapıldığı ve hata davranışının saldırgana ne sızdırdığıdır.

HMAC, Merkle-Damgård tabanlı hash fonksiyonlarının naif MAC kullanımındaki length extension risklerini ortadan kaldırmak için tasarlanmış standart bir yapıdır. HMAC(K, m) = H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)) biçimindeki iç ve dış hash yapısı, tek bir prefix-hash kullanımından farklıdır. İç hash sonucu tek başına devam ettirilebilir bir MAC değeri gibi kullanılmaz; dış hash aşaması bu değeri anahtarlı ikinci bir bağlama sokar.

HMAC’in güvenliği düz hash collision direnciyle birebir aynı şekilde yorumlanmamalıdır. RFC 2104, HMAC’in kriptografik gücünün kullanılan hash fonksiyonunun özelliklerine ve gizli anahtara bağlı olduğunu belirtir. Anahtarın rastgele, yeterli entropiye sahip ve gizli olması temel gereksinimdir. Çok kısa veya düşük entropili anahtarlar HMAC güvenlik gücünü sınırlar; fakat mesele yalnızca anahtarın hash çıktı uzunluğundan kısa olup olmaması değildir.

HMAC anahtarı hedef güvenlik seviyesiyle uyumlu seçilmelidir. Uygulamada HMAC-SHA256 için 256-bit rastgele bir anahtar güçlü ve yaygın bir tercihtir. Daha uzun anahtarlar hash blok boyutunu aştığında HMAC tanımı gereği önce hashlenir; bu da “ne kadar uzun anahtar, o kadar güvenlik” gibi basit bir yorumun doğru olmadığını gösterir. Anahtar yönetimi, algoritma seçiminden ayrı düşünülmemelidir.

CMAC, AES gibi blok şifreler üzerinde çalışan cipher-based MAC yapısıdır. NIST SP 800-38B tarafından tanımlanmıştır. HMAC’in hash tabanlı olduğu ortamlara karşılık CMAC, AES donanım hızlandırmasının bulunduğu veya sistemde zaten blok şifre altyapısının kullanıldığı bağlamlarda anlamlı olabilir. TLS gibi birçok internet protokolünde tarihsel olarak HMAC baskın olsa da gömülü sistemler, donanım güvenlik modülleri veya blok şifre temelli mimarilerde CMAC tercih edilebilir.

Poly1305, ChaCha20-Poly1305 AEAD yapısının MAC bileşenidir. Poly1305 bir one-time MAC olarak tasarlanmıştır; her mesaj için farklı bir Poly1305 anahtarı kullanılmalıdır. ChaCha20-Poly1305 içinde bu one-time key, ChaCha20 anahtarı ve nonce üzerinden türetilir. Bu yönetim AEAD katmanında doğru yapılırsa güvenlidir; fakat Poly1305 ayrı bir MAC gibi kullanılacaksa anahtar türetme ve anahtar tekrarını engelleme sorumluluğu uygulamaya geçer. Poly1305 anahtarının tekrar kullanılması MAC güvenliğini ciddi biçimde bozar.

KMAC, SHA-3/KECCAK tabanlı anahtarlı hash/MAC ve PRF yapısıdır. NIST SP 800-185; cSHAKE, KMAC, TupleHash ve ParallelHash’i SHA-3 türev fonksiyonları olarak tanımlar. KMAC değişken uzunlukta çıktı üretebilir ve domain separation, cSHAKE/KMAC parametreleriyle açık biçimde kurulabilir. Bu yönüyle KMAC, SHA-3 ekosistemiyle uyumlu, anahtarlı ve özelleştirilebilir bir yapı arayan sistemlerde değer taşır.

MAC doğrulaması sırasında en sık yapılan uygulama hatalarından biri, beklenen MAC ile gelen MAC değerini normal string veya byte karşılaştırmasıyla kontrol etmektir. Karşılaştırma ilk farklı byte’ta duruyorsa, uygun koşullarda saldırgan işlem süresinden kaç byte’ın eşleştiğine dair kısmi bilgi çıkarabilir. Ağ gürültüsü, rate limit ve tag uzunluğu saldırıyı zorlaştırabilir; ancak güvenli tasarım prensibi açıktır: MAC/tag doğrulaması constant-time comparison ile yapılmalıdır.

Python’da hmac.compare_digest(), libsodium’da crypto_verify_* ailesi gibi fonksiyonlar bu amaca hizmet eder. Fakat yalnızca alt seviye karşılaştırmanın constant-time olması yeterli değildir. Üst katmanda “uzunluk yanlışsa hemen dön”, “format yanlışsa farklı hata ver”, “ilk alan doğruysa farklı log üret” gibi erken çıkışlar eklenirse zamanlama ve hata davranışı yine oracle hâline gelebilir.

MAC doğrulama hatası uygulamada ayrıntılı biçimde dışarı verilmemelidir. “MAC uyuşmadı”, “uzunluk hatalı”, “format yanlış”, “anahtar bulunamadı” gibi ayrımlar saldırganın hangi aşamada hata oluştuğunu anlamasına ve davranışı modellemesine yardım edebilir. Dışarıya tek ve genel bir doğrulama başarısızlığı dönmek; ayrıntılı nedeni ise yalnızca güvenli, erişimi sınırlandırılmış iç loglarda tutmak daha doğru yaklaşımdır.

KDF Yapıları

Anahtar türetme fonksiyonları, kriptografik materyali kullanılabilir anahtara dönüştürmek için kullanılır. Temel eğitimde KDF çoğu zaman “şifreden anahtar üretir” şeklinde tanımlanır; ancak bu tanım eksiktir. İleri düzeyde KDF seçimi salt kullanımı, domain separation, çıktı uzunluğu, context binding ve anahtar ayrımı gibi tasarım kararlarını içerir.

HKDF, RFC 5869’da tanımlanan HMAC tabanlı extract-and-expand yapısına sahip bir KDF’dir. İki aşaması vardır: Extract ve Expand. Bu ayrım, ham anahtar materyalini önce daha düzgün bir pseudorandom key’e dönüştürmeyi, ardından bu PRK’dan bağlama özgü anahtarlar üretmeyi sağlar.

Extract aşamasında Input Keying Material, yani IKM, HMAC kullanılarak pseudorandom key’e dönüştürülür. IKM çoğu zaman Diffie-Hellman shared secret gibi doğrudan simetrik anahtar olarak kullanılması uygun olmayan ham bir değerdir. Burada “düşük entropili” ifadesi her zaman doğru değildir; Diffie-Hellman çıktısı düşük entropili kabul edilmez. Asıl mesele, bu ham materyalin dağılımsal ve yapısal olarak doğrudan şifreleme veya MAC anahtarı gibi kullanılmaya uygun olmamasıdır.

HKDF’de salt opsiyoneldir. RFC 5869’a göre salt verilmezse HashLen uzunluğunda sıfır değerli salt varsayılır. Buna rağmen bağımsız ve uygun salt kullanımı extract aşamasını güçlendirir, farklı oturumlar veya bağlamlar arasında ayrımı daha sağlıklı kurar ve güvenlik marjını artırır. Domain separation için ise asıl kritik parametre expand aşamasındaki info değeridir.

Expand aşamasında PRK’dan bağlama özgü anahtar materyali üretilir. info parametresi bu bağlamı kodlar. Örneğin “AES-256-GCM encryption key v1”, “HMAC-SHA256 authentication key v1”, “client traffic key” veya “server traffic key” gibi açık ve ayrıştırılabilir etiketler kullanılabilir. Aynı PRK ve aynı info ile aynı uzunlukta çıktı istenirse aynı çıktı üretilir; bu yüzden farklı amaçlar için aynı info değerinin kullanılması key separation hatasına yol açabilir.

HKDF-Expand çıktısı sınırsız değildir. RFC 5869’a göre üretilecek output keying material uzunluğu en fazla 255 × HashLen olabilir. Bu sınır hash blok boyutu değildir. Bu ayrım önemlidir; çünkü yanlış biçimde “blok boyutunu aşmamalı” demek HKDF’nin teknik sınırını hatalı öğretir.

Pratik bir senaryoda Diffie-Hellman anahtar anlaşmasından elde edilen ham shared secret doğrudan AES veya HMAC anahtarı olarak kullanılmamalıdır. HKDF-Extract bu ham materyali PRK’ya dönüştürür; HKDF-Expand ise farklı amaçlar için ayrı ve bağlama bağlanmış anahtarlar üretir. TLS 1.3 key schedule bu mantığı gerçek protokol seviyesinde gösterir; her traffic secret ve türetilen anahtar farklı label/context bilgileriyle ayrılır.

PBKDF2, PKCS #5 ailesinde tanımlanan, HMAC döngülerine dayalı parola tabanlı anahtar türetme fonksiyonudur. PBKDF2’nin temel amacı, parola tahminlerini saldırgan açısından daha pahalı hâle getirmektir. Ancak PBKDF2 CPU ağırlıklı bir yapıdır; GPU ve ASIC donanımları üzerinde yüksek paralel deneme kapasitesine karşı memory-hard yapılar kadar direnç sağlamaz. Bu nedenle yeni genel amaçlı sistemlerde Argon2id gibi memory-hard yapılar daha güçlü tercihlerdir. FIPS-140 veya eski sistem uyumluluğu gerekiyorsa PBKDF2-HMAC-SHA256 uygun parametrelerle hâlâ kullanılabilir.

PBKDF2 için iterasyon sayısı rehbere ve uyumluluk ihtiyacına göre belirlenir. OWASP Password Storage Cheat Sheet, FIPS-140 uyumluluğu gereken durumlarda PBKDF2-HMAC-SHA256 için 600.000 veya üzeri iterasyon önerir. NIST SP 800-63B ise belirli tek bir iterasyon sayısı vermekten çok, cost factor’ın sistem performansını olumsuz etkilemeyecek en yüksek pratik seviyede seçilmesini ve zamanla artırılmasını ister.

KDF bağlamında salt iki temel fayda sağlar. Birincisi, aynı parolayı kullanan iki kullanıcının aynı hash çıktısına sahip olmasını engeller. İkincisi, önceden hesaplanmış rainbow table saldırılarını pratik dışı bırakır. Salt gizli olmak zorunda değildir; fakat kullanıcıya, hesaba veya oturuma özgü ve yeterince çakışma ihtimali düşük olmalıdır. NIST SP 800-63B minimum 32-bit salt şartı koyar; buna rağmen yeni sistemlerde 128-bit rastgele salt kullanmak güçlü ve yaygın bir modern tercihtir.

Domain separation, aynı temel materyalden farklı amaçlar için türetilen anahtarların birbirinden bağımsız kalmasını sağlayan tasarım prensibidir. HKDF’de info, KMAC/cSHAKE tarafında customization string veya function name parametreleri bu rolü üstlenir. Aynı temel materyalden şifreleme anahtarı, MAC anahtarı ve IV türetilecekse her birinin açıkça farklı bağlama bağlanması gerekir.

Parola Hashing ve Memory-Hard Yapılar

Parola hashing, KDF konusunun özel ve son derece pratik bir alt alanıdır. Buradaki saldırgan modeli nettir: saldırgan bir hash veritabanını ele geçirmiştir ve çevrimdışı ortamda olabildiğince çok parola tahmini yapmak ister. Bu modelde çevrimiçi rate limit, CAPTCHA veya hesap kilitleme mekanizmaları artık devre dışıdır; saldırganın hızını belirleyen şey hash fonksiyonunun maliyeti, salt yapısı, parola entropisi ve kullanılan donanımdır.

SHA-256 ve benzeri genel amaçlı hash fonksiyonları hızlı hesaplama için tasarlanmıştır. Dosya bütünlüğü, imza öncesi özetleme veya veri tanımlama için bu hız avantajdır. Fakat parola saklamada aynı hız saldırganın lehine çalışır. Modern GPU kümeleri hızlı hash fonksiyonlarını çok yüksek hızlarda deneyebilir. Bu nedenle parola saklamak için hızlı hash fonksiyonu değil, parola hashing için tasarlanmış, salt kullanan, maliyet parametresine sahip ve mümkünse memory-hard bir yapı kullanılmalıdır.

bcrypt, 1999’da tasarlanmış ve Blowfish blok şifresini temel alan bir parola hashing algoritmasıdır. cost parametresi hesaplama maliyetini 2^cost ölçeğinde artırır. bcrypt hâlâ yaygın kullanılan ve iyi bilinen bir seçenektir. OWASP, legacy sistemlerde bcrypt kullanılıyorsa work factor değerinin 10 veya üzeri olmasını ve bcrypt’in 72 bayt parola sınırının dikkate alınmasını önerir.

bcrypt’in önemli sınırı, giriş uzunluğu konusunda 72 baytlık sınıra sahip olmasıdır. Daha uzun parolalar bazı implementasyonlarda kesilebilir. Bu durum özellikle uzun passphrase kullanan sistemlerde dikkatle ele alınmalıdır. Ayrıca bcrypt’in bellek kullanımı düşüktür; bu nedenle Argon2id ve scrypt gibi memory-hard yapılara kıyasla GPU/ASIC saldırılarına karşı maliyet yükleme kapasitesi daha sınırlıdır. Buna rağmen doğru cost değeriyle legacy sistemlerde kabul edilebilir bir geçiş seçeneği olabilir.

bcrypt cost değeri donanım üzerinde benchmark edilmelidir. 10 ve üzeri yaygın bir başlangıç noktasıdır; 12–14 aralığı birçok sistemde görülebilir. Ancak bu değerler standart bir zorunluluk gibi yazılmamalıdır. Hedef süre uygulamanın performans gereksinimi, kullanıcı deneyimi, saldırgan modeli ve DoS riskine göre belirlenir. Cost=8 güncel sistemlerde genellikle yetersiz kabul edilir; fakat “anlık hesaplanır” gibi mutlak bir ifade yerine, “modern donanımda offline saldırıyı yeterince yavaşlatmayabilir” demek daha doğrudur.

scrypt, bcrypt’in bellek tarafındaki zayıflığını gidermek için memory-hard bir yapı olarak tasarlanmıştır. N, r ve p parametreleri CPU/bellek maliyetini, blok boyutunu ve paralelliği belirler. Bellek gereksinimi yaklaşık N × r ölçeğinde arttığı için GPU/ASIC saldırılarında her paralel deneme daha pahalı hâle gelir. Güncel OWASP rehberi, Argon2id yoksa scrypt için örnek minimum olarak N=2^17, r=8, p=1 değerini verir. Daha düşük parametreler eski sistemlerde görülebilir; fakat N=2^14, r=8, p=1 modern sistemler için güçlü minimum gibi sunulmamalıdır.

Argon2, 2015 Password Hashing Competition’ın kazananıdır. Üç varyantı vardır: Argon2d, Argon2i ve Argon2id. Argon2d veri bağımlı bellek erişimi kullandığı için GPU/ASIC saldırılarına karşı güçlü bir profil sunar; fakat yan kanal açısından bazı ortamlarda daha dikkatli değerlendirilmelidir. Argon2i veri bağımsız bellek erişimiyle yan kanal riskini azaltmaya odaklanır. Argon2id ise hibrit yaklaşımdır ve parola hashing için genel önerilen varyanttır.

Argon2id’in tercih edilmesinin nedeni, hem memory-hard yapı sayesinde GPU/ASIC tabanlı çevrimdışı tahmin saldırılarını pahalılaştırması hem de yan kanal riskine karşı Argon2d’ye göre daha dengeli bir profil sunmasıdır. OWASP Argon2id’i güncel parola saklama için birinci seçenek olarak verir; RFC 9106 da Argon2id için önerilen parametre setlerini açıklar. NIST ise Argon2id’i tek isim olarak zorunlu kılmaz; bunun yerine parola doğrulayıcılarının offline saldırılara dirençli, salt’lı ve cost factor içeren uygun parola hashing şemaları kullanmasını ister.

Argon2id üç temel parametreyle yapılandırılır. t, time cost değeridir ve kaç geçiş/iterasyon yapılacağını belirler. m, memory cost değeridir ve genellikle KiB cinsinden bellek kullanımını belirtir. p, parallelism değeridir ve paralel iş parçacığı sayısını ifade eder. Bu üç değer birlikte değerlendirilir; yalnızca algoritma adını görmek güvenlik değerlendirmesi için yeterli değildir.

OWASP Password Storage Cheat Sheet, Argon2id için minimum başlangıç olarak m=19 MiB, t=2, p=1 değerlerini verir. RFC 9106 ise daha yüksek güvenlik için Argon2id t=1, 2 GiB memory seçeneğini birinci öneri; bellek kısıtlı ortamlar için t=3, 64 MiB memory seçeneğini ikinci öneri olarak sunar. Bu iki kaynak aynı şeyi söylemiyor gibi görünse de aslında farklı pratik hedeflere hitap eder: OWASP uygulama güvenliği için erişilebilir minimum bir taban verirken, RFC 9106 kriptografik tasarım önerisi olarak daha yüksek bellek maliyetli ayarları da listeler.

Argon2id parametrelerini belirlerken hedef, saldırgana gerçek bellek ve CPU maliyeti yüklerken kullanıcı deneyimini kabul edilebilir tutmaktır. 250–500 ms gibi süre hedefleri pratik sistemlerde görülebilir; fakat standart zorunluluk değildir. OWASP, parola hashing işleminin genel olarak kullanıcı deneyimini ve DoS riskini bozmayacak şekilde ayarlanmasını vurgular. Bu nedenle parametre seçimi mutlaka hedef sistem donanımında benchmark edilmelidir.

Düşük bellek parametreleri Argon2id’in memory-hard avantajını ciddi biçimde zayıflatır. Örneğin m=4 MiB gibi bir değer, güncel önerilerin altında kalır ve saldırgana beklenen bellek maliyetini yeterince yüklemeyebilir. Yine de “PBKDF2’den farklı değildir” demek fazla genelleyici olur; Argon2id hâlâ farklı bir yapıdır, fakat zayıf parametrelerle beklenen savunma etkisi büyük ölçüde azalır.

Parola Hashing ve KDF Araçlarının Parametre Analizi

Argon2id çoğu kütüphanede PHC string formatını kullanır. Örnek bir çıktı yapısı şöyledir:

Bu formatta argon2id kullanılan varyantı gösterir. v=19, Argon2 sürümünü ifade eder. m=65536, 65536 KiB yani 64 MiB bellek kullanımına karşılık gelir. t=3, üç geçiş/iterasyon anlamına gelir. p=4, dört paralel iş parçacığını gösterir. Son iki alan base64 kodlanmış salt ve hash çıktısıdır.

Bir Argon2id çıktısını değerlendirirken önce varyanta bakılır. argon2id beklenen modern parola hashing tercihidir. Ardından memory cost değeri incelenir. 4096 veya 8192 KiB gibi düşük bellek değerleri güncel önerilerin oldukça altında kalır. Sonra time cost değeri kontrol edilir; t=1 ile t=3 arasındaki fark saldırgan maliyetini etkiler. Son olarak salt uzunluğu ve rastgeleliği değerlendirilir. Yeni sistemlerde 16 bayt veya daha yüksek salt uzunluğu güçlü bir modern tercihtir.

PHC string formatının en önemli avantajı, parola hash’iyle birlikte algoritma adını ve parametreleri de saklamasıdır. Bu sayede sistem zaman içinde parametre yükseltmesi yapabilir. Kullanıcı bir sonraki başarılı girişinde eski parametrelerle doğrulanır, ardından yeni parametrelerle yeniden hashlenebilir. Bu yaklaşım, toplu parola sıfırlama zorunluluğu olmadan güvenlik seviyesini aşamalı artırmanın yaygın yoludur.

bcrypt çıktısı genellikle şu formata benzer:

Buradaki 2b varyant bilgisidir. 12 cost değeridir ve hesaplama maliyetinin 2^12 ölçeğinde olduğunu gösterir. Cost değeri 8 veya altındaysa bu yapı güncel donanım için genellikle zayıf kabul edilir. Ancak nihai karar hedef sistemde benchmark edilerek verilmelidir. Sistemin aynı anda kaç giriş denemesi işleyebileceği, DoS riski ve kullanıcı deneyimi de bu ayarın parçasıdır.

PBKDF2 çıktılarında iterasyon sayısı format içinde açıkça görülebilir. Örneğin bazı eski sistemlerde veya belirli framework sürümlerinde şu biçimde çıktı görülebilir:

Bu örnek güncel Werkzeug varsayılanı olarak verilmemelidir. Werkzeug 3.1.x dokümantasyonunda generate_password_hash için varsayılan yöntem scrypt olarak görünür; PBKDF2 desteklense de daha az güvenli seçenek olarak listelenir ve PBKDF2 iterasyon varsayılanları sürümlere göre değişmiştir. Güncel dokümantasyon, default parametrelerin zamanla güncellenebileceğini ve eski hash’lerin doğrulama sırasında yeni parametrelerle migrate edilebileceğini belirtir.

PBKDF2 değerlendirirken yalnızca algoritma adını değil, hash fonksiyonunu ve iterasyon sayısını da okumak gerekir. PBKDF2-HMAC-SHA256 ile PBKDF2-HMAC-SHA1 aynı risk profiline sahip değildir. 100.000 altı iterasyonlar güncel sistemlerde genellikle zayıf kabul edilir. OWASP, FIPS-140 uyumluluğu gereken durumlarda PBKDF2-HMAC-SHA256 için 600.000 veya üzeri iterasyon önerir; fakat bu değer NIST SP 800-132’den geliyormuş gibi anlatılmamalıdır.

HKDF çıktılarının bağlama göre ayrılması kod incelemede özellikle önemlidir. Bir güvenlik analisti şu soruları sormalıdır: Extract aşamasında salt nasıl kullanılıyor? Salt sabit mi, oturuma özgü mü, protokol tarafından mı belirleniyor? Expand aşamasında info her kullanım amacı için farklı ve anlamlı mı? Aynı PRK’dan şifreleme anahtarı, MAC anahtarı ve IV türetiliyorsa bu çıktılar açık domain separation ile ayrılmış mı? Üretilen toplam çıktı uzunluğu RFC 5869’daki 255 × HashLen sınırına uyuyor mu?

TLS 1.3 key schedule’ını incelemek HKDF’nin gerçek protokolde nasıl kullanıldığını görmek için değerli bir egzersizdir. TLS 1.3, farklı traffic secret’ları ve anahtarları türetirken HKDF tabanlı aşamalı bir yapı kullanır; bu yapı, aynı temel sırdan farklı bağlamlara ait ayrı anahtar materyali üretmenin neden önemli olduğunu gösterir.

Komut & Araç Okuryazarlığı

Bu bölümde amaç, öğrencinin araç çıktısını yalnızca “güvenli/güvensiz” diye etiketlemesi değil, formatın içindeki parametreleri okuyarak güvenlik seviyesini yorumlayabilmesidir.

Argon2id PHC Çıktısını Okuma

Platform / Araç: Python argon2-cffi, referans Argon2 implementasyonu veya PHC formatı üreten başka bir güvenilir kütüphane.

Amaç: Mevcut bir sistemde Argon2id parametrelerinin ne kadar güvenli yapılandırıldığını yorumlamak.

Beklenen çıktı şu yapıya benzer:

Bu çıktı okunurken önce algoritma varyantı kontrol edilir. argon2id beklenen modern tercihtir. argon2i bazı bağlamlarda hâlâ görülebilir; fakat sunucu tarafı genel parola hashing için Argon2id daha dengeli bir tercihtir. argon2d ise yan kanal riski bulunan ortamlarda dikkatle değerlendirilmelidir.

Sonra m değeri incelenir. m=65536, 64 MiB bellek anlamına gelir. Bu değer RFC 9106’nın bellek kısıtlı ortamlar için ikinci önerisiyle uyumludur. OWASP minimum tabanı ise 19 MiB, t=2, p=1 olarak verir. Bu yüzden 64 MiB/t=3 güçlü bir ayar olabilir; fakat yüksek eşzamanlı giriş yükü olan sistemlerde bellek tüketimi ayrıca kapasite planlaması gerektirir.

t değeri iterasyon/geçiş sayısını gösterir. t=1 her zaman kötü değildir; RFC 9106’nın 2 GiB bellek kullanan birinci önerisi t=1 değerini kullanır. Bu nedenle time cost tek başına değil, memory cost ile birlikte değerlendirilmelidir. p değeri ise paralellik seviyesini gösterir; CPU yapısı ve kütüphane davranışıyla birlikte ele alınmalıdır.

Salt alanı base64 formatında görünür. Salt gizli değildir; fakat yeterince uzun, kullanıcıya özgü ve rastgele olmalıdır. Modern sistemlerde 16 bayt ve üzeri salt güçlü bir pratik tercihtir.

bcrypt Cost Değerini Değerlendirme

bcrypt çıktısında cost değeri doğrudan görünür:

Buradaki 12, maliyet seviyesidir. Cost arttıkça doğrulama süresi üstel olarak artar. Cost=8 gibi değerler güncel sistemlerde genellikle düşük kabul edilir. Cost=10 ve üzeri yaygın başlangıç noktasıdır; ancak gerçek hedef değer, sistemin donanımında ölçülmelidir. OWASP, bcrypt kullanılacaksa work factor’ın 10 veya üzerinde olmasını ve 72 bayt sınırının dikkate alınmasını önerir.

bcrypt migration için standart yaklaşım, kullanıcı başarılı giriş yaptığında hash’i yeni cost değeriyle tekrar üretmektir. Böylece tüm kullanıcıları aynı anda parola sıfırlamaya zorlamadan kademeli geçiş yapılabilir.

PBKDF2 İterasyon Sayısını Yorumlama

PBKDF2 çıktılarında iterasyon değeri genellikle format içinde yer alır. Örneğin:

pbkdf2:sha256:600000$<salt>$<hash>

Bu yapı görüldüğünde üç şey kontrol edilir: kullanılan hash fonksiyonu, iterasyon sayısı ve salt. PBKDF2-HMAC-SHA256, eski sistemlerde ve FIPS uyumluluğu gereken ortamlarda kullanılabilir. Ancak yeni genel amaçlı sistemlerde Argon2id gibi memory-hard seçenekler daha güçlü bir savunma sağlar.

600.000 iterasyon değeri OWASP’in FIPS uyumluluğu gereken PBKDF2-HMAC-SHA256 kullanımları için verdiği öneridir. NIST SP 800-63B ise belirli bir sabit sayıdan çok, cost factor’ın pratikte mümkün olan en yüksek güvenli seviyede seçilmesini ister. Bu ayrım raporlama dilinde korunmalıdır.

HKDF Kullanımını Kod İncelemede Okuma

HKDF kullanımı incelenirken “HKDF var” demek yeterli değildir. Extract aşamasında salt nasıl veriliyor? Expand aşamasında info boş mu? Aynı PRK’dan birden fazla anahtar türetiliyorsa her amaç için ayrı info kullanılmış mı? Türetilen çıktı uzunluğu 255 × HashLen sınırına uyuyor mu?

İyi bir yapılandırmada info değeri açık, sürümlendirilebilir ve bağlama özgüdür. Örneğin:

app-v1 aes-gcm encryption key

app-v1 hmac authentication key

app-v1 token signing key

Bu tür ayrımlar, aynı temel materyalden türeyen anahtarların farklı kullanım alanlarında karışmasını önler. Boş info kullanımı tek bir amaç için bazen teknik olarak çalışabilir; ancak protokol büyüdükçe veya aynı PRK’dan birden fazla değer türetildikçe key separation riski doğurur.

İleri Seviye Güvenli Analiz / Kontrol Listesi

Bir sistem veya kod tabanında hash, MAC, KDF veya parola hashing yapılarını değerlendirirken ilk adım, hangi bileşenin hangi amaçla kullanıldığını netleştirmektir. Hash bütünlük doğrulaması için mi, MAC kimlik doğrulama için mi, KDF anahtar türetme için mi, parola hashing kimlik bilgisi saklama için mi kullanılıyor? Amaçlar karışırsa güvenlik modeli yanlış okunur.

Hash kullanımında kullanılan algoritma ve hedef güvenlik özelliği birlikte değerlendirilmelidir. SHA-1 veya MD5 varsa, kullanım bağlamı sorulmalıdır. Collision resistance gerekiyor mu? Dijital imza, sertifika, belge bütünlüğü veya kod imzalama gibi bir bağlam mı var? Yoksa yalnızca legacy identifier veya güvenlik dışı eşleme mi yapılıyor? Aynı algoritma adı farklı bağlamlarda farklı risk üretir.

MAC kullanımında HMAC, CMAC, Poly1305 veya KMAC gibi standart bir yapı kullanılıp kullanılmadığı kontrol edilmelidir. SHA256(secret || message) gibi naif yapılar HMAC değildir. Doğrulama constant-time yapılıyor mu? Hata mesajları ayrıntılı mı? MAC anahtarı yeterli entropiye sahip mi? Tag kısaltılmışsa güvenlik seviyesi buna göre değerlendirilmiş mi?

KDF kullanımında HKDF, PBKDF2 veya başka bir yapı kullanılıyorsa parametreler incelenmelidir. HKDF’de salt ve info doğru kullanılıyor mu? Farklı amaçlar için domain separation sağlanmış mı? Aynı PRK’dan birden fazla anahtar türetiliyorsa info değerleri benzersiz ve anlamlı mı? HKDF output length RFC sınırlarına uyuyor mu?

Parola hashing tarafında Argon2id, bcrypt, scrypt veya PBKDF2 kullanımı ve parametreleri değerlendirilmelidir. Argon2id için bellek değeri yeterli mi? bcrypt cost mevcut donanımda kalibre edilmiş mi? scrypt parametreleri güncel önerilerin gerisinde mi? PBKDF2 varsa iterasyon sayısı ve uyumluluk gerekçesi açık mı? Salt uzunluğu ve rastgeleliği yeterli mi?

Araç çıktısında yalnızca “güvenli algoritma kullanılmış” tespitinde kalınmamalıdır. Parametreler, salt yönetimi, hata yönetimi, timing güvenliği, migration stratejisi ve standart uyumu birlikte ele alınmalıdır. Güvenlik değerlendirmesi, algoritma adıyla değil, algoritmanın nasıl kullanıldığıyla tamamlanır.

Bir bulgu geliştirici veya güvenlik ekibine aktarılırken teknik ama uygulanabilir bir dil kullanılmalıdır. Örneğin:

“Mevcut parola hashing yapılandırmasında Argon2id kullanılıyor; ancak bellek parametresi 4 MiB olarak ayarlanmış. Bu değer güncel OWASP ve RFC 9106 önerilerinin altında kalıyor. Algoritma seçimi doğru yönde olsa da parametreler GPU destekli çevrimdışı saldırılara karşı beklenen maliyeti yeterince artırmayabilir. Parametrelerin hedef sistemde benchmark edilerek yükseltilmesi ve kullanıcıların bir sonraki başarılı girişte yeni parametrelerle yeniden hashlenmesi önerilir.”

Analitik Senaryo

Durum

TEST-APP01 adlı bir uygulama sunucusunun güvenlik yapılandırması inceleniyor. Uygulama kullanıcı parolalarını ve oturum tokenlarını yönetiyor. Kod incelemesinde şu durum tespit ediliyor: parolalar bcrypt ile saklanıyor ve cost=8 kullanılıyor. Oturum token üretimi tarafında kodun bazı yerlerinde “HMAC” ifadesi geçiyor, ancak kaynak kodda standart HMAC API’si mi kullanıldığı yoksa SHA256(secret || user_id) gibi naif bir birleştirme mi yapıldığı net değil. Ayrı bir API katmanında ise mesaj bütünlüğü kontrolü için SHA256(body) çıktısı başlığa ekleniyor.

İlk Değerlendirme

Üç ayrı risk alanı vardır. Birincisi bcrypt cost=8 değerinin güncel donanım karşısında yetersiz kalma ihtimalidir. Bu değer her sistemde aynı etkiyi göstermez; ancak modern sunucu ve saldırgan donanımı düşünüldüğünde offline saldırıyı yeterince yavaşlatmayabilir.

İkinci risk, HMAC ifadesinin belirsiz kullanımıdır. Eğer gerçekten standart HMAC-SHA256(key=secret, message=user_id) API’si kullanılıyorsa yapı temel olarak doğru yöndedir; fakat token mesajının yalnızca user_id’den ibaret olması bağlam eksikliği doğurabilir. Eğer kod aslında SHA256(secret || user_id) yapıyorsa bu HMAC değildir; Merkle-Damgård length extension riski ve naif MAC tasarımı problemi vardır.

Üçüncü risk, API bütünlüğü için SHA256(body) gibi anahtarsız hash kullanılmasıdır. Anahtarsız hash, saldırganın body içeriğini değiştirip yeni hash’i yeniden hesaplamasını engellemez. Bu yapı güvenlik anlamında bütünlük veya otantiklik sağlamaz; yalnızca kazara bozulmaları tespit etmeye yarayabilir.

Kontrol Edilecek Noktalar

bcrypt cost=8 değerinin uygulama sunucusunda doğrulama başına kaç milisaniye sürdüğü benchmark edilmelidir. Hedef değer, sistem performansı ve DoS riski dikkate alınarak belirlenmelidir. Eğer doğrulama süresi çok düşükse cost değeri artırılmalıdır.

HMAC tarafında kaynak kod doğrudan incelenmelidir. Standart bir HMAC API’si mi kullanılıyor? Örneğin Python’da hmac.new(key, msg, digestmod) veya eşdeğer güvenilir kütüphane çağrısı mı var? Yoksa secret ve user_id birleştirilip düz SHA-256 mı hesaplanıyor? Bu ayrım kaynak kod görülmeden anlaşılamaz.

Token mesajı da incelenmelidir. Yalnızca user_id imzalanıyorsa token’ın bağlamı eksik olabilir. Token içinde issuer, audience, expiry, scope, session id ve sürüm gibi alanlar varsa bunların canonical encoding ile MAC’e dahil edilmesi gerekir. user_id || role || expiry gibi belirsiz string birleştirmeleri yerine ayrıştırılabilir ve tek anlamlı bir format kullanılmalıdır.

API bütünlüğü tarafında SHA256(body) başlığı güvenlik sağlamaz. Bütünlük ve otantiklik gerekiyorsa HMAC-SHA256 veya AEAD tabanlı bir mekanizma kullanılmalıdır. Eğer API trafiği zaten TLS ile korunuyorsa bile uygulama katmanı mesaj bütünlüğü ayrı bir gereksinimse anahtarlı mekanizma şarttır.

İncelenecek Çıktı

bcrypt hash formatında $2b$08$... gibi cost segmenti aranır. HMAC uygulamasında standart kütüphane çağrısı olup olmadığı kontrol edilir. API bütünlük başlığında hash’in nasıl üretildiği ve doğrulandığı incelenir. Doğrulama sırasında compare_digest veya eşdeğer constant-time karşılaştırma kullanılıyor mu, hata durumunda farklı mesajlar dönüyor mu, bunlar ayrıca değerlendirilir.

Güvenli Doğrulama Yaklaşımı

bcrypt için cost değeri benchmark ortamında sisteme özgü hedefe göre kalibre edilmelidir. Cost artırımı doğrudan tüm eski hash’leri geçersiz kılmak zorunda değildir. Kullanıcı başarılı giriş yaptığında mevcut hash doğrulanabilir ve parola yeni cost değeriyle yeniden hashlenebilir.

HMAC için standart kütüphane API’si kullanılmalı ve doğrulama constant-time comparison ile yapılmalıdır. Mesaj alanları net biçimde kodlanmalı, domain separation için token türü ve sürüm bilgisi MAC kapsamına alınmalıdır.

API bütünlüğü için anahtarsız SHA-256 yerine HMAC-SHA256 veya uygun bağlamda AEAD kullanılmalıdır. Eğer yalnızca iletim hatası tespiti isteniyorsa bu ayrı belirtilmeli; fakat güvenlik anlamında bütünlük iddiası kurulacaksa anahtarlı mekanizma şarttır.

Yanlış Yorumlama İhtimali

“SHA-256 güvenli bir algoritmadır” ifadesi, anahtarsız hash’in API bütünlüğü için yeterli olduğu anlamına gelmez. Güvenlik özelliği algoritma adından değil, kullanım bağlamından doğar. SHA-256 güçlü bir hash fonksiyonu olabilir; fakat SHA256(body) saldırganın yeni body için yeni hash üretmesini engellemez.

“HMAC kullanıyoruz” ifadesi de kaynak kod görülmeden yeterli değildir. Standart HMAC API’si kullanılıyor mu, yoksa geliştirici kendi HMAC benzeri yapısını mı kurmuş? Token alanları belirsiz biçimde mi birleştiriliyor? Doğrulama constant-time mı? Bu soruların cevabı güvenlik değerlendirmesinin parçasıdır.

Riskin Pratik Karşılığı

Anahtarsız hash kullanan bütünlük kontrolü, saldırganın ağ veya ara sistem üzerinde body içeriğini değiştirip hash’i yeniden hesaplamasına izin verebilir. Uygulama bu başlığı güvenlik doğrulaması gibi kabul ederse manipüle edilmiş veri geçerli sayılabilir.

bcrypt cost=8, saldırganın çevrimdışı hash denemelerini yeterince yavaşlatmayabilir. Eğer kullanıcı parolaları zayıfsa veya daha önce sızmış parola listelerinde yer alıyorsa, düşük cost değeri saldırganın başarı ihtimalini artırır.

Naif SHA256(secret || user_id) kullanımı varsa length extension ve bağlam karışıklığı gibi riskler doğabilir. Standart HMAC kullanılsa bile token mesajı iyi yapılandırılmamışsa farklı token türleri arasında karışıklık veya replay riski oluşabilir.

Önerilen Güvenli Yaklaşım

bcrypt cost değeri hedef sistemde benchmark edilerek artırılmalıdır. Uzun vadede yeni parola hashing standardı olarak Argon2id’e geçiş planı hazırlanabilir. Geçiş sırasında kullanıcıların bir sonraki başarılı girişinde yeni parametrelerle rehash edilmesi güvenli ve kullanıcı deneyimini bozmayan bir yöntemdir.

Token üretiminde standart HMAC-SHA256 API’si kullanılmalı; mesaj alanları canonical encoding ile yapılandırılmalı ve token türü, sürüm, issuer, audience, expiry ve scope gibi bağlam bilgileri MAC kapsamına alınmalıdır. Doğrulama hmac.compare_digest() veya eşdeğer constant-time fonksiyonla yapılmalıdır.

API bütünlüğü için SHA256(body) yerine HMAC-SHA256 veya uygun AEAD yapısı kullanılmalıdır. Hata mesajları tek ve genel tutulmalı; “MAC yanlış”, “format yanlış”, “token süresi dolmuş” gibi ayrımlar dışarıya güvenlik açısından gereksiz ayrıntı sızdırmayacak şekilde tasarlanmalıdır.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

Birthday paradox Doğum günü paradoksu; büyük bir uzayda beklenenden daha az denemeyle çakışma görülmesini açıklayan olasılık ilkesi.

Birthday attack Hash çakışmasını yaklaşık 2^(n/2) karmaşıklıkta arayan saldırı sınıfı.

Collision resistance Farklı iki girdinin aynı hash değerini üretmesini hesaplama açısından zorlaştıran özellik.

Preimage resistance Hash değeri verildiğinde bu değeri üreten girdinin bulunmasını zorlaştıran özellik.

Second preimage resistance Belirli bir girdi verildiğinde aynı hash’i üreten farklı bir girdi bulmayı zorlaştıran özellik.

Chosen-prefix collision Saldırganın iki farklı başlangıç yapısına sahip girdiyi aynı hash değerine yönlendirdiği güçlü collision saldırısı türü.

Length extension attack Merkle-Damgård hashlerinde H(m) ve uzunluk bilgisiyle H(m ‖ padding(m) ‖ ek_veri) hesaplanabilmesine dayanan saldırı.

Merkle-Damgård SHA-2, SHA-1 ve MD5 gibi hash fonksiyonlarında görülen ardışık blok işleme yapısı.

Chaining state Merkle-Damgård yapısında bloklar arasında taşınan iç durum.

Sponge construction SHA-3’ün temelini oluşturan absorb/squeeze fazlarına sahip yapı.

XOF Extendable Output Function; değişken uzunlukta çıktı üretebilen hash-benzeri fonksiyon.

SHAKE SHA-3 çerçevesindeki XOF ailesi; SHAKE128 ve SHAKE256 üyelerini içerir.

cSHAKE SHAKE’in özelleştirilebilir/domain separation destekli türevi.

HMAC Hash-based Message Authentication Code; standart anahtarlı MAC yapısı.

CMAC Cipher-based MAC; AES gibi blok şifreler üzerinde çalışan MAC yapısı.

Poly1305 One-time key kullanımına dayanan MAC; ChaCha20-Poly1305 içinde kullanılır.

KMAC KECCAK/SHA-3 tabanlı, değişken uzunlukta çıktı verebilen anahtarlı MAC/PRF yapısı.

Constant-time comparison Karşılaştırma süresini eşleşen byte sayısına bağlı hâle getirmemeyi hedefleyen güvenli doğrulama yöntemi.

Timing oracle İşlem süresindeki farklardan kısmi bilgi sızdıran yan kanal zayıflığı.

HKDF RFC 5869’da tanımlanan HMAC tabanlı extract-and-expand KDF yapısı.

Extract HKDF’de ham input keying material değerini pseudorandom key’e dönüştüren aşama.

Expand HKDF’de PRK’dan bağlama özgü anahtar materyali üreten aşama.

IKM Input Keying Material; HKDF’ye verilen ham anahtar materyali.

PRK Pseudorandom Key; HKDF Extract aşamasının çıktısı.

OKM Output Keying Material; HKDF Expand aşamasının ürettiği çıktı anahtar materyali.

Domain separation Aynı temel kriptografik materyalin farklı amaçlarda karışmaması için bağlama özgü ayrım yapılması.

PBKDF2 Password-Based Key Derivation Function 2; iteratif HMAC tabanlı parola KDF yapısı.

bcrypt Blowfish tabanlı, cost parametresiyle yapılandırılan parola hashing algoritması.

scrypt Bellek bağımlı parola hashing/KDF yapısı; N, r ve p parametreleriyle yapılandırılır.

Argon2id Password Hashing Competition kazananı Argon2 ailesinin hibrit ve genel parola hashing için önerilen varyantı.

Memory-hard function Hesaplama için anlamlı miktarda bellek gerektiren, GPU/ASIC paralelleştirmesini pahalılaştıran fonksiyon.

PHC string format Password Hashing Competition formatı; algoritma, parametreler, salt ve hash’i tek string içinde kodlar.

Time cost Argon2’de iterasyon/geçiş sayısını belirleyen parametre.

Memory cost Argon2’de kullanılacak bellek miktarını belirleyen parametre.

Parallelism Argon2’de paralel iş parçacığı sayısını belirleyen parametre.

Salt Parola hashing veya KDF’de kullanılan, çakışmayı ve önceden hesaplama saldırılarını engelleyen kullanıcıya/oturuma özgü değer.

Rainbow table Önceden hesaplanmış hash değerleri tablosu; salt kullanımı bu saldırıyı pratik dışı bırakır.

Pepper Parola hashing’e eklenen, veritabanından ayrı tutulan gizli değer; salt yerine geçmez, ek koruma sağlar.

Work factor bcrypt veya PBKDF2 gibi yapılarda saldırgan maliyetini artıran hesaplama parametresi.

Cost factor Parola hashing şemasında her parola tahmininin maliyetini artıran genel parametre.

Canonical encoding MAC veya imza kapsamındaki alanların tek anlamlı, ayrıştırılabilir ve tutarlı biçimde kodlanması.

Kendini Değerlendir — İleri Kriptografi Modül 3

Bu Modülde Neler Öğrendik?

Bu modül, hash ve parola güvenliği konusunu “algoritma adını bilme” seviyesinden çıkarıp güvenlik modeli, saldırgan modeli ve yapısal analiz düzeyine taşıdı.

Hash güvenlik özelliklerini collision, preimage ve second preimage olarak ayrı kategorilerde görmek, güvenlik seviyesi hesaplamalarını doğru yapmayı sağlar. Birthday paradox’ın n-bit hash için yaklaşık 2^(n/2) collision güvenliği anlamına geldiğini bilmek, SHA-256’nın neden collision açısından yaklaşık 128-bit güvenlik sunduğunu anlamanın temelidir.

Length extension açığının Merkle-Damgård yapısından kaynaklandığını ve doğru saldırı formülünün H(m ‖ padding(m) ‖ ek_veri) olduğunu öğrenmek, naif SHA256(secret || mesaj) gibi yapıların neden güvenli MAC olmadığını açıklar. SHA-3’ün sponge yapısı ise bu saldırı modelinden yapısal olarak farklıdır.

HMAC’in neden güvenli, naif H(key ‖ mesaj) yapısının neden riskli olduğunu; Poly1305’in neden one-time key gerektirdiğini; KMAC’in SHA-3/KECCAK tabanlı değişken çıktılı bir MAC/PRF olarak nasıl konumlandığını anlamak, kod incelemede doğrudan kullanılan becerilerdir.

HKDF’nin extract/expand ayrımı ve info parametresinin domain separation için kritik rolü, gerçek protokol tasarımlarını yorumlamayı kolaylaştırır. Aynı PRK’dan farklı amaçlar için anahtar türetirken bağlam etiketlerinin açık biçimde ayrılması gerekir. HKDF çıktı sınırının blok boyutu değil, 255 × HashLen olduğu da teknik olarak doğru biçimde bilinmelidir.

Memory-hard fonksiyonların neden gerekli olduğunu anlamak, parola güvenliğini saldırgan modeliyle birlikte düşünmeyi sağlar. Saldırgan hash veritabanını ele geçirdiğinde çevrimdışı deneme yapar; bu nedenle her tahminin CPU ve bellek maliyeti artırılmalıdır. Argon2id’in güçlü modern tercih olmasının nedeni yalnızca yeni olması değil, bu saldırgan modeline daha uygun maliyet yüklemesidir.

Araç çıktısında PHC string formatını okumak, bcrypt cost değerini yorumlamak, PBKDF2 iterasyon sayısını güncel rehberlerle karşılaştırmak ve HKDF info kullanımını kod üzerinden değerlendirmek gerçek sistemlerdeki yapılandırma analizinin somut karşılığıdır.

Bu modülde edinilen en kritik alışkanlık şudur: Bir algoritmanın adını görmek yeterli değildir. Parametre değerleri, salt yönetimi, doğrulama davranışı, timing güvenliği, migration stratejisi ve kullanım bağlamı birlikte değerlendirilmeden güvenlik yorumu tamamlanmış sayılmaz.

MODÜL 4 — İleri açık anahtar kriptografisi

Modül özeti

Asimetrik kriptografiyi yalnızca “büyük sayılar” değil; padding, protokol, imzalama ve anahtar formatı okuryazarlığı ile birlikte ele alır.

Modül 4 — İleri Açık Anahtar Kriptografisi

Açık anahtar kriptografisi temel eğitimde genellikle “RSA büyük asal sayıların çarpımına dayanır, ECC eğri üzerindeki hesaplamalara dayanır” düzeyinde bırakılır. Bu modül, o tanımın çok ötesine geçer. Güvenliğin hangi matematiksel varsayıma indirgenebildiğini, bu varsayımların pratik saldırı yüzeyiyle nasıl ilişkilendiğini ve uygulama kararlarının güvenlik modelini nasıl etkilediğini ele alır.

RSA tarafında padding seçimi, küçük açık üs kullanımı, Bleichenbacher’ın adaptif seçilmiş şifreli metin saldırısı, timing sızıntısı ve anahtar kullanım ayrımı birlikte değerlendirilir. Bu konuların ortak noktası şudur: RSA matematiği doğru olsa bile yanlış padding, hatalı protokol davranışı veya yan kanal sızıntısı sistemi güvensiz hâle getirebilir. RSAES-OAEP ve RSASSA-PSS gibi modern şemalar bu risklerin önemli bölümünü güvenlik modeli içinde ele alır; ancak doğru parametre ve doğru implementasyon yine şarttır. RSAES-OAEP’in güvenliği, RSA fonksiyonunun tersine çevrilmesinin zorluğu ve uygun mask generation özellikleri gibi koşullar altında adaptif seçilmiş şifreli metin saldırılarına karşı ele alınır.

ECC tarafında scalar multiplication’ın yan kanal yüzeyi, ECDSA nonce tekrarının özel anahtarı açığa çıkarması, invalid curve saldırıları ve nokta doğrulama gereksinimi işlenir. Bu modül ayrıca X25519, Ed25519, P-256 ve P-384 gibi modern yapıların neden tercih edildiğini teknik düzeyde açıklar. Burada özellikle Ed25519 ile X25519’un aynı şey olmadığı vurgulanır: X25519, Curve25519’un Montgomery formu üzerinde tanımlı anahtar anlaşması fonksiyonudur; Ed25519 ise ilişkili edwards25519 eğrisi üzerinde tanımlı EdDSA imza şemasıdır. RFC 7748 X25519/X448’i, RFC 8032 ise Ed25519/Ed448 imza algoritmalarını tanımlar.

Pairing tabanlı kriptografi ise BLS imzaları ve kimlik tabanlı şifreleme bağlamında kontrollü biçimde konumlandırılır. Bu alan ileri uzmanlık gerektirdiğinden müfredat sınırı korunur. Son bölümde OpenSSL çıktılarından anahtar parametrelerini ve eğri isimlerini okuma, PEM/DER/ASN.1 formatlarını ayırt etme ve kütüphane varsayılanlarını sorgulama alışkanlığı kazandırılır.

Kazanımlar

Bu modül sonunda öğrenci:

Factoring, discrete logarithm, CDH ve DDH varsayımlarının birbirleriyle ilişkisini açıklayabilir; bir algoritmanın güvenliğinin hangi varsayıma ve hangi güvenlik modeline dayandığını ifade edebilir.

RSA’da küçük açık üs sorununu, Bleichenbacher saldırısının yapısal kaynağını ve timing sızıntısını güvenlik modeli bağlamında analiz edebilir.

RSA-OAEP ve RSA-PSS’in hangi amaçlarla kullanıldığını açıklar; şifreleme padding’i ile imzalama padding’inin karıştırılmaması gerektiğini bilir.

FIPS 186-5’in RSASSA-PKCS1-v1.5 ve RSASSA-PSS imza şemalarını belirli koşullarla onaylı kabul ettiğini; buna rağmen yeni tasarımlarda RSA-PSS’in formal güvenlik gerekçesi nedeniyle güçlü bir tercih olduğunu yorumlayabilir. FIPS 186-5, bu iki RSA imza şemasını onaylı imza şemaları olarak ele alır.

Eliptik eğri gruplarının sonlu alan üzerindeki işleyişini, scalar multiplication’ın güvenlik sezgisini ve ECDH/ECDSA/EdDSA arasındaki tasarım farklarını teknik düzeyde açıklayabilir.

X25519, Ed25519, P-256 ve P-384 gibi seçenekleri güvenlik profili, performans, yan kanal direnci, standart ekosistemi ve kullanım amacı açısından karşılaştırabilir.

ECDSA nonce tekrarının özel anahtarı nasıl açığa çıkardığını ve deterministik ECDSA/RFC 6979 ile EdDSA’nın bu risk sınıfını nasıl azalttığını değerlendirebilir. RFC 6979, DSA ve ECDSA için deterministik imza üretim prosedürünü tanımlar.

Invalid curve saldırısının kavramsal mantığını, klasik Weierstrass eğrilerinde nokta doğrulamasının neden kritik olduğunu ve X25519 gibi yapılarda doğrulama modelinin farklılaştığını açıklayabilir.

Bilinear pairing fikrinin BLS imzalarına ve kimlik tabanlı şifrelemeye nasıl zemin hazırladığını kısaca konumlandırabilir; bu alanın standart açık anahtar kriptografisine göre neden ek uzmanlık gerektirdiğini ifade edebilir.

OpenSSL çıktısında RSA/ECC anahtar parametrelerini, eğri adını, anahtar boyutunu ve imza algoritmasını okuyabilir; PEM, DER ve ASN.1 formatları arasındaki ilişkiyi ayırt edebilir.

Şifreleme, imza ve key establishment için aynı anahtar çiftinin kullanılmasının neden riskli olduğunu, anahtar kullanım ayrımının standartlar ve protokol politikalarıyla nasıl desteklendiğini açıklayabilir.

Açık anahtar kriptografisindeki yapılandırma ve parametre sorunlarını güvenlik ekibine ve mimari ekibe teknik olarak aktarabilecek bir öneri dili geliştirebilir.

Sert Matematiksel Varsayımlar

Açık anahtar kriptografisinin güvenliği, belirli hesaplama problemlerinin pratikte çözülemez olduğu varsayımına dayanır. Bu “sertlik” sezgisel bir ifade değildir. Bir problemin sert olduğu söylendiğinde, belirli bir saldırgan modelinde ve belirli kaynak sınırları altında bu problemi çözebilen verimli bir algoritmanın bilinmediği kastedilir. Kriptografik güvenlik ispatı ise çoğu zaman bir indirgeme ile kurulur: Eğer saldırgan şemayı kırabiliyorsa, bu saldırganı kullanarak altta yatan sert problemi çözebiliriz.

Factoring problemi, iki büyük asal sayının çarpımı olan n = p × q değeri verildiğinde p ve q çarpanlarını bulmanın zorluğudur. RSA anahtar üretiminde modulus güvenliği bu zorlukla yakından ilişkilidir. Ancak RSA şifreleme veya imza şemalarının güvenliği yalnızca “factoring zordur” cümlesine indirgenemez. Textbook RSA, RSA fonksiyonuna ilişkin varsayımlarla; RSA-OAEP veya RSA-PSS gibi şemalar ise padding yapısı, güvenlik modeli, hash/MGF seçimi ve implementasyon koşullarıyla birlikte değerlendirilir.

RSA özel anahtarını modulus üzerinden çıkarmak pratikte factoring ile ilişkilidir. Buna rağmen teorik açıdan “RSA’yı kırmak her koşulda factoring’e eşdeğerdir” demek doğru değildir. Örneğin hatalı padding, oracle davranışı veya timing sızıntısı varsa saldırgan factoring problemini çözmeden de düz metne veya özel anahtar bilgisine ulaşabilir. Bu nedenle açık anahtar kriptografisinde varsayım ile uygulama yüzeyi birlikte okunmalıdır.

RSA anahtar boyutu seçimi güvenlik gücüyle ilişkilidir. RSA-2048 yaklaşık 112-bit güvenlik seviyesine karşılık gelen güncel minimum eşik olarak görülür. Yaklaşık 128-bit güvenlik seviyesi hedefleniyorsa RSA-3072 tercih edilir; daha uzun vadeli veya daha geniş güvenlik marjı isteyen sistemlerde RSA-4096 değerlendirilebilir. NIST SP 800-131A Rev. 2, SP 800-57 Part 1’de yer alan 128-bit güvenlik gücüne geçiş yaklaşımına atıf yapar; bu nedenle “3072 bit yalnızca 2030’a kadar güvenlidir” gibi bir ifade doğru değildir.

Discrete Logarithm problemi, sonlu bir siklik grupta g^x = h denklemi verildiğinde x değerini bulmanın zorluğudur. Diffie-Hellman ve eliptik eğri kriptografisi bu problem ailesiyle ilişkilidir. Burada önemli ayrım şudur: Ayrık logaritma probleminin zorluğu kullanılan gruba bağlıdır. Klasik sonlu alanlarda ayrık logaritma için subexponential algoritmalar bilinir; bu nedenle güvenli parametreler büyük seçilmelidir. Eliptik eğri gruplarında ise bilinen en iyi genel saldırılar çok daha yüksek maliyetlidir; bu yüzden ECC, daha kısa anahtarlarla benzer güvenlik seviyeleri sunabilir.

Computational Diffie-Hellman varsayımı, g^a ve g^b verildiğinde g^(ab) değerini hesaplamanın zor olduğunu söyler. ECDH güvenliği bu tür bir varsayımla ilişkilidir. Decisional Diffie-Hellman varsayımı ise g^a, g^b ve g^c değerleri verildiğinde c = ab mi, yoksa rastgele bir değer mi olduğunu ayırt etmenin zor olduğunu varsayar.

Genel olarak DDH, CDH’den; CDH de DL’den daha güçlü bir varsayım olarak görülür. Ancak bu ilişki kullanılan grup yapısına bağlıdır. Pairing bulunan bazı gruplarda DDH kolaylaşabilirken CDH hâlâ zor kabul edilebilir. Bu nedenle “DDH → CDH → DL” hiyerarşisi faydalı bir sezgi sağlar; fakat her grup ve her protokol için mekanik biçimde uygulanacak mutlak bir yasa gibi okunmamalıdır.

Bir protokolün “CDH’ye dayalı güvenli” olduğu söylendiğinde, bunun anlamı CDH varsayımı çürütülmediği sürece protokolün her koşulda güvenli olduğu değildir. Hangi güvenlik modelinde ispat yapıldığı, saldırganın hangi yetkilere sahip olduğu, indirgemenin ne kadar sıkı olduğu ve protokolün gerçek dünyada nasıl implemente edildiği ayrıca değerlendirilmelidir.

Bir algoritmanın güvenlik ispatı, çoğu zaman “eğer saldırgan algoritmayı kırabiliyorsa, o saldırganı kullanarak temel sertlik problemini çözeriz” biçiminde kurulur. Bu indirgeme ne kadar sıkıysa, saldırganın avantajı ile temel problem çözümü arasındaki kayıp o kadar küçüktür. Gevşek indirgeme, teoride ispatlı görünen bir yapının pratik parametre seçiminde daha fazla güvenlik marjına ihtiyaç duyabileceğini gösterir.

NIST SP 800-56A ve SP 800-56B gibi dokümanlar, Diffie-Hellman ve RSA tabanlı anahtar anlaşması protokolleri için gereksinimleri ve güvenlik seviyelerini okumada temel kaynaklardır. SP 800-186 ise ayrık logaritma tabanlı kriptografi için önerilen eğrileri ve grup yapılarını ele alır; P-256 gibi Weierstrass eğrileri ile X25519/X448 gibi modern seçeneklerin standart bağlamını anlamada önemlidir.

RSA Güvenliği ve Saldırıları

RSA’nın doğru kullanımı, yalnızca matematiksel yapısını bilmekten ibaret değildir. Padding seçimi, anahtar boyutu, açık üs seçimi, timing yönetimi, hata mesajları ve anahtar kullanım ayrımı birlikte değerlendirilmelidir. Bu kararların herhangi birindeki hata, matematiksel olarak sağlam olan RSA’yı pratikte savunmasız hâle getirebilir.

RSA şifrelemede e = 3 gibi küçük bir açık üs kullanılması, özellikle paddingsiz veya hatalı paddingli textbook RSA kullanımında ciddi sorun doğurabilir. Eğer mesaj m küçükse ve m^3 < n ise c = m^3 mod n işleminde modüler indirgeme gerçekleşmez; saldırgan c’nin küp kökünü alarak m değerine ulaşabilir. Birden fazla alıcıya aynı mesaj farklı moduluslarla ve aynı küçük üs ile gönderildiğinde Håstad’ın broadcast saldırısı benzer fikri sistematik biçimde kullanır.

Modern sistemlerde açık üs için yaygın tercih e = 65537 değeridir. Bu değer hem verimli hem de güvenli kullanım pratikleriyle uyumludur. Küçük açık üs tek başına her durumda saldırı anlamına gelmez; asıl kritik hata, küçük üs ile birlikte paddingsiz veya hatalı paddingli RSA şifreleme yapılmasıdır. Doğru padding, standartlara uygun anahtar üretimi ve güvenli kütüphane kullanımı burada belirleyici olur.

RSA padding olmaksızın deterministiktir. Aynı mesaj aynı anahtar altında her zaman aynı ciphertext’i üretir. Bu durum IND-CPA güvenliğini imkânsız kılar. Daha da önemlisi, textbook RSA cebirsel olarak şekillendirilebilir: saldırgan bir ciphertext üzerinde çarpımsal dönüşüm yaparak ilişkili başka ciphertext’ler üretebilir. Bu tür özellikler seçilmiş şifreli metin saldırılarına kapı açar.

PKCS#1 v1.5 padding, uzun süre TLS ve başka protokollerde RSA şifreleme için kullanılmış eski bir yapıdır. 1998’de Daniel Bleichenbacher, PKCS#1 v1.5 padding doğrulama hatalarının ayrıntılı biçimde dışarı sızdığı durumlarda adaptif oracle sorgularıyla RSA şifreli metninin çözülebileceğini gösterdi. Saldırı binlerce veya milyonlarca sorgu gerektirebilir; fakat yıllar içinde farklı TLS implementasyonlarında tekrar tekrar pratik karşılık bulmuştur. ROBOT saldırısı da bu sınıfın modern sistemlerde uzun süre yaşamaya devam edebildiğini göstermiştir.

TLS sunucusu PKCS#1 v1.5 ile RSA key exchange destekliyorsa Bleichenbacher sınıfı saldırılar bakımından ayrıca incelenmelidir. TLS 1.3 statik RSA ve statik Diffie-Hellman cipher suite’lerini kaldırmış, tüm açık anahtar tabanlı key exchange mekanizmalarında forward secrecy sağlayan bir yapıya geçmiştir. TLS 1.2 döneminde RSA key exchange yerine ECDHE/DHE tabanlı yapıların tercih edilmesi bu geçişin temel güvenlik kararlarından biridir.

RSAES-OAEP, RSA şifreleme için modern padding yaklaşımıdır. Mesajı şifrelemeden önce mask generation function ile iki aşamalı bir maskeleme yapısına sokar. Bu yapı deterministikliği kırar ve seçilmiş şifreli metin saldırılarına karşı güvenlik hedefler. RSAES-OAEP’in güvenliği, uygun parametreler ve doğru implementasyonla, random oracle modeli ve RSA fonksiyonunu tersine çevirmenin zorluğuna ilişkin varsayımlar altında değerlendirilir. RFC 8017, RSAES-OAEP’in adaptif seçilmiş şifreli metin saldırılarına karşı anlamsal güvenliğini bu varsayımlar çerçevesinde açıklar.

RSA-PSS ise RSA imzalama için tasarlanmış probabilistic signature scheme yapısıdır. Rastgele salt kullanır ve formal güvenlik analizi açısından RSA-PKCS#1 v1.5 imzasına göre daha güçlü bir modern tercih olarak değerlendirilir. Buna rağmen FIPS 186-5’in RSA-PKCS#1 v1.5 imza üretimini tamamen onay dışına aldığı söylenmemelidir. FIPS 186-5, RSASSA-PKCS1-v1.5 ve RSASSA-PSS imza şemalarını belirli gereksinimlerle onaylı olarak ele alır. Yeni tasarımlarda RSA-PSS tercih edilebilir; mevcut sistemlerde PKCS#1 v1.5 imzalarının durumu ise standart uyumu, protokol gereksinimi ve geçiş planı çerçevesinde değerlendirilmelidir.

RSA’da şifreleme ve imzalama farklı kriptografik amaçlardır. Aynı anahtar çiftinin hem şifreleme/key transport hem de imzalama için kullanılması protokol bileşimi hatalarına yol açabilir. Örneğin bir imzalama fonksiyonunun yanlış bağlamda decryption oracle gibi davranması veya key usage sınırlarının bulanıklaşması ciddi risk üretir. Bu nedenle imza, şifreleme ve key establishment için anahtar kullanım ayrımı yapılmalıdır. ECDSA gibi imza anahtarları için FIPS 186-5 anahtarların başka amaçlarla kullanılmaması gerektiğini açıkça belirtir; RSA tarafında da sertifika key usage alanları, protokol politikaları ve anahtar yönetim kuralları bu ayrımı destekler.

RSA özel anahtar işlemleri, özellikle gizli d üssüyle yapılan modüler üs alma, sabit sürede gerçekleştirilmediğinde timing sızıntısına yol açabilir. Montgomery multiplication, constant-time implementasyonlar ve blinding teknikleri bu riski azaltmak için kullanılır. Blinding, işlem öncesinde değeri rastgele bir faktörle maskeleyip işlem sonrasında maskeyi kaldırarak özel anahtar işleminin gerçek girdiye bağlı zamanlama örüntülerini gizlemeye yardımcı olur.

Bu teknikler RSA’nın matematiksel güvenliğinden ayrı olarak uygulama güvenliğinin parçasıdır. RSA doğru şema ve doğru parametrelerle kullanılsa bile özel anahtar işlemleri timing, cache veya güç analizi gibi yan kanallara açık biçimde uygulanırsa güvenlik iddiası pratikte zayıflar.

Eliptik Eğri Kriptografisi — İleri

ECC’nin temel mantığı şudur: Sonlu alan üzerinde tanımlı bir eliptik eğri üzerindeki noktalar belirli bir grup yapısı oluşturur. Bu grupta scalar multiplication, yani Q = kP hesaplamak kolaydır; fakat P ve Q verildiğinde k değerini bulmak ECDLP nedeniyle zordur. Bu asimetri, ECDH, ECDSA ve EdDSA gibi yapıların temelini oluşturur.

Gerçek sayılar üzerindeki geometrik eliptik eğri çizimleri kavramsal sezgi için faydalıdır; fakat gerçek kriptografik ECC sonlu alanlarda çalışır. Prime field eğrilerde işlemler mod p aritmetiğiyle yapılır. Nokta toplama, nokta iki katlama ve sonsuz nokta kavramları bu sonlu alan üzerinde tanımlanır. Sonsuz nokta, grup işleminin kimlik elemanıdır.

Klasik Weierstrass eğrilerinde alınan public key noktasının gerçekten beklenen eğri üzerinde olup olmadığı, sonsuz nokta olmadığı ve doğru alt grupta bulunduğu doğrulanmalıdır. Bu doğrulama yalnızca teorik bir ayrıntı değildir; invalid curve saldırılarına karşı temel savunmadır. X25519 gibi Montgomery ladder tabanlı yapılarda ise doğrulama modeli farklıdır. RFC 7748, X25519 ve X448 için u-koordinatı tabanlı fonksiyonları ve pratik güvenlik özelliklerini tanımlar; bu nedenle klasik nokta doğrulama dili ile X25519 davranışı birebir aynı anlatılmamalıdır.

Scalar multiplication’ın güvenliği yalnızca ECDLP’nin zorluğuna bağlı değildir. Implementasyonun yan kanal direnci de belirleyicidir. Sabit zamanlı olmayan double-and-add gibi yöntemlerde özel anahtarın bit desenine bağlı dallanmalar ve işlem süreleri oluşabilir. Bu farklar timing, cache veya power analysis ile özel anahtar hakkında bilgi sızdırabilir. Bu nedenle ECC implementasyonu sıfırdan yazılmamalı; güvenilir, bakımlı ve yan kanal direnci dikkate alınmış kütüphaneler kullanılmalıdır.

ECDH, klasik Diffie-Hellman anahtar anlaşmasının eliptik eğri üzerindeki karşılığıdır. Alice ve Bob birbirlerinin public key noktalarını alır, kendi private scalar değerleriyle scalar multiplication yapar ve aynı shared secret noktasına ulaşır. Bu ham nokta veya x koordinatı doğrudan şifreleme anahtarı olarak kullanılmamalıdır. Ham ECDH çıktısı yapısal bileşenler içerebilir ve protokol bağlamına bağlanmamıştır. Bu nedenle HKDF gibi bir KDF ile işlenerek oturum anahtarları, yön bilgileri ve kullanım bağlamları ayrıştırılmalıdır.

ECDSA, imzalama sırasında her imza için benzersiz ve gizli bir nonce k gerektirir. İmza çıktısı (r, s) çiftinden oluşur. r değeri kG noktasının x koordinatından türetilir; s değeri ise mesaj hash’i, private key ve nonce k ile ilişkili bir denklemden hesaplanır. Bu yapı nedeniyle k değerinin tekrar etmesi veya tahmin edilebilir olması özel anahtarı doğrudan riske atar.

EdDSA, ECDSA’dan farklı bir tasarıma sahiptir. Ed25519 özelinde imza nonce’u, private key seed’in hashlenmesiyle elde edilen prefix ve mesaj üzerinden deterministik biçimde türetilir. Bu yapı, ECDSA’da görülen harici CSPRNG’ye bağımlı nonce üretimi riskini büyük ölçüde azaltır. Ancak bu “her koşulda nonce riski imkânsızdır” anlamına gelmez. Hatalı implementasyon, fault injection, yan kanal sızıntısı veya private key koruması zayıflığı hâlâ güvenlik sorunu doğurabilir. RFC 8032, EdDSA’yı edwards25519 ve edwards448 eğrileriyle tanımlar.

Ed25519 ile X25519’un ayrımı açık tutulmalıdır. X25519, Curve25519’un Montgomery formu üzerinde tanımlı Diffie-Hellman fonksiyonudur. Ed25519 ise ilişkili edwards25519 eğrisi üzerinde tanımlı EdDSA imza şemasıdır. Bu yapılar matematiksel olarak ilişkili olsa da kullanım amaçları, anahtar biçimleri ve protokol rolleri farklıdır. X25519 anahtar anlaşması için, Ed25519 imza için kullanılır.

Ed25519, modern sistemlerde güçlü ve yaygın bir imza seçeneğidir. TLS 1.3 Ed25519’u desteklenen imza algoritmaları arasında konumlandırır; SSH ekosisteminde de Ed25519 yaygınlaşmıştır. Ancak WireGuard gibi sistemlerde ana mekanizma olarak X25519/Curve25519 anahtar anlaşması öne çıkar. Bu yüzden “Ed25519, WireGuard’da standart seçimdir” gibi bir ifade doğru değildir; burada Ed25519 ve X25519 rolleri karıştırılmamalıdır.

P-256, NIST tarafından tanımlanan ve geniş ekosistem desteğine sahip klasik Weierstrass eğrisidir. TLS, sertifika altyapısı, kurumsal PKI ve donanım güvenlik modüllerinde P-256 çok yaygın desteklenir. P-384 daha yüksek güvenlik marjı isteyen sistemlerde tercih edilebilir. Curve25519/X25519 ise performans, sade implementasyon ve yan kanal direnci açısından modern protokollerde öne çıkar. NIST SP 800-186, P-256 gibi Weierstrass eğrileri yanında modern Montgomery ve Edwards eğrilerini de önerilen eğri ailesi bağlamında ele alır.

P-256 ile Curve25519/X25519 arasındaki tercih yalnızca matematiksel güvenlik meselesi değildir. Birlikte çalışabilirlik, sertifika ekosistemi, FIPS gereksinimleri, kütüphane desteği, donanım hızlandırması ve protokol standardı seçimi belirleyicidir. Kurumsal PKI tarafında P-256 hâlâ güçlü bir pratik seçimken, modern protokol tasarımlarında X25519 anahtar anlaşması sıkça tercih edilir.

Özellik ECDSA EdDSA / Ed25519

Nonce üretimi Geleneksel kullanımda rastgele CSPRNG; RFC 6979 ile deterministik ECDSA mümkündür. Private key seed’den türetilen prefix ve mesaj üzerinden deterministik nonce üretimi.

Nonce tekrar riski Aynı veya ilişkili nonce kullanımı özel anahtarı açığa çıkarabilir. CSPRNG kaynaklı nonce tekrar riskini büyük ölçüde azaltır; güvenlik doğru implementasyona bağlıdır.

Hız Eğriye ve implementasyona göre değişir. Ed25519 pratikte hızlı ve verimli implementasyonlara uygundur.

Constant-time implementasyon Dikkat gerektirir; kütüphane kalitesi kritiktir. Constant-time implementasyonu kolaylaştıran tasarım özellikleri vardır; otomatik garanti değildir.

Standart bağlam FIPS 186-5, X9.62, SEC standartları, TLS/PKI ekosistemi. RFC 8032, modern protokol ve yazılım ekosistemi.

Tipik eğriler P-256, P-384, secp256k1 gibi eğriler. Ed25519 için edwards25519.

Kullanım amacı Dijital imza. Dijital imza.

ECC Uygulama Riskleri

Eliptik eğri kriptografisi, algoritmik düzeyde sağlam olsa bile implementasyon kararları nedeniyle ciddi güvenlik açıkları üretebilir. Bu bölümdeki riskler çoğu zaman matematiğin değil, uygulamanın ve protokol entegrasyonunun yarattığı sorunlardır.

ECDSA’nın özel anahtarı ele veren en kritik zafiyetlerinden biri, aynı nonce k değerinin iki farklı imzada kullanılmasıdır. İki farklı mesaj aynı private key ve aynı nonce ile imzalanırsa r değerleri aynı olur ve s denklemleri üzerinden önce k, ardından private key hesaplanabilir. Bu saldırı ek oracle gerektirmez; imza çiftleri yeterlidir.

Pratikte aynı public key altında farklı mesaj imzalarında aynı r değerinin görülmesi, aynı veya ilişkili nonce kullanımına dair çok güçlü bir alarmdır. Matematiksel olarak r, kG noktasının x koordinatından türediği için bazı ilişkili nonce durumlarında da aynı r görülebilir; fakat güvenlik incelemesinde aynı r değeri yüksek öncelikli kritik bulgu olarak ele alınmalıdır.

Bu risk gerçek dünyada defalarca ortaya çıkmıştır. Sony PS3 imzalama sisteminde nonce yönetimi hatası private key’in açığa çıkmasına yol açmıştır. Bazı Bitcoin cüzdanlarında zayıf RNG veya nonce tekrarları özel anahtarların kurtarılmasına neden olmuştur. Bu örneklerin ortak dersi şudur: ECDSA’da nonce kalitesi, private key güvenliğiyle aynı derecede kritiktir.

ECDSA kullanılacaksa güvenilir kütüphane API’si tercih edilmelidir. Manuel nonce üretimi yapılmamalıdır. Deterministik ECDSA/RFC 6979, kötü RNG kaynaklı nonce tekrar riskini azaltmak için önemli bir seçenektir. Ancak deterministik imza da yan kanal veya fault attack risklerinden bağımsız değildir; private key işlemleri yine sabit zamanlı ve güvenli implementasyonla yapılmalıdır. RFC 6979, DSA/ECDSA için deterministik imza üretim prosedürünü tanımlar ve mevcut doğrulayıcılarla uyumluluğu hedefler.

Yan kanal riskleri ECC’de özellikle scalar multiplication sırasında ortaya çıkar. Özel scalar’ın bit desenine göre farklı dallar izleyen veya farklı sürelerde çalışan algoritmalar, saldırgana özel anahtar hakkında istatistiksel bilgi sağlayabilir. Timing, cache, elektromanyetik sızıntı ve güç analizi bu bağlamda değerlendirilir.

Modern kütüphaneler bu riski genellikle yüksek seviye API seviyesinde ele alır. Ancak düşük seviye API kullanımı, raw point işleme, custom curve desteği veya elle scalar multiplication yazımı risklidir. Öğrencinin veya güvenlik analistinin hedefi scalar multiplication algoritması yazmak değil, güvenli kütüphaneyi seçmek ve doğru API seviyesini kullanmaktır.

Invalid curve saldırıları, özellikle klasik ECDH uygulamalarında alınan public key noktasının doğru eğri üzerinde olup olmadığının doğrulanmaması durumunda gündeme gelir. Saldırgan, beklenen eğriye ait olmayan veya küçük dereceli bir yapı üzerinde bulunan bir noktayı göndererek kurbanın private scalar’ı hakkında parça parça bilgi sızdırabilir.

Savunma, bağlama göre değişir. Klasik Weierstrass tabanlı ECDH’de public key noktasının eğri üzerinde olduğu, sonsuz nokta olmadığı ve doğru alt grup özelliklerini sağladığı kontrol edilmelidir. X25519 gibi Montgomery ladder tabanlı yapılarda ise nokta doğrulama modeli farklıdır; kütüphane dokümantasyonu ve low-order çıktı davranışı ayrıca okunmalıdır. Yüksek seviye güvenli API’ler çoğu zaman bu ayrıntıları yönetir; fakat düşük seviye veya raw input kabul eden API’larda sorumluluk geliştiriciye kalabilir.

Zayıf rastgelelik, açık anahtar kriptografisinde yalnızca ECDSA nonce üretimiyle sınırlı değildir. RSA anahtar üretimi, ECC private key üretimi, ephemeral ECDH ve imzalama rastgelelikleri güvenilir CSPRNG gerektirir. Gömülü sistemlerde, erken boot aşamasındaki servislerde veya entropi kaynağı sınırlı cihazlarda bu konu özellikle önemlidir. Platform CSPRNG’si, donanım TRNG desteği ve kütüphane random API’si güvenlik incelemesinin parçası olmalıdır.

Anahtar doğrulama ve parametre kontrolü de uygulama güvenliğinin temelidir. Public key boyutu, eğri adı, OID, key usage alanları ve algoritma parametreleri beklenen bağlama uygun olmalıdır. Bir sistem hem P-256 hem X25519 hem de Ed25519 destekliyorsa, hangi anahtarın imza, hangisinin key agreement için kullanıldığı açıkça ayrılmalıdır. Aksi hâlde doğru algoritmalar yanlış bağlamda kullanılarak protokol güvenliği zayıflatılabilir.

Pairing Tabanlı Kriptografiye Giriş

Pairing tabanlı kriptografi, ileri kriptografide ayrı bir uzmanlık alanıdır. Bu modülde konu yalnızca kavramsal konumlandırma düzeyinde ele alınır. Amaç pairing implementasyonu öğretmek değil, BLS imzaları ve kimlik tabanlı şifreleme gibi yapıların neden standart ECC’den farklı bir matematiksel araca ihtiyaç duyduğunu göstermektir.

Bilinear pairing, iki eliptik eğri grubundan üçüncü bir hedef gruba giden özel bir eşlemedir. Basitleştirilmiş biçimde e: G₁ × G₂ → G_T olarak yazılır ve bilinearity özelliği sağlar: e(aP, bQ) = e(P, Q)^(ab). Bu özellik, standart ECDSA veya ECDH ile kolay kurulamayan bazı kriptografik yapıların oluşturulmasına imkân tanır.

Pairing tabanlı kriptografinin bedeli yüksektir. Pairing hesaplamaları standart ECC scalar multiplication işlemlerinden daha karmaşıktır. Eğri seçimi, hash-to-curve işlemleri, subgroup kontrolü, cofactor handling ve güvenli implementasyon ayrıntıları özel uzmanlık gerektirir. Bu nedenle üretim kullanımlarında BLS12-381 gibi yaygınlaşmış pairing-friendly eğriler ve güvenilir referans implementasyonlar tercih edilir.

BLS imzaları, pairing tabanlı kriptografinin en yaygın pratiğe taşınan uygulamalarından biridir. Temel avantajı imza agregasyonudur. Birden fazla imza belirli kurallar altında tek bir aggregate signature hâline getirilebilir. Ancak bu özellik basitçe “n farklı mesajdaki n imza tek bir imzaya iner ve tek doğrulamayla biter” şeklinde anlatılmamalıdır. Farklı public key ve farklı mesaj senaryolarında rogue-key saldırılarına karşı proof-of-possession veya message augmentation gibi savunmalar gerekir. CFRG BLS imza taslağı basic, message augmentation ve proof-of-possession şemalarını bu ayrımlar üzerinden tanımlar.

BLS doğrulaması pairing hesaplamaları gerektirir. Bu nedenle tekil BLS imza doğrulaması çoğu zaman ECDSA veya Ed25519 doğrulamasından daha maliyetli olabilir. Buna karşılık büyük ölçekli sistemlerde çok sayıda imzanın aggregate edilmesi toplam doğrulama ve veri taşıma maliyetini azaltabilir. Ethereum’un proof-of-stake consensus katmanı, Filecoin ve bazı blockchain protokolleri BLS imzalarını ve BLS12-381 gibi pairing-friendly eğrileri bu nedenle kullanır.

Threshold BLS, eşik imzaları konusuyla doğal bağlantı kurar. k-of-n yapısında imza payları birleştirilerek geçerli tek bir BLS imzası üretilebilir. Bu sırada özel anahtar hiçbir noktada tek parça hâlinde ortaya çıkmak zorunda değildir. Bu konu daha ileri eşik kriptografi modüllerinin kapsamına girer.

Kimlik tabanlı şifreleme, PKI olmaksızın bir kimlik bilgisini doğrudan public key gibi kullanma fikrini hayata geçirir. Örneğin bir e-posta adresi veya kullanıcı kimliği public key rolü görebilir. Merkezi bir Private Key Generator, bu kimliğe karşılık gelen private key’i üretir. Bu yapı sertifika dağıtımı problemini azaltır; fakat güveni merkezi PKG’ye taşır. PKG ele geçirilirse veya kötüye kullanılırsa sistemin güvenlik modeli kökten zayıflar.

Kimlik tabanlı şifreleme geniş genel üretim kullanımına sahip değildir; fakat araştırma literatüründe ve bazı özel sistemlerde önemlidir. Pairing tabanlı kriptografi bu eğitim kapsamında yalnızca konumlandırılır. Derinleşmek isteyenler için BLS12-381 implementasyonları, hash-to-curve standartları ve pairing güvenliği ayrı uzmanlık alanı olarak ele alınmalıdır.

Açık Anahtar ve ECC Araçlarıyla Çıktı Analizi

Açık anahtar kriptografisinin gerçek sistem bağlamındaki karşılığını anlamak için araç çıktılarını doğru okuyabilmek gerekir. Buradaki amaç komut ezberi değil, anahtar parametre ve format okuryazarlığı kazanmaktır.

ASN.1, kriptografik yapıların nasıl temsil edileceğini tanımlayan soyut sözdizimi ailesidir. RSA anahtarı, sertifika, public key, private key, eğri OID’si ve imza algoritması gibi yapılar ASN.1 ile modellenebilir. DER, ASN.1 yapılarının ikili ve deterministik kodlamasıdır. PEM ise DER içeriğinin Base64 ile kodlanıp BEGIN/END başlıklarıyla metin formuna sarılmış hâlidir.

Bir PEM dosyasında başlık satırı dosyanın ne içerdiğini anlamak için ilk ipucudur. -----BEGIN CERTIFICATE----- bir X.509 sertifikayı, -----BEGIN PRIVATE KEY----- PKCS#8 formatında private key’i, -----BEGIN RSA PRIVATE KEY----- ise RSA’ya özgü eski PKCS#1 private key formatını işaret eder. BEGIN PRIVATE KEY ile BEGIN RSA PRIVATE KEY aynı şey değildir. Modern araçlar genellikle algoritma bağımsız PKCS#8 formatını tercih eder.

OpenSSL ile RSA anahtar parametreleri okunurken temel amaç modulus bit uzunluğunu, public exponent değerini ve anahtar formatını doğrulamaktır. İzinli bir test ortamında openssl rsa -text -noout -in test_key.pem benzeri bir komut RSA private key ayrıntılarını gösterebilir. Öğrenci burada anahtar boyutuna ve public exponent değerine bakmalıdır. 1024-bit RSA güncel güvenlik beklentileri için yetersizdir. 2048-bit minimum eşik, 3072-bit yaklaşık 128-bit güvenlik seviyesi, 4096-bit ise daha geniş marj olarak değerlendirilebilir.

Public exponent değerinde 65537 beklenen yaygın değerdir. e=3 gibi küçük üsler tek başına her koşulda “anahtar kırıldı” anlamına gelmez; fakat özellikle eski veya hatalı paddingli şifreleme yapılarında risk sinyalidir. Bu nedenle küçük public exponent görülürse padding, protokol ve kütüphane davranışı ayrıca incelenmelidir.

Anahtar boyutu tek başına güvenlik göstergesi değildir. RSA-4096 kullanılsa bile PKCS#1 v1.5 şifreleme oracle davranışıyla kullanılıyorsa risk devam eder. Benzer şekilde RSA-OAEP kullanılması, imza tarafında RSA-PSS kullanıldığı anlamına gelmez. Şifreleme ve imza mekanizmaları ayrı ayrı değerlendirilmelidir.

OpenSSL ile klasik EC anahtar parametreleri okunurken eğri adı ve OID özellikle önemlidir. openssl ec -text -noout -in ec_key.pem çıktısında ASN1 OID: prime256v1 gibi bir ifade görülebilir. prime256v1, P-256/secp256r1 eğrisini ifade eder. secp384r1, P-384; secp521r1, P-521 olarak okunur. Ed25519 gibi modern imza anahtarlarında ise openssl pkey -text -noout -in ed_key.pem gibi genel pkey aracı daha doğru seçimdir.

İmza ve key agreement seçenekleri kullanım amacına göre ayrılmalıdır. İmza için P-256/P-384 ECDSA veya Ed25519; anahtar anlaşması için P-256/P-384 ECDH veya X25519 gibi seçenekler ayrı değerlendirilir. Ed25519/Curve25519 şeklinde tek bir ifade kullanmak imza ve DH rollerini karıştırır. Ed25519 imza, X25519 ise anahtar anlaşması içindir.

brainpool eğrileri gibi farklı eğri aileleri bazı Avrupa standartlarında yer alır; ancak FIPS/NIST uyumluluğu gereken ortamlarda NIST’in önerdiği eğri listesi esas alınmalıdır. FIPS dışı olmak tek başına “kriptografik olarak güvensiz” anlamına gelmez. Bu, uyumluluk bağlamına göre değerlendirilmesi gereken bir standart farkıdır.

PEM başlığı İçerik

-----BEGIN PRIVATE KEY----- PKCS#8 formatında, algoritma bağımsız private key.

-----BEGIN ENCRYPTED PRIVATE KEY----- Şifrelenmiş PKCS#8 private key.

-----BEGIN RSA PRIVATE KEY----- PKCS#1 formatında RSA’ya özgü eski private key.

-----BEGIN PUBLIC KEY----- SubjectPublicKeyInfo formatında public key.

-----BEGIN CERTIFICATE----- X.509 sertifika.

-----BEGIN CERTIFICATE REQUEST----- CSR, yani Certificate Signing Request.

Bir araç veya kütüphane “varsayılan” ECC anahtarı ürettiğinde, hangi eğriyi seçtiği otomatik olarak doğru kabul edilmemelidir. Bazı eski konfigürasyonlar kurumsal politikadan farklı eğri seçebilir. Üretilen her anahtarın eğri adı, boyutu, kullanım amacı ve sertifika key usage alanları doğrulanmalıdır.

İleri Seviye Güvenli Analiz / Kontrol Listesi

Açık anahtar kriptografisi bileşenlerini değerlendirirken önce kapsam netleştirilmelidir. Sistemde RSA mı, ECC mi, EdDSA mı, X25519 mu, yoksa bunların bir kombinasyonu mu kullanılıyor? Hangi anahtar boyutları, eğri seçimleri ve protokol bağlamları var? İmza ve key establishment anahtarları ayrılmış mı?

RSA için anahtar boyutu ilk kontrol noktasıdır. 2048-bit altı RSA anahtarları ciddi risk olarak ele alınmalıdır. 2048-bit RSA güncel minimum seviyeyi, 3072-bit RSA yaklaşık 128-bit güvenlik seviyesini, 4096-bit RSA daha geniş güvenlik marjını temsil eder. Public exponent 65537 mi? Küçük exponent varsa kullanım bağlamı ve padding ayrıca incelenmelidir.

RSA şifreleme tarafında OAEP mi, yoksa PKCS#1 v1.5 mi kullanılıyor? PKCS#1 v1.5 şifreleme kullanılıyorsa hata davranışı oracle oluşturuyor mu? TLS tarafında RSA key exchange destekleniyor mu? TLS 1.3 bu sınıfı protokol seviyesinde kaldırdığı için eski TLS 1.2 yapılandırmaları özellikle kontrol edilmelidir.

RSA imza tarafında PKCS#1 v1.5 ve PSS ayrımı doğru yapılmalıdır. FIPS 186-5, RSASSA-PKCS1-v1.5 ve RSASSA-PSS’i belirli koşullarla onaylı kabul eder; ancak yeni tasarımlarda RSA-PSS formal güvenlik gerekçesi nedeniyle tercih edilebilir. Bu nedenle “PKCS#1 v1.5 imza tamamen yasaktır” gibi bir raporlama dili kullanılmamalıdır.

ECC için kullanılan eğri belirlenmelidir. P-256, P-384, Ed25519, X25519, secp256k1 veya başka bir eğri mi kullanılıyor? Bu eğri kullanım amacına uygun mu? Ed25519 imza için, X25519 key agreement için mi kullanılmış? Public key doğrulaması veya düşük seviyeli point parsing güvenli biçimde yapılıyor mu?

ECDSA kullanılıyorsa nonce üretimi kritik kontrol noktasıdır. CSPRNG güvenilir mi? RFC 6979 deterministik ECDSA kullanılıyor mu? Farklı imzalarda aynı r değeri görülüyor mu? İmzalama implementasyonu güvenilir kütüphane üzerinden mi, yoksa elle mi yazılmış? Elle yazılmış ECDSA imzalama kodu yüksek riskli kabul edilmelidir.

EdDSA kullanılıyorsa doğru algoritma ve doğru key formatı incelenmelidir. Ed25519 deterministic nonce üretimi sayesinde ECDSA’daki kötü RNG kaynaklı nonce tekrar riskini azaltır; ancak private key koruması, yan kanal direnci ve kütüphane kalitesi hâlâ değerlendirilmelidir.

Public key, private key, sertifika ve CSR dosyaları karıştırılmamalıdır. PEM başlıkları kontrol edilmeli, private key dosyalarının erişim izinleri sınırlandırılmalı, private key çıktıları ekran görüntüsü veya log olarak saklanmamalıdır. Anahtarların kullanım amacı sertifika key usage ve extended key usage alanlarıyla uyumlu olmalıdır.

Bir bulgu geliştirici veya güvenlik ekibine aktarılırken teknik ama uygulanabilir bir dil kullanılmalıdır. Örneğin:

“Sistemde RSA-1024 anahtarları tespit edildi. Bu anahtar boyutu güncel güvenlik gereksinimleri için yeterli güvenlik marjı sağlamıyor. Yaklaşık 128-bit güvenlik hedefleniyorsa RSA-3072 veya uygun ECC seçenekleri değerlendirilmelidir. Geçiş sırasında sertifika yenileme takvimi, key usage ayrımı ve protokol uyumluluğu birlikte planlanmalıdır.”

Analitik Senaryo

Durum

STAGE-SERVER01 üzerinde çalışan bir API gateway uygulaması, istemci kimlik doğrulaması için özel bir JWT imzalama mekanizması kullanıyor. Kod incelemesinde JWT’lerin ECDSA P-256 ile imzalandığı görülüyor. Ancak imzalama kodu üçüncü taraf güvenilir bir kütüphane üzerinden değil, geliştiricinin yazdığı özel bir implementasyondan geçiyor. Nonce üretimi için Python’un random.getrandbits(256) fonksiyonu kullanılmış. Bu fonksiyon secrets modülü veya işletim sistemi CSPRNG’si gibi kriptografik olarak güvenli bir kaynak değildir.

İlk Değerlendirme

İki ayrı endişe vardır. Birincisi, ECDSA nonce’unun Python random modülünden üretilmesidir. Python’un standart random modülü kriptografik amaçlar için tasarlanmamıştır ve öngörülebilir çıktılar üretebilir. İkincisi, nonce yönetiminin özel implementasyon içinde elle yapılmasıdır. ECDSA’da nonce tekrar eder veya tahmin edilebilir hâle gelirse private key açığa çıkabilir.

P-256 standart ve güvenli kabul edilen bir eğri olabilir; fakat bu durum implementasyonun güvenli olduğu anlamına gelmez. Eğri seçimi doğru, nonce üretimi yanlışsa sistem hâlâ kritik biçimde güvensizdir.

Kontrol Edilecek Noktalar

Önce kütüphane seçimi sorgulanmalıdır. Python’da üretim kullanımı için pyca/cryptography gibi bakımlı ve güvenlik odaklı kütüphaneler tercih edilmelidir. Pure-Python ECDSA kütüphaneleri kullanılacaksa constant-time davranış, nonce üretimi, bakım durumu ve güvenlik uyarıları ayrıca incelenmelidir. Özel ECDSA implementasyonu üretim sisteminde yüksek riskli kabul edilmelidir.

Nonce üretimi ayrıca incelenmelidir. random.getrandbits(256) kriptografik olarak güvenli değildir. Sistemde aynı nonce’un tekrar kullanılıp kullanılmadığını anlamak için imza loglarında aynı public key altında farklı mesajlarda aynı r değerinin görülüp görülmediği kontrol edilebilir. Aynı r değeri, aynı veya ilişkili nonce kullanımına dair çok güçlü bir alarmdır ve private key kurtarma riski doğurur.

JWT yapısı da incelenmelidir. İmzalanan veri canonical biçimde mi kodlanıyor? Algoritma alanı doğrulamada sabitlenmiş mi? alg confusion gibi klasik JWT hatalarına karşı kontrol var mı? ECDSA imza doğrulaması düşük-S normalizasyonu veya format ayrımı gibi kütüphane beklentileriyle uyumlu mu? Bu noktalar imza algoritmasının kendisinden ayrı, protokol entegrasyonu riskleridir.

İncelenecek Çıktı

Kaynak kodda nonce üretim satırı incelenir. random.getrandbits(256) kullanımı kritik bulgu olarak not edilir. İmzalama kütüphanesi veya özel implementasyon dosyası kontrol edilir. requirements.txt, pyproject.toml veya eşdeğer bağımlılık listelerinde pyca/cryptography gibi güvenilir bir kütüphane var mı bakılır.

JWT log kayıtlarında r değerleri karşılaştırılır. Aynı public key altında farklı mesajlar için aynı r değeri görülürse bu acil müdahale gerektiren bir durumdur. Böyle bir durumda private key’in sızmış olabileceği varsayılmalı, anahtar rotasyonu ve geçmiş token etkisi değerlendirilmelidir.

Güvenli Doğrulama Yaklaşımı

Doğrulama, üretim sistemine saldırı yaparak değil, izinli test ortamında ve log/kod incelemesiyle yapılmalıdır. Aynı imzalama kodu izole lab ortamında çalıştırılarak nonce davranışı incelenebilir. Ancak gerçek private key’ler test ortamına taşınmamalıdır.

ECDSA nonce üretimini elle yamamak yerine güvenilir bir kütüphane API’sine geçmek gerekir. Geçici olarak “secrets.token_bytes(32) kullanalım” demek bile tek başına tam çözüm değildir; çünkü ECDSA nonce’u eğri mertebesine uygun aralığa bias üretmeyecek şekilde dönüştürülmelidir. Bu ayrıntıları elle yapmak yerine RFC 6979 deterministik ECDSA destekleyen veya nonce yönetimini güvenli biçimde yapan bir kütüphane kullanılmalıdır.

Yanlış Yorumlama İhtimali

“P-256 kullanıyoruz, bu standart bir eğridir” argümanı bu bağlamda yanıltıcıdır. Eğri seçimi doğru olsa bile nonce üretimi güvensizse saldırgan private key’e ulaşabilir. Algoritma seçimi ile implementasyon kalitesi ayrı değerlendirme katmanlarıdır.

“Ed25519’a geçersek tüm riskler biter” yorumu da fazla genelleyicidir. Ed25519 harici RNG’ye bağlı ECDSA nonce tekrar riskini azaltır; fakat kütüphane kalitesi, private key koruması, yan kanal direnci ve protokol entegrasyonu hâlâ önemlidir.

Riskin Pratik Karşılığı

Eğer iki ECDSA imzasında aynı veya ilişkili nonce kullanılırsa, saldırgan imza çiftlerinden private key’i hesaplayabilir. Bu private key ile geçerli JWT’ler üretilebilir, yetkisiz erişim sağlanabilir ve geçmişte imzalanmış tokenların güvenilirliği sorgulanır.

Bu tür bir bulgu yalnızca kod kalitesi sorunu değildir. Private key’in güvenliği doğrudan tehlikeye girmiş olabilir. Müdahale planında anahtar rotasyonu, eski tokenların iptali, imzalama sisteminin kütüphane tabanlı güvenli yapıya taşınması ve logların özel anahtar sızıntısı varsayımıyla incelenmesi gerekir.

Önerilen Güvenli Yaklaşım

İmzalama kodu güvenilir ve bakımlı bir kütüphane üzerine taşınmalıdır. Üretim Python ortamında pyca/cryptography gibi güvenlik odaklı kütüphaneler tercih edilmelidir. ECDSA kullanılmaya devam edilecekse nonce yönetimi kütüphane tarafından yapılmalı veya RFC 6979 deterministik ECDSA desteği kullanılmalıdır.

Mümkünse Ed25519 değerlendirilmelidir. Ed25519, ECDSA’daki harici RNG’ye bağlı nonce tekrar riskini önemli ölçüde azaltır ve modern imza sistemleri için güçlü bir tercihtir. Ancak geçiş sırasında protokol uyumluluğu, istemci desteği, anahtar formatı, imza formatı ve doğrulama kütüphaneleri birlikte planlanmalıdır.

Mevcut ECDSA private key’in etkilenmiş olabileceği varsayılmalı ve rotasyon planı hazırlanmalıdır. Aynı r değeri görülmüşse bu kritik olay olarak ele alınmalı, ilgili tokenlar iptal edilmeli ve olay müdahale süreci başlatılmalıdır.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

Factoring problemi Büyük bir tam sayının asal çarpanlarına ayrılmasının hesaplama açısından zor olması; RSA modulus güvenliğiyle yakından ilişkilidir.

RSA problemi RSA fonksiyonunu, private key olmadan tersine çevirmenin zor olduğu varsayım ailesi.

Discrete Logarithm Ayrık logaritma; g^x = h denkleminde x değerini bulma problemi.

ECDLP Eliptik Eğri Ayrık Logaritma Problemi; ECC güvenliğinin temelindeki zorluk varsayımı.

CDH Computational Diffie-Hellman; g^a ve g^b verildiğinde g^(ab) hesaplamanın zor olduğu varsayımı.

DDH Decisional Diffie-Hellman; Diffie-Hellman üçlüsünü rastgele üçlüden ayırt etmenin zor olduğu varsayımı.

Bleichenbacher saldırısı PKCS#1 v1.5 RSA şifreleme padding hatalarını oracle olarak kullanan adaptif seçilmiş şifreli metin saldırısı.

RSAES-OAEP RSA şifreleme için kullanılan modern padding şeması; seçilmiş şifreli metin saldırılarına karşı güvenlik hedefler.

RSASSA-PSS RSA imzalama için kullanılan probabilistic signature scheme; modern ve formal güvenlik gerekçesi güçlü RSA imza yaklaşımı.

RSASSA-PKCS1-v1.5 RSA için eski ama hâlen bazı standart bağlamlarında onaylı/uyumlu imza şeması; yeni tasarımlarda PSS tercih edilebilir.

PKCS#1 v1.5 şifreleme RSA şifreleme için eski padding yaklaşımı; oracle davranışı varsa Bleichenbacher sınıfı saldırılara açıktır.

Scalar multiplication Eliptik eğri üzerinde k × P hesaplaması; ECC’nin temel işlemi.

ECDH Elliptic Curve Diffie-Hellman; ECC tabanlı anahtar anlaşması.

X25519 Curve25519’un Montgomery formu üzerinde tanımlı Diffie-Hellman fonksiyonu.

ECDSA Elliptic Curve Digital Signature Algorithm; nonce güvenliği kritik olan ECC imza şeması.

Deterministik ECDSA RFC 6979 ile tanımlanan, nonce’u mesaj ve private key üzerinden deterministik türeten ECDSA yaklaşımı.

EdDSA Edwards-curve Digital Signature Algorithm; deterministik nonce üretimi kullanan modern imza şeması.

Ed25519 edwards25519 eğrisi üzerinde tanımlı EdDSA imza şeması.

edwards25519 Ed25519 imzasında kullanılan twisted Edwards eğrisi.

Curve25519 X25519 anahtar anlaşmasıyla ilişkilendirilen Montgomery eğrisi.

P-256 NIST tarafından tanımlanan prime256v1/secp256r1 eğrisi; PKI ve TLS ekosisteminde yaygındır.

Nonce ECDSA’da her imzada benzersiz ve gizli olması gereken değer; tekrarı private key’i açığa çıkarabilir.

Invalid curve attack Public key doğrulaması yapılmadığında saldırganın beklenmeyen eğri/nokta üzerinden private key hakkında bilgi sızdırmaya çalıştığı saldırı sınıfı.

Low-order point Küçük mertebeli nokta; bazı protokollerde küçük alt grup veya çıktı kontrolü açısından önemlidir.

Constant-time Gizli veriye bağlı dallanma veya süre farkı üretmemesi hedeflenen implementasyon özelliği.

Blinding RSA private key işlemlerinde timing saldırısı riskini azaltmak için kullanılan rastgele maskeleme tekniği.

Bilinear pairing İki eğri grubunu üçüncü bir gruba eşleyen ve pairing tabanlı kriptografinin temelini oluşturan yapı.

BLS imzası Boneh-Lynn-Shacham imzası; pairing tabanlı, aggregation özelliğiyle bilinen imza şeması.

Rogue-key saldırısı Aggregate signature sistemlerinde kötü niyetli public key seçimiyle doğrulamayı yanıltmaya çalışan saldırı sınıfı.

Proof of possession BLS gibi sistemlerde public key sahibinin private key’e sahip olduğunu kanıtlamasını gerektiren savunma yaklaşımı.

IBE Identity-Based Encryption; kimlik bilgisini public key gibi kullanan şifreleme yaklaşımı.

PKG Private Key Generator; IBE sistemlerinde kimliğe karşılık private key üreten merkezi otorite.

PEM DER içeriğinin Base64 ile kodlanıp BEGIN/END başlıklarıyla sarıldığı metin formatı.

DER ASN.1 yapılarının deterministik ikili kodlaması.

ASN.1 Kriptografik yapıların tanımlanmasında kullanılan soyut sözdizimi notasyonu.

PKCS#8 Private key’lerin algoritma bağımsız biçimde saklanmasını tanımlayan format.

PKCS#1 RSA’ya özgü anahtar ve şema formatlarını tanımlayan standart ailesi.

OID Object Identifier; eğri, algoritma veya parametreleri tanımlayan hiyerarşik sayısal kimlik.

Key usage Sertifikada anahtarın hangi amaçla kullanılabileceğini belirten alan.

Anahtar kullanım ayrımı İmza, şifreleme ve key establishment için ayrı anahtarların kullanılması prensibi.

Kendini Değerlendir — İleri Kriptografi Modül 4

Bu Modülde Neler Öğrendik?

Bu modül, açık anahtar kriptografisini “RSA büyük sayılara dayanır, ECC eğriye dayanır” cümlesinin çok ötesine taşıdı.

Öğrenci artık güvenlik varsayımları hiyerarşisini — factoring, DL, CDH ve DDH — daha doğru okuyabilir. Bir protokol için “güvenlidir” denildiğinde, bunun hangi varsayıma, hangi güvenlik modeline ve hangi indirgeme kalitesine dayandığını sorgulayabilir.

RSA tarafında en kritik kavrayış şudur: Padding seçimi, hata davranışı, timing koruması ve anahtar kullanım ayrımı, matematiksel doğruluğu pratik güvenliğe dönüştüren tasarım kararlarıdır. PKCS#1 v1.5 şifreleme bağlamındaki Bleichenbacher sınıfı saldırılar, küçük açık üs problemleri ve oracle davranışları, gerçek dünyada karşılığı olan risklerdir.

RSA-OAEP’in şifreleme için, RSA-PSS’in imza için kullanıldığını; bu iki yapının karıştırılmaması gerektiğini öğrendik. FIPS 186-5’in RSASSA-PKCS1-v1.5 imzayı tamamen onay dışı bırakmadığını, ancak yeni tasarımlarda RSA-PSS’in formal güvenlik gerekçesi nedeniyle daha güçlü tercih olabileceğini netleştirdik.

ECC tarafında nonce yönetiminin kritikliği öne çıktı. ECDSA’da aynı veya ilişkili nonce kullanımı private key’i açığa çıkarabilir. RFC 6979 deterministik ECDSA bu riski azaltır; Ed25519 ise harici RNG’ye bağlı ECDSA nonce tekrar riskini yapısal olarak büyük ölçüde azaltan modern bir imza seçeneğidir.

Ed25519, X25519 ve Curve25519 ayrımı özellikle önemlidir. Ed25519 imza içindir ve edwards25519 üzerinde tanımlıdır. X25519 anahtar anlaşması içindir ve Curve25519’un Montgomery formuyla ilişkilidir. Bu ayrımı doğru yapmadan modern ECC ekosistemi doğru okunamaz.

Invalid curve saldırıları, nokta doğrulaması, low-order point kontrolleri ve constant-time scalar multiplication gibi konular, ECC güvenliğinin yalnızca eğri seçiminden ibaret olmadığını gösterir. Güvenli kütüphane seçimi ve doğru API seviyesi, teorik güvenliğin pratikte korunması için zorunludur.

Araç okuryazarlığı açısından OpenSSL çıktısında eğri adını, OID’yi, RSA anahtar boyutunu, public exponent değerini ve PEM başlıklarını okuyabilmek somut bir güvenlik becerisidir. Bu beceri, güvenlik değerlendirmelerinde ölçülebilir ve raporlanabilir bulgular üretmeyi sağlar.

Pairing tabanlı kriptografi ise BLS imzaları ve IBE kavramıyla genel bir konumlandırmaya kavuştu. BLS aggregation güçlü bir avantaj sunsa da rogue-key saldırıları, proof-of-possession gereksinimi ve pairing doğrulama maliyeti gibi ek uzmanlık gerektiren ayrıntılar içerir. Bu alan, standart açık anahtar kriptografisinin ötesinde ayrı bir uzmanlaşma yoludur.

MODÜL 5 — Güvenli kanal protokolleri ve modern mesajlaşma kriptografisi

Modül özeti

Algoritma yığınını protokol hedefleriyle birleştirir: AKE, 0-RTT sınırları, HPKE modları ve Signal ailesinin forward secrecy / PCS dilini doğru kurmak.

Modül 5 — Güvenli Kanal Protokolleri ve Modern Mesajlaşma Kriptografisi

Kriptografik algoritmalar tek başına güvenlik sağlamaz. Anahtar anlaşması, kimlik doğrulama, iletim güvenliği, bütünlük kontrolü ve ileri gizlilik gibi özelliklerin doğru bir protokol içinde bir araya getirilmesi gerekir. En güçlü simetrik ve asimetrik algoritmalar bile yanlış protokol tasarımıyla kullanıldığında MITM, replay, downgrade veya unknown key-share gibi saldırılara açık kalabilir.

Bu modül, temel eğitimde kavramsal düzeyde geçilen TLS’i mimari bütünlüğüyle ele alır. TLS 1.3’ün HKDF tabanlı key schedule yapısı, 0-RTT güvenlik sınırları, downgrade koruması, sertifika doğrulama zinciri ve Certificate Transparency yaklaşımı ayrıntılı biçimde incelenir. TLS 1.3, RFC 8446 ile tanımlanmıştır ve TLS 1.2’ye göre handshake, cipher suite yapısı ve anahtar türetme mimarisi açısından ciddi değişiklikler getirir.

TLS bölümünden hareketle HPKE’nin KEM tabanlı tasarım felsefesi, ardından Signal protokol ailesinin X3DH ve Double Ratchet yapısı işlenir. HPKE, RFC 9180’de KEM + KDF + AEAD bileşenlerinden oluşan hibrit açık anahtar şifreleme çerçevesi olarak tanımlanır. Signal tarafında ise X3DH asenkron başlangıç oturumu kurmayı, Double Ratchet ise mesaj bazında anahtar yenileme, forward secrecy ve post-compromise security hedeflerini destekler.

Modülün önemli bir kısmı protokol saldırılarına ayrılmıştır; fakat odak saldırı pratiği değil, güvenli protokol tasarımında hangi mekanizmanın hangi saldırı sınıfını kapattığını anlamaktır. Öğrenci bu modülü tamamladığında TLS 1.3 handshake akışını analiz edebilmeli, testssl.sh veya SSL Labs çıktısını güvenlik açısından yorumlayabilmeli, downgrade ve 0-RTT risklerini net biçimde tarif edebilmeli, Signal ve HPKE gibi modern protokollerin neyi garanti edip neyi etmediğini açıklayabilmelidir.

Bu modül önceki dört modülle doğrudan ilişkilidir. Formal güvenlik modelleri, AEAD ve simetrik kripto, KDF yapıları ve ECC/ECDH burada birleşerek gerçek güvenli kanal protokollerine dönüşür. Bu yüzden modül boyunca “hangi algoritma kullanılıyor?” sorusundan çok “hangi güvenlik hedefi hangi protokol adımıyla sağlanıyor?” sorusu öne çıkar.

Kazanımlar

Öğrenci bu modül sonunda:

Authenticated Key Exchange yapılarının temel güvenlik hedeflerini — karşılıklı kimlik doğrulama, forward secrecy, identity protection ve key compromise impersonation direnci — formal modelle ilişkilendirerek açıklayabilir.

TLS 1.3 handshake akışını key schedule ve HKDF bağlamında adım adım yorumlayabilir; Early Secret, Handshake Secret, Master Secret ve bunlardan türetilen traffic secret değerlerinin rolünü tarif edebilir.

0-RTT veri gönderiminin ne anlama geldiğini, hangi güvenlik garantilerini zayıflattığını ve replay’e hassas işlemlerde neden dikkatli kullanılmaması gerektiğini açıklayabilir.

HPKE’nin KEM, KDF ve AEAD üçlüsünden nasıl kurulduğunu; base, psk, auth ve auth_psk modlarının güvenlik hedefleri açısından nasıl ayrıldığını değerlendirebilir.

X3DH anahtar anlaşmasını ve Double Ratchet mekanizmasını forward secrecy ile post-compromise security açısından karşılaştırmalı biçimde analiz edebilir.

Replay, downgrade, MITM, unknown key-share ve protokol bileşimi hatalarını güvenlik modeli perspektifiyle açıklayabilir; her saldırı sınıfına karşı hangi protokol mekanizmasının koruma sağladığını söyleyebilir.

Wireshark’ta TLS 1.3 handshake paketlerini kavramsal düzeyde okuyabilir; hangi mesajların açık, hangilerinin şifreli taşındığını ve bunun güvenlik açısından ne anlama geldiğini tarif edebilir.

OpenSSL s_client, testssl.sh ve SSL Labs raporlarını güvenlik açısından yorumlayabilir; zayıf cipher suite, eski TLS sürümü, forward secrecy eksikliği veya sertifika zinciri sorunları gibi bulguları teknik olarak açıklayabilir.

Certificate Transparency’nin neden var olduğunu, hangi sertifika türleri için kritik olduğunu, SCT’nin ne anlama geldiğini ve CT kaydı eksikliğinin hangi bağlamlarda risk göstergesi sayılabileceğini açıklayabilir.

Protokol analiz araçlarının yalnızca izinli sistemlerde kullanılabileceğini ve araç çıktısının kesin hüküm değil, güvenlik bağlamıyla yorumlanması gereken bir sinyal olduğunu ifade edebilir.

Authenticated Key Exchange

Temel eğitimde Diffie-Hellman’ın iki tarafın ortak bir sır üretmesini nasıl sağladığı öğrenilmişti. Ancak saf Diffie-Hellman karşı tarafın kimliğini doğrulamaz. Araya giren bir saldırgan, Alice ile ayrı, Bob ile ayrı DH gerçekleştirerek iki farklı güvenli kanal kurabilir ve tarafların birbirleriyle doğrudan konuştuğunu düşünmesini sağlayabilir. Bu klasik MITM senaryosu, anahtar anlaşmasının tek başına yeterli olmadığını gösterir.

Authenticated Key Exchange, anahtar anlaşmasını kimlik doğrulamayla birleştirir. Amaç yalnızca ortak bir sır üretmek değil, bu sırrın gerçekten beklenen tarafla kurulduğunu kanıtlamaktır. Modern AKE protokollerinde tarafların imza anahtarları, sertifikaları, pre-shared key bilgileri veya uzun vadeli kimlik anahtarları anahtar anlaşması transcript’ine bağlanır. Böylece saldırgan anahtar anlaşmasının bir parçasını değiştirirse Finished mesajı, imza doğrulaması veya transcript hash kontrolü başarısız olur.

AKE güvenlik hedeflerinin merkezinde forward secrecy yer alır. Forward secrecy, uzun vadeli özel anahtar sonradan ele geçirilse bile geçmiş oturum trafiğinin çözülememesi anlamına gelir. Bunun için oturum anahtarları yalnızca uzun vadeli anahtarlardan türetilmez; her oturumda taze ephemeral DH veya ECDH katkısı kullanılır. Ephemeral private key değerleri oturumdan sonra silindiğinde, uzun vadeli anahtarın sonradan ele geçirilmesi geçmiş trafik için yeterli olmaz.

Kimlik doğrulama ve forward secrecy birlikte tasarlanmalıdır. Uzun vadeli anahtar yalnızca kimlik kanıtlamak için kullanılır; gerçek oturum sırrı ephemeral anahtar anlaşmasından gelir. TLS 1.3’te sunucu sertifikası ve imza adımı, handshake transcript’ini bağlayarak sunucunun kimliğini kanıtlar; oturum anahtarı ise ephemeral key exchange ve HKDF zinciri üzerinden türetilir.

Key Compromise Impersonation, AKE protokollerinde daha az bilinen ama önemli bir hedeftir. Alice’in uzun vadeli özel anahtarı sızarsa saldırganın Alice gibi davranabilmesi beklenen bir sonuçtur. Fakat iyi tasarlanmış bir AKE protokolünde bu sızıntı, saldırganın Bob gibi davranarak Alice’i kandırmasına otomatik olarak izin vermemelidir. Yani bir tarafın anahtarının sızması, karşı tarafın kimliğini taklit etmeyi kolaylaştırmamalıdır.

Identity protection ise handshake sırasında taraf kimliklerinin pasif gözlemciden ne ölçüde korunduğuyla ilgilidir. TLS 1.3, sertifika mesajlarını TLS 1.2’ye göre daha erken şifreli bölüme taşıyarak sunucu sertifikasının pasif gözlemci tarafından doğrudan görülmesini engeller. Ancak bu tam kimlik gizliliği anlamına gelmez. ECH kullanılmadıkça SNI açıkta kalabilir; IP adresi, DNS sorguları ve trafik meta verileri de sunucu kimliği hakkında bilgi verebilir. Bu yüzden TLS 1.3, kimlik gizliliğini güçlendirir ama tek başına tam identity protection sağlamaz.

Anahtar anlaşması ile kimlik doğrulamayı sonradan birbirine eklenen iki bağımsız katman gibi görmek protokol bileşimi hatalarına yol açar. Güçlü protokollerde hangi mesajın neyi imzaladığı, hangi bağlam bilgisinin transcript’e dahil edildiği ve hangi anahtarın hangi amaçla kullanıldığı baştan tanımlıdır. Bu bütünleşik tasarım olmadığında “imzaladım ama neyi imzaladım?” sorusu belirsiz kalır ve unknown key-share gibi saldırılar mümkün hâle gelebilir.

TLS 1.3 Derinlemesine

TLS 1.3, 2018’de RFC 8446 ile yayımlanmıştır. TLS 1.2’ye göre yalnızca küçük bir sürüm artışı değil, handshake yapısında, key schedule tasarımında, cipher suite modelinde ve güvenlik varsayımlarında önemli bir yeniden düzenlemedir. TLS 1.3, statik RSA key exchange gibi forward secrecy sağlamayan yapıları kaldırmış, AEAD tabanlı modern cipher suite’leri merkeze almış ve HKDF tabanlı açık bir anahtar programı oluşturmuştur.

TLS 1.3 handshake’i normal durumda 1-RTT ile tamamlanır. İstemci ClientHello mesajında desteklediği TLS sürümlerini, cipher suite’leri, key share gruplarını ve uzantıları gönderir. Sunucu ServerHello ile seçilen parametreleri ve kendi key share değerini döner. Bu noktadan sonra handshake’in önemli bölümü türetilen handshake traffic secret değerleriyle şifrelenir.

TLS 1.3’te sunucu sertifikası TLS 1.2’de olduğu gibi açıkta taşınmaz; şifreli handshake kayıtları içinde gönderilir. Bu, pasif gözlemciye karşı önemli bir iyileştirmedir. Ancak Wireshark gibi araçlar oturum anahtarlarıyla beslenirse bu şifreli kayıtları çözebilir ve Certificate mesajlarını gösterebilir. Anahtar logu yoksa TLS 1.3 Certificate ve Finished mesajları dışarıdan genellikle Application Data gibi görünen şifreli kayıtlar içinde kalır.

TLS 1.3’ün en ayırt edici teknik özelliklerinden biri HKDF tabanlı key schedule yapısıdır. Ana omurga Early Secret, Handshake Secret ve Master Secret üzerinden kurulur. Resumption Master Secret ise Master Secret’tan türetilen ve oturum devamı için kullanılan ayrı bir değerdir; ana omurgadaki üçlü sır dizisiyle aynı seviyede “dördüncü ana sır” gibi anlatılmamalıdır. Bu ayrım, TLS 1.3 anahtar programını doğru okumak açısından önemlidir.

Early Secret, PSK veya sıfır girdiden başlatılan erken aşama sırrıdır. Handshake Secret, ephemeral key exchange sonucuyla birlikte türetilir ve handshake mesajlarının korunmasında kullanılır. Master Secret ise uygulama trafiği, exporter secret ve resumption gibi sonraki türetmelerin temelidir. Bu yapı, her aşamada hangi materyalin hangi anahtarı beslediğini açıkça tanımlar.

Client Handshake Traffic Secret ve Server Handshake Traffic Secret, handshake’in şifreli bölümünü korur. Handshake tamamlandıktan sonra Client Application Traffic Secret ve Server Application Traffic Secret devreye girer. İstemciden sunucuya ve sunucudan istemciye akan trafik ayrı traffic secret değerlerinden türetilen ayrı anahtarlarla korunur. Bu yön ayrımı, tek bir yönün anahtar materyalinin diğer yönü doğrudan etkilemesini engeller.

TLS 1.3’te cipher suite yapısı TLS 1.2’den farklıdır. TLS 1.2 cipher suite adları çoğu zaman key exchange, authentication, encryption ve MAC bileşenlerini birlikte ifade ederdi. TLS 1.3’te cipher suite temel olarak AEAD algoritmasını ve hash fonksiyonunu belirtir; key exchange ise supported groups, key_share ve PSK mekanizmaları gibi uzantılar üzerinden yürür. Bu nedenle TLS 1.3 için “cipher suite ECDHE içeriyor mu?” şeklindeki TLS 1.2 alışkanlığı doğrudan uygulanmamalıdır.

TLS 1.3 statik RSA ve statik DH key exchange’i kaldırır. Normal tam handshake senaryosunda DHE veya ECDHE tabanlı ephemeral key exchange kullanılır. Bunun yanında PSK-only ve PSK-DHE resumption modları da vardır. PSK-only mod forward secrecy sağlamaz; PSK-DHE ise taze DH katkısıyla forward secrecy özelliğini korumaya çalışır. Bu ayrım, session resumption ve 0-RTT değerlendirmelerinde özellikle önemlidir.

0-RTT, TLS 1.3’ün performans için sunduğu ama dikkatli yönetilmesi gereken özelliğidir. İstemci, önceki bir oturumdan elde edilen PSK/resumption materyaline dayanarak handshake tamamlanmadan uygulama verisi gönderebilir. Bu, gecikmeyi azaltır; ancak 0-RTT verisi 1-RTT uygulama trafiğiyle aynı güvenlik seviyesine sahip değildir. En önemli sınır, 0-RTT verisinin replay’e karşı protokol düzeyinde tam koruma sağlamamasıdır. RFC 8446, 0-RTT replay riskinin uygulama ve sunucu politikalarıyla ele alınması gerektiğini açıkça belirtir.

0-RTT verisi replay edildiğinde zarar doğurmayacak idempotent işlemlerle sınırlandırılmalıdır. Statik içerik çekme veya tekrarlandığında yan etkisi olmayan sorgular bu sınıfa daha yakındır. Ödeme, sipariş oluşturma, parola değiştirme, yetki yükseltme, para transferi, stok azaltma veya kritik durum güncellemesi gibi replay edildiğinde zarar doğurabilecek işlemler 1-RTT sonrasına bırakılmalıdır. Sorun “kimlik doğrulama gerektiren her işlem” değil, replay edildiğinde güvenlik veya iş mantığı açısından zarar doğurabilecek işlemlerdir.

Downgrade koruması TLS 1.3’te önemli bir tasarım noktasıdır. TLS 1.3 destekleyen bir sunucu daha düşük bir TLS sürümüne düşerse, ServerHello.random alanına özel downgrade sentinel değerleri yerleştirir. İstemci bu değerleri kontrol ederek beklenmeyen downgrade girişimini tespit edebilir. Bu mekanizma, doğru istemci kontrolü ve güvenli minimum sürüm politikasıyla birlikte anlamlıdır; tek başına bütün kötü yapılandırmaları telafi eden sihirli bir koruma değildir.

Sertifika doğrulama TLS’in kimlik doğrulama temelidir. İstemci, sunucu sertifikasının Subject Alternative Name alanındaki adla bağlandığı alan adını eşleştirir, sertifika zincirini güvenilen bir köke kadar doğrular, geçerlilik tarihlerini ve imza algoritmalarını kontrol eder. Sertifika zinciri doğru değilse güçlü cipher suite kullanılması bağlantının kimlik doğrulamasını kurtarmaz.

Certificate Transparency, CA ekosistemindeki yanlış veya kötü niyetli sertifika düzenlemelerini görünür hâle getirmeyi hedefler. CT, özellikle publicly trusted CA’lerden alınan ve modern tarayıcılar tarafından güvenilecek TLS sertifikaları için kritik bir gereksinimdir. Chrome’un CT politikasına göre CT enforcement bulunan sürümlerde publicly trusted TLS sertifikalarının başarılı doğrulama için CT-compliant olması gerekir. Private CA veya kurum içi sertifikalar aynı CT beklentisine otomatik olarak tabi değildir.

CT, sahte veya yanlış düzenlenmiş sertifikaları kriptografik olarak imkânsız hâle getirmez. Bunun yerine public loglar ve Signed Certificate Timestamp kontrolü sayesinde gizli issuance’ı tespit edilebilir hâle getirir. Bazı tarayıcı politikalarında SCT varlığı güven kararının parçası hâline gelir. Bu yüzden CT hem izleme/şeffaflık mekanizması hem de public web PKI bağlamında istemci güven politikasının bir bileşeni olarak anlaşılmalıdır.

TLS 1.2 ile TLS 1.3 arasındaki farklar şu şekilde özetlenebilir:

Özellik TLS 1.2 TLS 1.3

Anahtar değişimi Statik RSA, DHE/ECDHE ve farklı kombinasyonlar mümkün olabilir. Statik RSA ve statik DH kaldırılmıştır; key_share ve PSK mekanizmaları kullanılır.

Forward secrecy Cipher suite seçimine bağlıdır. Normal DHE/ECDHE tam handshake için varsayılan güvenlik hedefidir; PSK-only resumption ayrıca değerlendirilir.

Handshake round-trip Genellikle 2-RTT. Normalde 1-RTT; 0-RTT isteğe bağlıdır.

Sertifika görünürlüğü Sertifika açık handshake içinde görülür. Sertifika şifreli handshake kayıtlarında taşınır.

Şifreleme/bütünlük CBC+MAC gibi eski yapılar mümkün olabilir. AEAD tabanlı modern yapı kullanılır.

Cipher suite modeli Key exchange, authentication, cipher ve MAC birlikte adlandırılır. Cipher suite temel olarak AEAD + hash bilgisini taşır; key exchange uzantılarla belirlenir.

Downgrade koruması Daha sınırlı ve yapılandırmaya bağlıdır. TLS 1.3 destekleyen sunucularda, daha eski sürüme düşüş senaryolarını tespit etmeye yardımcı olan ServerHello.random downgrade sentinel değerleriyle güçlendirilmiştir.

0-RTT Yoktur. Vardır; replay riski nedeniyle dikkatli kullanılmalıdır.

HPKE Mantığı

HPKE, yani Hybrid Public Key Encryption, RFC 9180 ile standartlaştırılmış modern bir hibrit açık anahtar şifreleme çerçevesidir. HPKE’nin amacı, açık anahtar tabanlı anahtar kurulumunu, KDF ile anahtar türetmeyi ve AEAD ile veri şifrelemeyi tek bir tutarlı yapıda birleştirmektir. Bu sayede geliştiriciler RSA-OAEP benzeri doğrudan açık anahtar şifreleme kalıpları yerine, büyük verileri AEAD ile şifreleyen ve oturum sırrını KEM ile kuran standart bir çerçeve kullanabilir.

Buradaki “hybrid” ifadesi, klasik ve post-kuantum algoritmaların birlikte kullanıldığı PQC hibrit geçiş anlamına gelmez; HPKE bağlamında açık anahtar tabanlı anahtar kurulumu ile simetrik AEAD şifrelemenin standart bir çerçevede birleştirilmesini ifade eder.

HPKE’nin çekirdeğinde KEM, yani Key Encapsulation Mechanism bulunur. KEM geleneksel “mesajı public key ile doğrudan şifrele” yaklaşımından farklıdır. Gönderen, alıcının public key’ini kullanarak bir shared secret ve buna bağlı bir encapsulated key, yani enc değeri üretir. Alıcı private key’iyle enc değerini işleyerek aynı shared secret değerini elde eder. Bu shared secret doğrudan uygulama mesajını şifrelemek için kullanılmaz; KDF’ye girer ve AEAD anahtarlarına dönüştürülür.

HPKE, KEM + KDF + AEAD üçlüsünden oluşur. Gönderen önce alıcının public key’iyle shared secret ve enc üretir. Ardından shared secret ve bağlam bilgisi KDF’ye verilir. KDF, AEAD için key, base nonce ve exporter secret gibi değerleri üretir. Mesaj AEAD ile şifrelenir ve enc değeri ciphertext ile birlikte alıcıya gönderilir. Alıcı kendi private key’iyle aynı shared secret’ı tekrar elde eder, aynı KDF sürecini çalıştırır ve AEAD doğrulama/çözme işlemini yapar.

HPKE’nin dört temel modu vardır: base, psk, auth ve auth_psk. Base mode, gönderici kimliği hakkında kriptografik kanıt sağlamaz; alıcı, mesajın kendi public key’i için şifrelendiğini doğrulayabilir ama gönderenin kim olduğunu HPKE base mode üzerinden bilemez. PSK mode, önceden paylaşılan bir sırrı bağlama dahil eder. Auth mode, gönderenin belirli bir KEM private key’e sahip olduğunu alıcıya kriptografik olarak bağlar. Auth_psk mode ise authenticated sender anahtarı ve PSK kullanımını birlikte ele alır. RFC 9180, bu modları HPKE’nin çalışma biçimleri olarak tanımlar.

HPKE auth mode tam anlamıyla klasik karşılıklı AKE protokolü gibi anlatılmamalıdır. Auth mode, gönderici kimliğini alıcıya kriptografik olarak bağlar; fakat uygulama düzeyinde bu public key’in kime ait olduğu, nasıl dağıtıldığı, nasıl doğrulandığı ve metadata’nın nasıl korunduğu ayrıca tasarlanmalıdır. RFC 9180, authenticated modlarda göndericiyle ilişkili key material bilgisinin alıcı tarafından bilinmesi gerektiğini ve bunun metadata koruması açısından dikkat gerektirebileceğini belirtir.

HPKE’nin açık anahtar şifrelemeye göre önemli avantajı, büyük veriyi public key işlemiyle değil AEAD ile şifrelemesidir. KEM yalnızca shared secret kurar; asıl mesaj simetrik AEAD ile korunur. Bu yaklaşım performans, mesaj boyutu ve bütünlük doğrulaması açısından daha pratik ve daha modern bir tasarım sunar.

HPKE, nonce ve KDF bağlamını standart bir context içinde yöneterek yaygın bileşim hatalarını azaltır. Fakat “nonce reuse veya domain separation hataları tanım gereği tamamen imkânsızdır” demek fazla kesin olur. HPKE context doğru yönetilirse AEAD nonce’ları base nonce ve sequence number mantığıyla güvenli biçimde türetilir. Ancak context reuse, yanlış state yönetimi, standart dışı implementasyon veya düşük seviye API hataları hâlâ risk oluşturabilir.

HPKE mimarisi KEM tabanlı olduğu için post-kuantum KEM’lerle profillenmeye uygundur. Ancak RFC 9180’in temel KEM seti klasik DHKEM seçeneklerini içerir; ML-KEM gibi post-kuantum KEM’lerin HPKE içinde kullanımı için ayrıca profil, standartlaşmış entegrasyon veya ilgili taslakların izlenmesi gerekir. Bu nedenle “ML-KEM doğrudan standart HPKE içinde hazırdır” gibi bir anlam verilmemelidir.

HPKE’nin gerçek değeri, şifreleme, bütünlük, anahtar kurulumu ve bağlam ayrımını tek bir standart çerçeveye taşımasıdır. Böylece geliştiricinin “RSA ile bir anahtar şifreleyeyim, sonra AES-GCM yapayım, nonce’u kendim yöneteyim” gibi hata üretmeye açık bileşimler kurma ihtiyacı azalır. Yine de güvenlik, kullanılan HPKE suite seçimine, context yönetimine, private key korumasına ve uygulama düzeyindeki kimlik doğrulamaya bağlıdır.

Signal Protokolü ve Modern Mesajlaşma

Signal protokol ailesi, asenkron uçtan uca şifreli mesajlaşma için modern standartlardan biri hâline gelmiştir. Signal uygulaması, WhatsApp ve bazı modern mesajlaşma sistemleri Signal Protocol ailesindeki X3DH ve Double Ratchet benzeri mekanizmalardan yararlanır. Ancak bu, tüm uygulamaların birebir aynı güvenlik profiline sahip olduğu anlamına gelmez. Çoklu cihaz mimarisi, yedekleme politikası, metadata yönetimi, grup mesajlaşması ve sunucu davranışı güvenlik profilini değiştirebilir.

X3DH, Extended Triple Diffie-Hellman anlamına gelir. Amaç, Bob çevrimdışıyken Alice’in Bob ile güvenli bir başlangıç oturumu kurabilmesidir. Bob sunucuya bazı public key materyalleri yükler: uzun vadeli Identity Key, orta vadeli Signed Prekey ve varsa One-Time Prekey değerleri. Signed Prekey, Bob’un identity key’iyle imzalandığı için Alice bu prekey’in Bob’a ait olduğunu doğrulayabilir. X3DH spesifikasyonu, protokolün asenkron ortamlarda ortak sır kurduğunu, forward secrecy ve deniability hedeflediğini belirtir.

X3DH’de Alice normalde DH1, DH2 ve DH3 hesaplamalarını yapar. Bob’un one-time prekey’i mevcutsa DH4 de eklenir. Yani “Alice her zaman dört ECDH işlemi yapar” demek doğru değildir. OPK yoksa protokol yine çalışabilir; fakat one-time prekey’in sağladığı bazı ek güvenlik özellikleri ve başlangıçtaki tazelik katkısı zayıflar. Bu nedenle OPK stok yönetimi operasyonel güvenlik açısından önemlidir.

X3DH’in güçlü tarafı, asenkron başlangıç sorununu kriptografik olarak çözmesidir. Bob çevrimdışıyken bile Alice, sunucudan aldığı imzalı prekey materyaliyle Bob’un kriptografik kimliğine bağlı bir başlangıç sırrı kurabilir. Ancak sunucu prekey dağıtımında aracı olduğu için istemcinin imzaları doğru doğrulaması, identity key değişikliklerini kullanıcıya anlamlı biçimde sunması ve OPK stoklarını yönetmesi gerekir.

Double Ratchet, X3DH sonrasında mesajların anahtar yaşam döngüsünü yönetir. İki ratchet birlikte çalışır: symmetric-key ratchet ve Diffie-Hellman ratchet. Her mesajda symmetric-key ratchet ilerleyerek yeni bir message key üretir. Bu mesaj anahtarı kullanıldıktan sonra silinir. Böylece gelecekteki state sızsa bile geçmiş mesaj anahtarlarına geri dönmek zorlaşır.

DH ratchet ise her mesajda zorunlu olarak çalışmaz. Yeni bir DH public key alındığında veya taraf yeni ratchet adımına geçtiğinde root chain güncellenir ve yeni sending/receiving chain değerleri oluşturulur. Bu ayrım önemlidir: Double Ratchet’te mesaj bazında sürekli ilerleyen mekanizma symmetric-key ratchet’tir; DH ratchet ise konuşmanın yönü ve yeni ratchet public key değişimleriyle devreye girer.

Forward secrecy, Double Ratchet’in geçmiş mesajları koruma tarafıdır. Kullanılmış message key değerleri silindiğinde, daha sonraki state ele geçirilse bile geçmiş mesaj anahtarlarına geri dönmek mümkün olmamalıdır. Bu, her mesaj için ayrı anahtar türetmenin temel güvenlik etkisidir.

Post-compromise security ise daha dikkatli tanımlanmalıdır. Saldırgan bir cihazın mevcut state’ine geçici olarak erişmişse ve daha sonra bu erişimi kaybederse, taraflar yeni DH ratchet adımlarıyla ilerledikçe gelecekteki mesajlar yeniden korunabilir hâle gelir. Ancak saldırgan cihazda kalıcı erişime sahipse, yeni state’i de görebilir; bu durumda post-compromise security sağlanamaz. Bu yüzden PCS “saldırgan anahtarı bir süre gördü ama artık içeride değil” varsayımıyla anlamlıdır.

Asenkron mesajlaşmada mesajların sırayla gelmemesi normaldir. Double Ratchet bu durum için skipped message key yönetimi gibi mekanizmalar kullanır. Ancak bu da uygulama açısından hassas bir yaşam döngüsü problemi doğurur: Bazı geçmiş message key değerleri kısa süreli saklanabilir; saklama sınırı, bellek yönetimi ve silme politikası doğru uygulanmalıdır. Çok uzun süre veya sınırsız saklanan skipped key değerleri forward secrecy hedefini zayıflatabilir.

Cihaz değişimi ve identity key yenileme de güvenlik açısından önemlidir. Kullanıcı yeni cihaza geçtiğinde veya oturumu yeniden kurduğunda X3DH benzeri başlangıç prosedürleri yeniden gündeme gelir. Eski identity key korunacak mı, yeni identity key üretilecek mi, kullanıcı karşı tarafın kimlik değişimini nasıl görecek? Bu sorular yalnızca kriptografik değil, aynı zamanda ürün tasarımı ve kullanıcı güvenliği sorularıdır.

Protokol Saldırıları

Protokol güvenliği, bileşen algoritmalarının güvenli olmasından fazlasını gerektirir. Güvenli bir AEAD, güçlü bir ECDH veya doğru bir HMAC tek başına güvenli protokol oluşturmaz. Protokol seviyesindeki saldırılar çoğu zaman algoritmayı kırmaz; mesajların sırasını, kimlik bağlamını, sürüm müzakeresini veya state yönetimini hedef alır.

Replay saldırılarında saldırgan, daha önce geçerli olan bir mesajı veya handshake parçasını yeniden oynatarak sistemin tekrar aynı tepkiyi vermesini sağlamaya çalışır. TLS içinde record layer sequence number ve AEAD doğrulaması aynı bağlantı içindeki tekrar ve değiştirme girişimlerini engeller. Finished mesajı ise handshake transcript’inin bütünlüğünü bağlar. Ancak 0-RTT verisi için replay riski tamamen TLS tarafından ortadan kaldırılmaz; uygulama ve sunucu anti-replay politikası gerekir.

Downgrade saldırılarında araya giren saldırgan, tarafları daha eski bir protokol sürümüne veya daha zayıf algoritmalara yönlendirmeye çalışır. TLS 1.3’te ServerHello.random alanındaki downgrade sentinel değerleri bu sınıfa karşı önemli bir tespit mekanizmasıdır. Bunun yanında minimum TLS sürümü politikası, zayıf cipher suite’lerin kapatılması ve istemci tarafında doğru doğrulama da gerekir.

MITM saldırılarında saldırgan, anahtar anlaşması sırasında iki taraf arasında aktif aracı hâline gelir. Kimlik doğrulama olmayan saf DH bu saldırıya açıktır. TLS, sertifika doğrulama, transcript imzaları ve Finished mesajlarıyla bunu engellemeye çalışır. Fakat CA altyapısındaki zayıflıklar, kullanıcıların sertifika uyarılarını atlaması, private key sızıntıları veya kurumsal TLS interception mimarileri MITM riskini yeniden gündeme getirebilir.

Unknown key-share saldırıları, taraflardan birinin oturumu kiminle kurduğunu yanlış anlamasıdır. Alice belirli bir anahtar üzerinde anlaştığını düşünür; fakat bu anahtarın kimlik bağlamı yanlış bağlanmıştır. Bu saldırılar genellikle key exchange materyali ile kimlik bilgisinin transcript içinde yeterince bağlanmadığı protokollerde ortaya çıkar. TLS 1.3, sertifika doğrulaması, CertificateVerify ve Finished mesajlarıyla transcript’i bağlayarak bu riski azaltır.

Protokol bileşimi hataları, iki güvenli protokolün yan yana kullanıldığında beklenmeyen boşluklar üretmesidir. TLS üzerinde çalışan uygulama katmanı token sistemi, TLS’in sağladığı kanal bütünlüğüne güvenebilir; fakat uygulama kimlik doğrulamasından tamamen vazgeçerse farklı bir güvenlik boşluğu doğar. Aynı şekilde uçtan uca şifreleme kullanan bir mesajlaşma sisteminde yedeklemeler plaintext olarak buluta gidiyorsa, protokolün uçtan uca güvenliği uygulama katmanında zayıflar.

Bu yüzden güvenlik analisti bir protokolü değerlendirirken “şifreleme var mı?” sorusundan önce “neyin kimliği doğrulanıyor, hangi bağlam korunuyor, hangi state ne zaman siliniyor ve hangi mesaj replay’e açık?” sorularını sormalıdır. Protokol güvenliği bağlam, sıra, kimlik ve state yönetimiyle birlikte düşünülür.

TLS ve Protokol Analiz Araçları

Bu bölüm, öğrencinin protokol konularını yalnızca teorik düzeyde öğrenmesini değil, gerçek araç çıktılarını okuyarak yorumlayabilmesini hedefler. Buradaki araç kullanımları yalnızca izinli sistemlerde, eğitim ortamlarında veya kişinin kendi altyapısında yapılmalıdır. Üçüncü taraf sistemlere izinsiz tarama yapmak güvenlik analizi değil, yetkisiz faaliyettir.

Wireshark ile TLS 1.3 Handshake Akışını Okuma

Wireshark’ta TLS 1.3 oturumu incelenirken amaç, handshake akışını ve kayıtların ne zaman şifreli hâle geldiğini anlamaktır. ClientHello ve ServerHello açık görülebilir. ServerHello sonrasında TLS 1.3 handshake mesajlarının önemli bölümü şifreli kayıtlar içinde taşınır. Sertifika ve Finished mesajları TLS 1.2’deki gibi açık certificate record olarak görünmez.

TLS 1.3 yakalamasında ChangeCipherSpec bazı uyumluluk modlarında görülebilir. Bu mesaj TLS 1.3’ün güvenlik açısından esas işlevsel mesajı değildir; middlebox uyumluluğu için korunmuş dummy bir kayıt gibi değerlendirilmelidir. Bu yüzden “ChangeCipherSpec görüldü, demek TLS 1.2 davranışı var” şeklinde otomatik yorum yapılmamalıdır. RFC 8446, TLS 1.3 middlebox compatibility mode bağlamında bu davranışı açıklar.

Wireshark oturum anahtarı loglarıyla beslenmemişse Certificate ve Finished gibi şifreli handshake içeriklerini ayrıştıramaz; bunları şifreli Application Data veya benzeri kayıtlar olarak gösterebilir. Eğer NSS key log veya uygun TLS key log dosyası sağlanırsa Wireshark şifreli kayıtların içindeki handshake mesajlarını çözebilir. Bu ayrım öğrencinin araç çıktısını doğru yorumlaması için önemlidir.

Normal bir TLS 1.3 gözleminde ClientHello, ServerHello ve ardından şifreli handshake/application data kayıtları görülür. TLS 1.2’ye geri düşme, eski cipher suite’lerin müzakere edilmesi veya beklenmeyen açık sertifika çerçeveleri ayrıca incelenmelidir.

OpenSSL s_client Çıktısını Yorumlama

OpenSSL s_client, belirli bir sunucuya TLS bağlantısı kurarak müzakere edilen protokol sürümünü, cipher suite’i ve sertifika zincirini görmeye yarar. İzinli bir test sunucusunda şu tür çıktılar incelenebilir:

Protocol satırı müzakere edilen TLS sürümünü gösterir. Cipher satırı seçilen TLS cipher suite’i belirtir. TLS 1.3 için TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 ve TLS_CHACHA20_POLY1305_SHA256 gibi seçenekler modern ve beklenen sonuçlardır. TLS_AES_128_GCM_SHA256, RFC 8446’da zorunlu uygulanacak TLS 1.3 cipher suite olarak tanımlandığı için güvenli kabul edilen normal bir çıktıdır.

Verify return code: 0 (ok) sertifika zincirinin doğrulandığını gösterir. Sıfır dışındaki değerler sertifika süresi, güvenilmeyen CA, ad uyuşmazlığı veya zincir eksikliği gibi sorunları işaret edebilir. Ancak s_client çıktısı tek bir bağlantı denemesinin görüntüsüdür. Sunucunun desteklediği tüm TLS sürümlerini, tüm cipher suite’leri ve tüm yapılandırma risklerini tek başına göstermez.

TLS 1.2 müzakere edilmişse cipher suite adındaki key exchange kısmı ayrıca okunmalıdır. TLS_RSA_WITH_AES_128_CBC_SHA gibi statik RSA içeren suite’ler forward secrecy sağlamaz. Buna karşılık TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 gibi suite’lerde ECDHE forward secrecy sağlar ve GCM AEAD kullanır. TLS 1.3’te bu bilgi cipher suite adında değil, handshake uzantılarında ve protokol yapısında yer alır.

testssl.sh ile İzinli TLS Yapılandırma Analizi

testssl.sh, hedef sunucunun desteklediği TLS sürümlerini, cipher suite’leri, sertifika zincirini, forward secrecy durumunu, HSTS başlığını ve çeşitli protokol özelliklerini sistematik biçimde test eder. Yalnızca sahibi olunan veya yazılı izin alınmış sistemlerde çalıştırılmalıdır. Araç gerçek bağlantılar kurar; bu nedenle izinsiz hedeflerde kullanılması güvenlik taraması kapsamına girer.

testssl.sh çıktısında ilk bakılacak yer desteklenen TLS sürümleridir. Public web servisleri için TLS 1.0 ve TLS 1.1’in devre dışı olması beklenir. TLS 1.2 desteği bazı legacy istemciler için gerekebilir; TLS 1.3 desteği ise modern yapılandırma için güçlü bir göstergedir. TLS 1.2 desteği tek başına sorun değildir; sorun TLS 1.2 içinde zayıf cipher suite’lerin veya statik RSA key exchange’in açık kalmasıdır.

Cipher suite bölümünde NULL, EXPORT, RC4, DES, 3DES veya statik RSA gibi seçenekler varsa bunlar bağlama göre risk olarak raporlanmalıdır. Forward secrecy satırı yalnızca bazı cipher suite’lerde etkin görünüyorsa, zayıf suite’ler kapatılmalıdır. Public web HTTPS servislerinde HSTS ve CT de ayrıca değerlendirilir.

HPKP güncel bir güvenlik kontrol başlığı gibi ele alınmamalıdır. HTTP Public Key Pinning modern tarayıcılarda terk edilmiş ve önerilmeyen bir mekanizmadır; yanlış kullanımı erişilebilirlik ve operasyonel felaketlere yol açabildiği için Certificate Transparency ve daha güvenli sertifika izleme yaklaşımları öne çıkmıştır. Chromium tarafında HPKP’nin kaldırılmasına yönelik süreç yıllar önce başlatılmıştır.

HSTS, tarayıcı tabanlı HTTPS kullanımında SSL stripping riskini azaltır. Özellikle domain daha önce HSTS politikası öğrenmişse veya preload listesinde yer alıyorsa etkilidir. Ancak tarayıcı dışı TLS istemcilerinde HSTS aynı anlama gelmez. İlk ziyaret ve preload olmayan domainlerde HSTS’nin koruması sınırlıdır. Bu nedenle HSTS bulgusu da bağlama göre yorumlanmalıdır.

Certificate Transparency kaydı public web HTTPS servisleri için beklenen bir göstergedir. Dahili/private CA kullanılan, mTLS ağırlıklı veya tarayıcı dışı TLS servislerinde CT yokluğu otomatik olarak açık değildir. Chrome CT policy publicly trusted TLS sertifikaları için CT-compliant olma beklentisini tanımlar; private trust anchor kullanılan kurum içi sistemler farklı değerlendirilir.

Certificate Transparency Kayıtlarını İnceleme

CT logları, publicly trusted sertifikaların hangi CA tarafından, hangi alan adı için ve hangi tarihte düzenlendiğini izlemeyi sağlar. Bir kurum kendi domainleri için CT loglarını izleyerek beklenmeyen sertifika düzenlemelerini tespit edebilir. Bu özellikle marka kötüye kullanımı, yanlış CA issuance veya potansiyel MITM altyapısı kurma girişimleri için erken uyarı sağlayabilir.

CT kaydının varlığı tek başına sertifikanın güvenli veya meşru olduğu anlamına gelmez. CT, sertifikanın loglandığını gösterir; kimlik doğrulama, CA güvenilirliği, alan adı kontrolü ve sertifika politikası ayrıca değerlendirilmelidir. Buna karşılık publicly trusted web sertifikasında SCT yokluğu modern tarayıcı politikaları açısından bağlantının reddedilmesine veya güven problemi oluşmasına yol açabilir.

İleri Seviye Güvenli Analiz / Kontrol Listesi

Bir TLS yapılandırmasını veya güvenli kanal protokolünü değerlendirirken önce kapsam ve izin netleştirilmelidir. Hedef sistem kime ait? Test aralığı ve yöntemi onaylandı mı? Kullanılacak araçlar aktif bağlantı kuruyor mu? Analiz yalnızca teknik doğruluk değil, operasyonel güvenlik ve yasal sınır açısından da kontrollü yapılmalıdır.

Kontrol edilecek ilk başlık protokol sürümüdür. Public web sistemleri için TLS 1.0 ve TLS 1.1 kapalı olmalıdır. TLS 1.2 destekleniyorsa yalnızca güçlü, forward secrecy sağlayan ve AEAD kullanan suite’ler açık bırakılmalıdır. TLS 1.3 destekleniyorsa bu olumlu bir göstergedir; fakat eski sürüm ve zayıf suite desteği hâlâ açık olabilir.

Cipher suite değerlendirmesinde TLS 1.2 ile TLS 1.3 ayrımı yapılmalıdır. TLS 1.2’de cipher suite adı key exchange bilgisini içerir. TLS 1.3’te cipher suite adı AEAD ve hash bilgisini taşır; key exchange mekanizması handshake uzantılarında yürür. Bu fark bilinmeden yapılan yorumlar hatalı raporlara yol açabilir.

Sertifika tarafında zincir bütünlüğü, SAN uyumu, son kullanma tarihi, imza algoritması, key usage ve extended key usage alanları kontrol edilmelidir. Public web servislerinde CT ve HSTS ayrıca incelenmelidir. Dahili servislerde private CA politikası, mTLS gereksinimi ve istemci doğrulama akışı daha önemli olabilir.

0-RTT destekleniyorsa hangi endpoint’lerin 0-RTT kabul ettiği ve hangi HTTP metodlarına izin verildiği incelenmelidir. Replay’e hassas işlemler 0-RTT’ye açık olmamalıdır. Load balancer, CDN ve çoklu backend mimarilerinde anti-replay state paylaşımı ayrıca değerlendirilmelidir.

Araç çıktısı nihai karar değildir. testssl.sh, SSL Labs, OpenSSL ve Wireshark farklı açılardan sinyal üretir. Bir araç “warning” verdiğinde bağlam sorulmalı; bir araç “ok” verdiğinde de tüm risklerin kapandığı varsayılmamalıdır. Güvenlik kararı, araç çıktısı ile protokol bilgisi ve sistem bağlamının birlikte yorumlanmasıyla verilir.

Geliştirici ve güvenlik ekibine öneri dili teknik ama uygulanabilir olmalıdır. Örneğin:

“Mevcut yapılandırmada TLS 1.0 ve TLS 1.1 desteği açık görünüyor. Bu sürümler modern güvenlik politikalarıyla uyumlu değildir ve ödeme gibi hassas trafiklerde strong cryptography beklentisini zayıflatır. TLS 1.0/1.1 devre dışı bırakılmalı, TLS 1.2 için yalnızca ECDHE + AEAD tabanlı suite’ler bırakılmalı ve TLS 1.3 desteklenmelidir. Kapatma öncesinde legacy istemci trafiği loglardan doğrulanmalı, değişiklik sonrası testssl.sh ile tekrar kontrol yapılmalıdır.”

Analitik Senaryo

Durum

Güvenlik mühendisi analyst01, bir e-ticaret platformunun ödeme altyapısında kullanılan TLS-GW01 adlı TLS geçidini değerlendirmekle görevlendirilmiştir. Kurumsal güvenlik politikası yalnızca TLS 1.2 ve üstünü, ayrıca yalnızca forward secrecy sağlayan cipher suite’leri desteklemeyi şart koşmaktadır. Ekip, geçen ay yapılandırmada elle değişiklik yapıldığını ve bu değişikliğin dokümante edilmediğini öğrenmiştir.

İlk Değerlendirme

Elle yapılmış ve dokümante edilmemiş bir yapılandırma değişikliği policy drift riski taşır. Öncelikle müzakere edilebilen protokol sürümleri ve cipher suite’ler politikayla karşılaştırılmalıdır. TLS 1.3 destekleniyor olması tek başına yeterli değildir; eski TLS sürümleri veya zayıf TLS 1.2 cipher suite’leri hâlâ açık olabilir.

İncelenecek Araç Çıktısı

testssl.sh çıktısında şu bulgular görülüyor:

Bu çıktı iki kritik sorunu gösterir. Birincisi, TLS 1.0 ve TLS 1.1 hâlâ aktiftir. Bu politika ihlalidir ve modern istemciler için gereksiz bir zayıf protokol yüzeyi oluşturur. İkincisi, TLS_RSA_WITH_AES_128_CBC_SHA statik RSA key exchange içerdiği için forward secrecy sağlamaz. Sunucu private key’i ileride ele geçirilirse, geçmişte kaydedilmiş bu oturumların trafiği çözülebilir.

HSTS başlığının olmaması public web tarayıcı bağlamında SSL stripping riskine karşı ek korumanın bulunmadığını gösterir. Ancak HSTS yalnızca tarayıcı bağlamında anlamlıdır; API istemcileri veya mobil uygulamalar için sertifika pinning, trust store politikası veya uygulama katmanı kontrolleri ayrıca değerlendirilmelidir.

Güvenli Doğrulama Yaklaşımı

Önce testssl.sh çıktısı ikinci bir araçla doğrulanmalıdır. OpenSSL s_client ile belirli TLS sürümleri zorlanarak hangi cipher suite’lerin müzakere edilebildiği kontrol edilebilir. Yapılandırma dosyası tarafında enabled protocol ve cipher list değerleri incelenmelidir. Load balancer veya CDN varsa testin gerçekten aynı endpoint’e ulaştığı doğrulanmalıdır.

TLS 1.0 ve TLS 1.1 devre dışı bırakılmalıdır. TLS 1.2 için statik RSA cipher suite’ler kaldırılmalı, yalnızca ECDHE tabanlı ve AEAD kullanan suite’ler bırakılmalıdır. TLS 1.3 desteklenmeye devam etmelidir. Değişiklik sonrası testssl.sh yeniden çalıştırılmalı ve çıktı politika dokümantasyonuna işlenmelidir.

Yanlış Yorumlama İhtimali

“TLS 1.3 destekleniyor, problem yok” yorumu hatalıdır. TLS 1.3 desteği, eski protokollerin kapalı olduğu veya TLS 1.2 içinde zayıf cipher suite bulunmadığı anlamına gelmez. Müzakere sürecinde istemci veya saldırgan tarafından zayıf seçenekler tercih edilebilir hâlde bırakılmışsa risk devam eder.

“Cipher suite AES içeriyor, o hâlde güçlüdür” yorumu da eksiktir. TLS_RSA_WITH_AES_128_CBC_SHA AES kullanır; fakat statik RSA key exchange nedeniyle forward secrecy sağlamaz ve CBC+SHA yapısı modern AEAD yaklaşımına göre daha eski bir tasarımdır. Cipher suite yalnızca şifreleme algoritmasına bakılarak değerlendirilemez.

Riskin Pratik Karşılığı

Ödeme altyapısında TLS 1.0/1.1 desteği, PCI DSS v4.0.1’in strong cryptography beklentisiyle uyumsuzluk riski doğurur ve acil kapatılması gereken zayıf protokol desteği olarak raporlanmalıdır. PCI DSS Requirement 4, açık/public ağlarda hassas kart verisinin güçlü kriptografiyle korunmasını ister.

Forward secrecy eksikliği, pasif olarak kaydedilmiş geçmiş trafiğin gelecekteki private key sızıntısıyla çözülebilmesine yol açabilir. Bu özellikle ödeme, kimlik doğrulama veya kişisel veri taşıyan sistemlerde ciddi bir güvenlik zafiyetidir.

Önerilen Güvenli Yaklaşım

TLS 1.0 ve TLS 1.1 devre dışı bırakılmalıdır. TLS 1.2 tarafında statik RSA tabanlı cipher suite’ler kaldırılmalı, ECDHE + AEAD tabanlı suite’ler bırakılmalıdır. TLS 1.3 aktif tutulmalı ve tercih edilen protokol olarak yapılandırılmalıdır.

Public web endpoint için HSTS başlığı uygun bir max-age değeriyle eklenmelidir. Preload düşünülüyorsa alt alan adları, operasyonel hazırlık ve geri dönüş planı dikkatle değerlendirilmelidir. HSTS tarayıcı bağlamında etkilidir; tarayıcı dışı istemciler için ayrıca istemci tarafı TLS doğrulama politikaları incelenmelidir.

Yapılandırma değişikliği sonrası testssl.sh ve OpenSSL ile doğrulama yapılmalı, sonuçlar güvenlik politikası dokümantasyonuna eklenmelidir. Legacy istemci uyumluluk riski production erişim loglarından ölçülmeli ve kapatma planı teknik paydaşlarla paylaşılmalıdır.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

AKE Authenticated Key Exchange; anahtar anlaşmasını kimlik doğrulamayla birleştiren protokol yapısı.

Forward Secrecy Uzun vadeli anahtar sonradan ele geçirilse bile geçmiş oturum trafiğinin korunması.

Post-Compromise Security Geçici state sızıntısı sona erdikten sonra yeni ratchet adımlarıyla gelecekteki mesajların yeniden korunabilmesi.

KCI Key Compromise Impersonation; bir tarafın anahtarı sızdığında saldırganın karşı tarafı taklit edip edememesiyle ilgili saldırı modeli.

Identity Protection Handshake sırasında taraf kimliklerinin pasif gözlemciden korunması hedefi; TLS 1.3 bunu güçlendirir ama ECH olmadan tam sağlamaz.

Traffic Secret TLS 1.3’te belirli yön ve aşama için trafik anahtarlarının türetildiği gizli değer.

Key Schedule Protokol boyunca anahtar materyalinin nasıl türetildiğini tanımlayan yapı.

0-RTT TLS 1.3’te önceki oturumdan gelen PSK ile handshake tamamlanmadan erken veri gönderimi.

Replay saldırısı Geçerli bir mesajın tekrar oynatılarak sistemin yeniden tepki vermesini hedefleyen saldırı.

Downgrade saldırısı Tarafları daha eski protokol sürümüne veya zayıf algoritmaya zorlayan saldırı.

Downgrade sentinel TLS 1.3’te ServerHello.random içinde kullanılan ve downgrade tespitine yardım eden özel değerler.

KEM Key Encapsulation Mechanism; public key kullanarak shared secret ve kapsül değeri üreten yapı.

HPKE RFC 9180 ile tanımlanan KEM + KDF + AEAD tabanlı hibrit public key encryption çerçevesi.

HPKE base mode Gönderici kimlik doğrulaması sağlamayan temel HPKE modu.

HPKE auth mode Göndericinin belirli bir KEM private key’e sahip olduğunu alıcıya bağlayan HPKE modu.

AEAD Authenticated Encryption with Associated Data; gizlilik ve bütünlüğü birlikte sağlayan şifreleme yapısı.

X3DH Signal protokol ailesinde asenkron başlangıç oturumu kurmak için kullanılan Extended Triple Diffie-Hellman protokolü.

Identity Key X3DH’de uzun vadeli kimlik anahtarı.

Signed Prekey X3DH’de identity key ile imzalanmış orta vadeli prekey.

One-Time Prekey X3DH’de varsa başlangıç oturumuna ek tazelik sağlayan tek kullanımlık prekey.

Double Ratchet Signal protokolünde DH ratchet ve symmetric-key ratchet’i birleştiren mesaj anahtarı yenileme mekanizması.

Symmetric-key ratchet Her mesajda yeni message key türeten tek yönlü KDF zinciri.

DH ratchet Yeni DH public key değişimiyle root chain’i yenileyen ratchet mekanizması.

Skipped message key Sıra dışı gelen mesajları çözebilmek için kısa süreli saklanan geçmiş mesaj anahtarları.

MITM Man-in-the-middle; saldırganın iki taraf arasında aktif aracı hâline geldiği saldırı.

UKS Unknown Key-Share; taraflardan birinin oturumu hangi kimlikle kurduğunu yanlış anlaması.

Protocol Composition Birden fazla protokolün birlikte kullanılmasında güvenlik garantilerinin nasıl birleştiği problemi.

Certificate Transparency Publicly trusted TLS sertifikalarının public loglarda görünür olmasını sağlayan şeffaflık mekanizması.

SCT Signed Certificate Timestamp; CT logunun sertifika için verdiği imzalı kayıt damgası.

Cipher Suite TLS’te kullanılan şifreleme parametre seti; TLS 1.3’te temel olarak AEAD ve hash fonksiyonunu belirtir.

HSTS HTTP Strict Transport Security; tarayıcıya belirli domain için HTTPS kullanımını zorunlu kılan başlık.

HPKP HTTP Public Key Pinning; modern tarayıcılarda terk edilmiş, artık önerilmeyen eski pinning mekanizması.

PSK Pre-Shared Key; TLS 1.3’te resumption ve 0-RTT bağlamında kullanılan önceden paylaşılmış sır.

ECH Encrypted Client Hello; TLS ClientHello içindeki hassas bilgileri, özellikle SNI’yi gizlemeyi hedefleyen mekanizma.

Kendini Değerlendir — İleri Kriptografi Modül 5

Bu Modülde Neler Öğrendik?

Bu modülde, önceki modüllerde öğrenilen ECDH, HKDF, AEAD, sertifika altyapısı ve formal güvenlik modellerinin gerçek güvenli kanal protokollerinde nasıl birleştiğini gördük. AKE’nin yalnızca ortak sır üretmek değil, bu sırrı doğru kimlikle bağlamak anlamına geldiğini öğrendik.

TLS 1.3’ün key schedule yapısını Early Secret, Handshake Secret ve Master Secret omurgası üzerinden okuduk. Resumption Master Secret’ın ayrı bir resumption değeri olduğunu, traffic secret’ların yönlere ve aşamalara göre ayrıldığını, cipher suite yapısının TLS 1.2’den farklılaştığını netleştirdik.

0-RTT’nin performans avantajının replay riskiyle birlikte geldiğini gördük. 0-RTT verisi replay’e açık olabileceği için ödeme, sipariş, yetki değişimi veya durum değiştiren işlemler bu kanalda taşınmamalıdır. Güvenli tasarımda 0-RTT, yalnızca replay edildiğinde zarar doğurmayacak idempotent işlemlerle sınırlandırılmalıdır.

HPKE’nin KEM + KDF + AEAD çerçevesi, modern public key encryption tasarımını standart ve daha az hata yaptıran bir yapıya taşır. Base, psk, auth ve auth_psk modlarının farklı güvenlik hedefleri olduğunu; auth mode’un gönderici kimlik bağlamı sağladığını ama tam karşılıklı AKE ile aynı şey olmadığını öğrendik.

Signal protokol ailesi tarafında X3DH’nin asenkron başlangıç oturumu kurduğunu, OPK varsa dördüncü DH katkısının eklendiğini ve Double Ratchet’in her mesajda symmetric-key ratchet’i ilerlettiğini gördük. DH ratchet’in her mesajda değil, yeni ratchet public key adımlarında çalıştığını netleştirdik.

Forward secrecy ile post-compromise security arasındaki ayrımı doğru kurduk. Forward secrecy geçmiş mesajları korurken, post-compromise security saldırganın geçici state erişimi sona erdikten sonra gelecekteki mesajların yeniden korunabilmesini ifade eder. Sürekli cihaz kompromisi varsa bu garanti sağlanamaz.

Protokol saldırılarını replay, downgrade, MITM, unknown key-share ve protokol bileşimi hataları üzerinden değerlendirdik. Bu saldırıları yalnızca saldırı ismi olarak değil, “hangi protokol mekanizması bu riski kapatır?” sorusuyla yorumlamayı öğrendik.

Araç okuryazarlığı tarafında Wireshark, OpenSSL s_client, testssl.sh ve SSL Labs çıktılarının nasıl okunacağını gördük. Araç çıktısının tek başına kesin hüküm olmadığını; TLS sürümü, cipher suite, sertifika zinciri, CT, HSTS ve kullanım bağlamının birlikte yorumlanması gerektiğini öğrendik.

Certificate Transparency’nin özellikle publicly trusted TLS sertifikaları için neden kritik olduğunu, private CA/dahili sistemlerde CT beklentisinin farklı değerlendirileceğini ve HPKP’nin güncel bir öneri değil, terk edilmiş tarihsel bir mekanizma olduğunu netleştirdik.

Bu modül, post-kuantum geçiş senaryoları için de zemin oluşturur. TLS 1.3 key schedule ve HPKE’nin KEM tabanlı yapısı, ileride ML-KEM gibi post-kuantum KEM’lerin hangi mimari noktalara yerleşebileceğini anlamak için gerekli düşünce çerçevesini sağlar.

MODÜL 6 — Sıfır bilgi ispatları ve gizlilik koruyucu kriptografi

Modül özeti

ZKP’yi yalnızca “kanıt var” değil; hangi relation, hangi setup, hangi transcript bağlama ve hangi uygulama entegrasyonu sorularıyla okumayı sağlar.

Modül 6 — Sıfır Bilgi İspatları ve Gizlilik Koruyucu Kriptografi

Sıfır bilgi ispatları, kriptografinin en zarif kavramlarından birini taşır: bir şeyi bildiğinizi, o şeyi açıklamadan kanıtlamak. Bu fikir ilk bakışta soyut görünse de modern kimlik doğrulama sistemlerinden gizlilik koruyucu blok zinciri protokollerine, uyumluluk kanıtlarından anonimleştirilmiş yetki doğrulamaya kadar giderek daha somut bir mühendislik gerçekliğine dönüşmüştür. Modül 5’te TLS 1.3 ve Signal gibi protokollerde güvenli kanal, kimlik doğrulama ve forward secrecy kavramlarını ele aldık. Bu modülde ise kriptografinin daha ileri bir gizlilik katmanına, yani ispat sistemlerine geçiyoruz.

Bu modülde ZKP’nin üç temel özelliğini güvenlik modeli perspektifinden okuyacak, Sigma protokollerini ve Fiat–Shamir dönüşümünü etkileşimli yapıdan etkileşimsiz yapıya geçiş mantığıyla değerlendireceğiz. Fiat–Shamir dönüşümünde challenge değerinin yalnızca bir commitment’tan değil, statement, public input, transcript ve domain separation bilgisi gibi bağlamlardan türetilmesi gerektiğini özellikle vurgulayacağız. Çünkü etkileşimsiz ispatlarda güvenlik, yalnızca kullanılan hash fonksiyonuna değil, neyin hash kapsamına alındığına da bağlıdır. Fiat–Shamir dönüşümü, public-coin etkileşimli ispatlarda verifier challenge’larının rastgele kahin çıktılarıyla değiştirilmesi fikrine dayanır; modern uygulamalarda transcript ve bağlam bağlama ayrıntısı kritik önemdedir.

Ardından zk-SNARKs, zk-STARKs ve Bulletproofs gibi modern yapıları; trusted setup sorunu, proof boyutu, prover maliyeti ve doğrulama maliyeti gibi pratik eksenlerden karşılaştıracağız. Trusted setup meselesi özellikle dikkatli ele alınacaktır: tek taraflı veya kötü yürütülen setup’ta toxic waste’i bilen taraf sahte ispat üretebilirken, çok katılımcılı MPC törenlerinde güvenlik “en az bir katılımcı katkısını gizli tutup imha ettiyse” varsayımına dayanır. Bu ayrım yapılmadan trusted setup anlatımı eksik kalır.

Kullanım alanlarını incelediğimizde uyumluluk ile gizlilik arasındaki gerilimi göreceğiz. Yaş doğrulama, üyelik ispatı, bakiye aralığı kanıtı veya işlem geçerliliği gibi senaryolarda ZKP güçlü bir araç olabilir; ancak ispatlanan değerin güvenilir bir credential, commitment veya protokol bağlamına bağlı olması gerekir. Aksi hâlde sistem yalnızca kullanıcının kendi seçtiği bir değeri ispatlamış olur.

Modülün son bölümünde Circom, Noir ve ZoKrates gibi araçları operasyonel bir komut ezberi olarak değil, ekosistemin olgunluk düzeyini, denetlenebilirlik riskini ve devre güvenliğinin önemini anlamak için ele alacağız. Buradaki temel mesaj şudur: “Proof doğrulandı” demek, “sistem güvenli” demek değildir. Proof’un doğrulanması, yalnızca belirli verification key, public input ve constraint sistemi altında ispatın tutarlı olduğunu gösterir. Devrenin doğru problemi modelleyip modellemediği ayrıca denetlenmelidir.

Bu modül, öğrencinin ileri kriptografide “şifreleme ötesi” kavramları güvenlik modeli, tasarım kararı ve uygulama riski açısından yorumlayabilmesini hedefler. Araştırma ağırlıklı olan bu alanı üretim sistemleri açısından nereye konumlandırmak gerektiğini net biçimde ortaya koymak, modülün ana değerlerinden biridir.

Kazanımlar

Öğrenci bu modül sonunda:

Sıfır bilgi ispatlarının completeness, soundness ve zero-knowledge özelliklerini güvenlik modeli çerçevesinde açıklayabilir; bu özelliklerin perfect, statistical veya computational modellerde sağlanabileceğini ayırt edebilir.

Completeness garantisinin bazı sistemlerde hatasız, bazı sistemlerde ise ihmal edilebilir hata olasılığıyla sağlandığını ifade edebilir.

Soundness garantisinin computational, statistical veya perfect olmasının sistemin güvenlik varsayımını nasıl değiştirdiğini yorumlayabilir.

Zero-knowledge özelliğinin simülatör argümanıyla nasıl tanımlandığını ve verifier’ın öğrendiği bilginin hangi model altında sınırlandırıldığını açıklayabilir.

Sigma protokollerinin commit → challenge → response üç adımlı yapısını ve bu yapının Schnorr gibi klasik protokollerde nasıl kullanıldığını açıklayabilir.

Fiat–Shamir dönüşümünün etkileşimli ispatları etkileşimsiz yapıya nasıl taşıdığını, challenge değerinin transcript ve domain separation bilgisine bağlanmamasının replay, malleability ve cross-protocol risklerine nasıl yol açabileceğini değerlendirebilir.

AND ve OR ispatlarını doğru biçimde ayırabilir; AND ispatlarının konjunktif, OR ispatlarının ise disjunktif önermeleri temsil ettiğini ifade edebilir.

zk-SNARKs, zk-STARKs ve Bulletproofs arasındaki farkları proof boyutu, trusted setup gerekliliği, prover/verifier maliyeti ve post-kuantum güvenlik beklentileri açısından karşılaştırabilir.

Trusted setup meselesini, toxic waste kavramını, çok katılımcılı MPC törenlerinin güven modelini ve başarısız ya da belirsiz setup sürecinin sistem güvenliğine etkisini açıklayabilir.

Range proof, üyelik ispatı, kimlik doğrulama ve blockchain geçerlilik kanıtı gibi kullanım alanlarını gerçek sistem gereksinimleriyle ilişkilendirebilir.

Circom, Noir ve ZoKrates gibi araçların ne amaçla kullanıldığını, circuit/devre mantığını, prover-verifier ayrımını ve bu ekosistemi üretim olgunluğu açısından değerlendirebilir.

ZKP araçlarının denetlenebilirlik, standartlaşma, bakım maliyeti, trusted setup, verification key yönetimi ve devre doğruluğu açısından taşıdığı riskleri ifade edebilir.

Bir ZKP sistemini değerlendirirken hangi güvenlik varsayımlarına dayandığını, hangi güven modelini kullandığını ve hangi uygulama risklerini taşıdığını belirleyerek geliştiriciye veya mimari ekibe aktarabilir.

ZKP Temelleri

Sıfır bilgi ispatı, bir prover’ın bir verifier’a belirli bir önermenin doğru olduğunu, önermenin doğruluğunu sağlayan sırrı açıklamadan kanıtlamasını sağlayan kriptografik bir yapıdır. Bu tanım ilk duyuşta felsefi görünebilir; fakat arkasında kesin biçimde formüle edilen üç temel özellik vardır: completeness, soundness ve zero-knowledge.

Completeness, önerme gerçekten doğruysa ve prover gerçekten gerekli bilgiye sahipse, dürüst prover’ın dürüst verifier’ı protokolün tanımladığı başarı koşulları içinde ikna edebilmesidir. Bazı protokollerde bu garanti olasılık 1 ile sağlanabilir; bazı sistemlerde ise ihmal edilebilir hata olasılığı bulunabilir. Eğitim seviyesinde “doğru bilgiye sahip olan taraf ispatı geçirebilmelidir” şeklinde düşünülebilir, ancak ileri seviyede completeness garantisinin hangi hata modeliyle sağlandığı ayrıca okunmalıdır.

Soundness, önerme yanlışsa veya prover gerekli witness’a sahip değilse, verifier’ı ikna etme olasılığının çok düşük olmasıdır. Bu özellik olmadan sistem güvenlik sağlamaz; çünkü bilgiyi bilmeyen bir taraf geçerli proof üretebilir hâle gelir. Soundness garantisi computational, statistical veya perfect olabilir. Computational soundness, sınırlı hesaplama gücüne sahip verimli saldırganlara karşı geçerlidir ve genellikle belirli kriptografik varsayımlara dayanır. Statistical soundness, sınırsız hesaplama gücüne sahip verifier veya saldırgan karşısında bile ihmal edilebilir hata dışında geçerlilik sağlar. Perfect soundness ise hata olasılığını tamamen ortadan kaldıran daha güçlü bir modeldir.

Zero-knowledge özelliği, verifier’ın ispat sürecinden sırrın kendisi hakkında tanımın izin verdiği modelin ötesinde bilgi öğrenmemesidir. Bu garanti de perfect, statistical veya computational zero-knowledge biçiminde sağlanabilir. Perfect zero-knowledge’da gerçek transcript ile simülatörün ürettiği transcript dağılımı aynıdır. Statistical zero-knowledge’da dağılımlar istatistiksel olarak çok yakındır. Computational zero-knowledge’da ise verimli bir ayırt edici, gerçek transcript ile simülasyonu pratikte ayırt edemez.

Zero-knowledge özelliğinin arkasındaki temel fikir simülatör argümanıdır. Eğer verifier’ın gördüğü her şey, witness bilinmeden çalışan bir simülatör tarafından ayırt edilemez biçimde üretilebiliyorsa, verifier’ın ispat sürecinden witness hakkında gerçek bir bilgi öğrenmediği söylenir. Burada önemli nokta, verifier’ın hiçbir şey öğrenmemesi değildir; verifier en azından önermenin doğru olduğunu öğrenir. Sıfır bilgi, bu bilginin ötesinde witness hakkında ek bilgi sızmamasını hedefler.

Bu üç özellik ZKP’yi klasik kimlik doğrulama veya challenge-response sistemlerinden ayırır. Klasik bir sistemde kullanıcı parolasını, gizli anahtara bağlı bir değeri veya tekrar kullanılabilir bir token’ı gösterebilir. ZKP’de ise amaç, sırrı ifşa etmeden ve verifier’a yeniden kullanılabilir hassas bilgi vermeden doğruluğu kanıtlamaktır. Bu yüzden ZKP, yalnızca “şifrelenmiş veri göndermek” değil, daha farklı bir kriptografik güvenlik katmanıdır.

Etkileşimli ispatlarda prover ve verifier arasında birden fazla mesaj alışverişi olur. Verifier, belirli adımlarda rastgele challenge değerleri üretir ve prover bu challenge’lara yanıt verir. Bu modelde verifier’ın challenge rastgeleliği protokol güvenliği için çok önemlidir. Eğer challenge tahmin edilebilir veya prover tarafından kontrol edilebilir hâle gelirse soundness zayıflayabilir.

Etkileşimsiz ispatlarda ise verifier’ın aktif katılımı ortadan kaldırılır ve proof tek bir mesaj olarak üretilebilir hâle gelir. Bu dönüşüm dağıtık sistemler, blockchain doğrulamaları ve çevrimdışı proof paylaşımı için çok değerlidir. Fiat–Shamir dönüşümü, birçok public-coin etkileşimli ispatı etkileşimsiz yapıya taşımak için kullanılan temel tekniktir. Ancak bu dönüşümün güvenliği, rastgele kahin modeli ve transcript bağlama ayrıntılarıyla birlikte değerlendirilmelidir.

Bir ZKP sistemini değerlendirirken ilk sorulardan biri şudur: Sistem hangi tür completeness, soundness ve zero-knowledge garantisi sunuyor? Bu garanti hangi varsayıma dayanıyor? Verifier kötü niyetli mi kabul ediliyor, yoksa honest-verifier zero-knowledge gibi daha sınırlı bir model mi kullanılıyor? Bu ayrımlar yapılmadan “ZKP kullanılıyor” cümlesi güvenlik açısından yeterli değildir.

Sigma Protokolleri

Sigma protokolleri, ZKP’nin en temel yapı taşlarından biridir. Adını üç adımlı akıştan alır: commit → challenge → response. Bu yapı, şekil olarak Σ harfine benzetildiği için Sigma protokolü olarak anılır.

Akışın mantığı basittir. Prover önce bir commitment üretir ve verifier’a gönderir. Verifier rastgele bir challenge seçer. Prover bu challenge’a yanıt verir. Verifier, commitment, challenge ve response üçlüsünün tutarlı olup olmadığını kontrol eder. Bu yapı, belirli bir witness’ın bilindiğini witness’ı açıklamadan ispatlamaya yarar.

Schnorr protokolü bu yapının en bilinen örneklerinden biridir. Prover, y = g^x denkleminde x değerini bildiğini, x’i açıklamadan kanıtlar. Protokol ayrık logaritma probleminin zorluğu üzerine kurulur. Bu protokolün önemi yalnızca kimlik ispatı açısından değil, imza şemalarının tasarımını anlamak açısından da büyüktür. Schnorr imzaları, Schnorr kimlik ispatının Fiat–Shamir dönüşümüyle etkileşimsizleştirilmiş imza biçimi olarak okunabilir.

EdDSA da Schnorr-benzeri bir imza ailesidir; ancak doğrudan “klasik Schnorr protokolünün aynısıdır” şeklinde anlatılmamalıdır. EdDSA’nın deterministic nonce üretimi, Edwards eğrileri, encoding biçimi ve domain separation ayrıntıları kendi standart bağlamıyla değerlendirilmelidir. Bu nüans, imza şemalarının ispat sistemleriyle bağlantısını doğru kurmak için önemlidir.

Chaum–Pedersen protokolü, iki ayrık logaritmanın eşit olduğunu ispatlamak için kullanılan klasik bir Sigma protokolüdür. Basitçe, prover iki farklı tabanda aynı gizli x değerini kullandığını, x’i açıklamadan kanıtlar. Bu tür ispatlar gizlilik koruyucu oylama, anonim kimlik doğrulama ve karmaşık protokol bileşimlerinde kullanılabilir.

AND ve OR ispatları, Sigma protokollerini bileşik önermeler için genelleştirir. AND ispatında prover, “A bilgisini ve B bilgisini biliyorum” der. Bu konjunktif bir önermedir. OR ispatında ise prover, “A veya B’den en az birini biliyorum” der. Bu disjunktif bir önermedir. OR ispatlarının ilginç tarafı, prover’ın hangi sırrı bildiğini açıklamadan bu disjunktif ifadeyi ispatlayabilmesidir. Bu özellik anonim kimlik doğrulama ve gizlilik koruyucu üyelik kanıtlarında değerlidir.

Fiat–Shamir dönüşümü, etkileşimli Sigma protokollerini etkileşimsiz hâle getirmek için kullanılır. Temel fikir, verifier’ın rastgele üretmesi gereken challenge değerini bir hash fonksiyonuyla deterministik olarak üretmektir. Fakat bu challenge yalnızca commitment’tan türetilmemelidir. Güvenli tasarımda statement, public input, commitment, önceki transcript, protokol adı, sürüm bilgisi ve domain separation etiketi hash kapsamına alınmalıdır. Modern literatürde Fiat–Shamir dönüşümü, public-coin etkileşimli protokollerde verifier challenge’larının transcript’e bağlı rastgele kahin çıktılarıyla değiştirilmesi olarak ele alınır.

Neyin hash’e dahil edildiği güvenliği doğrudan etkiler. Mesaj, oturum kimliği, public input veya protokol tanımlayıcısı hash kapsamına alınmazsa proof başka bağlamda tekrar kullanılabilir. Bu durum replay, malleability veya cross-protocol karışıklığına yol açabilir. Bu yüzden Fiat–Shamir dönüşümünde domain separation yalnızca iyi bir yazılım alışkanlığı değil, güvenlik modelinin parçasıdır.

Schnorr imzaları bu bakışla daha anlaşılır hâle gelir. İmza üretiminde challenge, commitment, public key ve mesaj gibi bağlamların hashlenmesiyle oluşturulur. Mesaj hash kapsamına alınmazsa aynı proof farklı mesaj için kullanılabilir hâle gelebilir. Public key veya domain separator eksikse farklı protokol bağlamları karışabilir. Bu nedenle etkileşimsiz ispatlarda transcript bağlama, imza güvenliğine çok yakın bir problem olarak düşünülmelidir.

Modern ZKP Yapıları

Sigma protokolleri anlaşılır ve verimlidir; fakat genellikle belirli cebirsel önermeler için uygundur. Genel hesaplamaları, yani “bu program şu girdilerle doğru çalıştı” türü ifadeleri ispatlamak için daha güçlü yapılara ihtiyaç vardır. zk-SNARKs, zk-STARKs ve Bulletproofs bu noktada devreye girer.

zk-SNARKs, “Succinct Non-interactive Arguments of Knowledge” ifadesinin kısaltmasıdır. Buradaki “succinct” kelimesi, proof boyutunun küçük ve doğrulama maliyetinin düşük olmasını ifade eder. Groth16 gibi yaygın SNARK sistemlerinde proof boyutu çok küçüktür ve doğrulama oldukça verimlidir. Bu özellik, özellikle blockchain gibi doğrulama maliyetinin doğrudan işlem ücretine dönüştüğü ortamlarda önemlidir.

SNARK sistemlerinin önemli bir kısmı trusted setup gerektirir. Trusted setup sırasında ortak referans parametreleri üretilir. Bazı yapılarda bu süreçte ortaya çıkan gizli ara değerler toxic waste olarak adlandırılır. Eğer toxic waste bilen bir taraf varsa, sistemin soundness garantisi zayıflayabilir ve sahte proof üretme riski oluşabilir.

Buradaki ayrım hassastır. Tek taraflı veya kötü yürütülen setup’ta toxic waste’i bilen taraf sahte ispat üretebilir. Çok katılımcılı MPC setup törenlerinde ise güvenlik genellikle en az bir katılımcının katkısını gizli tutup imha ettiği varsayımına dayanır. Yani “herhangi bir katılımcı kendi sırrını saklarsa sistem çöker” demek doğru değildir. Asıl risk, final trapdoor bilgisinin tek bir tarafça veya tüm kötü niyetli katılımcılarca bilinebilir hâle gelmesidir. Setup törenlerinde katılımcıların rastgelelik katkısı, transcript doğrulanabilirliği ve toxic waste’in imha edildiğine dair prosedürler bu yüzden kritiktir.

Universal setup, bazı modern SNARK sistemlerinde trusted setup yükünü azaltmak için kullanılan yaklaşımdır. Bu modelde setup bir kez yapılır ve belirli boyut sınırları içinde farklı devreler için kullanılabilir. Yine devreye özgü proving key veya verification key üretimi yapılabilir; fakat Groth16’daki gibi her devre için ayrı trusted ceremony gerekmeyebilir. snarkjs dokümantasyonu da Groth16’ın her circuit için trusted ceremony gerektirdiğini, PLONK ve FFLONK için ise universal Powers of Tau töreninin yeterli olduğunu belirtir.

zk-STARKs, “Scalable Transparent Arguments of Knowledge” olarak adlandırılır. “Transparent” ifadesi trusted setup gerektirmemesini vurgular. STARK’lar hash tabanlı ve post-kuantum açısından daha güçlü kabul edilen yapılardır; ancak güvenlik yalnızca “hash collision resistance” cümlesine indirgenmemelidir. FRI/low-degree testing, sonlu alan aritmetiği, Fiat–Shamir dönüşümü ve hash/random oracle modellemesi birlikte değerlendirilmelidir.

STARK’ların güçlü yanı trusted setup gerektirmemesi ve büyük hesaplamaları ispatlama konusunda ölçeklenebilir olmalarıdır. Bunun bedeli genellikle proof boyutudur. STARK proof’ları işlenen veri miktarına göre kompakt olabilir; fakat Groth16 gibi çok kısa SNARK proof’larına kıyasla daha büyük olma eğilimindedir. Doğrulama asimptotik olarak verimlidir; ancak pratik doğrulama maliyeti ve veri boyutu karşılaştırması seçilen SNARK/STARK sistemine göre değişir. Bu nedenle “STARK doğrulaması her zaman daha düşüktür” gibi bir ifade doğru değildir.

Bulletproofs, trusted setup gerektirmeyen kısa/logaritmik boyutlu ispatlar sunan bir yapıdır. Özellikle range proof alanında bilinir. Bulletproofs, gizli bir committed değerin belirli bir aralıkta olduğunu değeri açıklamadan ispatlamak için kullanılabilir. Bulletproofs makalesi bu yapıyı trusted setup gerektirmeyen kısa non-interactive zero-knowledge proof protokolü olarak tanımlar.

Bulletproofs’un proof boyutu Groth16 gibi çok küçük SNARK proof’larına göre daha büyük olabilir; doğrulama maliyeti de bazı SNARK sistemlerine göre daha yüksektir. Buna rağmen trusted setup gerektirmemesi ve range proof’lar için doğal bir çözüm sunması onu belirli senaryolarda değerli kılar. Monero gibi gizlilik koruyucu kripto para sistemlerinde miktar gizleme amacıyla kullanılmıştır.

Aşağıdaki tablo genel yönelimleri gösterir; her satır tüm akademik varyantları kapsayan mutlak bir hüküm gibi okunmamalıdır:

Özellik zk-SNARKs zk-STARKs Bulletproofs

Trusted setup Birçok yaygın yapıda gerekir; bazı modern yapılarda universal setup kullanılabilir. Gerekmez. Gerekmez.

Proof boyutu Genellikle çok küçük. SNARK’lara kıyasla genellikle daha büyük. Range proof için kısa/logaritmik; Groth16 gibi SNARK’lara kıyasla daha büyük olabilir.

Prover maliyeti Yüksek olabilir. Genellikle yüksek; büyük hesaplamalar için ölçeklenebilir yapı sunar. Orta-yüksek; kullanım senaryosuna bağlıdır.

Verifier maliyeti Groth16 gibi yapılarda çok düşüktür. Asimptotik olarak verimli; pratikte proof boyutu nedeniyle maliyet artabilir. Genellikle SNARK doğrulamasından daha ağır olabilir.

Post-kuantum beklentisi Yaygın pairing tabanlı SNARK’lar kuantum saldırgan modelinde zayıftır; tüm SNARK ailesi tek varsayıma indirgenmemelidir. Hash tabanlı ve transparent yapısıyla post-kuantum açısından daha güçlü kabul edilir. Ayrık logaritma varsayımına dayandığı için kuantum saldırgan modelinde zayıftır.

Tipik kullanım Blockchain proof doğrulama, gizlilik sistemleri, küçük proof gereken yerler. Ölçeklenebilir hesaplama ispatı, rollup sistemleri. Range proof, confidential transaction, committed value ispatları.

Hiçbir ZKP yapısı her senaryo için ideal değildir. Proof boyutu ve doğrulama hızı kritikse SNARK mantıklı olabilir. Trusted setup’tan kaçınmak ve post-kuantum dayanıklılık beklentisi öne çıkıyorsa STARK daha uygun olabilir. Hafif ve trusted setup gerektirmeyen range proof gerekiyorsa Bulletproofs değerlendirilebilir. Ancak bu karar yalnızca kriptografik yapı seçimi değildir; üretim sistemi için büyük mühendislik, denetim ve operasyon yükü taşır.

Range proof kavramı özellikle dikkat çekicidir. Bir ödeme sisteminde “taahhüt edilmiş bakiye belirli eşikten büyük” bilgisini tam miktarı açıklamadan kanıtlamak veya bir yaş doğrulama sisteminde “credential içinde yer alan yaş 18’den büyük” bilgisini doğum tarihini ifşa etmeden ispatlamak mümkündür. Fakat burada kritik bir şart vardır: ispatlanan değer güvenilir bir credential’a, imzalı attribute’a veya commitment’a bağlı olmalıdır. Aksi hâlde kullanıcı circuit’e istediği değeri koyup yalnızca kendi seçtiği değerin aralıkta olduğunu ispatlamış olur.

Kullanım Alanları

ZKP’nin teorisi güçlü olsa da kullanım alanlarını değerlendirirken olgunluk, performans, standartlaşma ve operasyonel maliyet birlikte düşünülmelidir. ZKP kullanmak, sistemin otomatik olarak gizli, anonim veya güvenli olduğu anlamına gelmez. ZKP yalnızca belirli bir önermenin belirli bir model altında doğruluğunu sırrı açıklamadan kanıtlar. Sistemin geri kalanında metadata, ağ bilgisi, hesap bağlantısı, kullanıcı davranışı veya uygulama logları bilgi sızdırıyor olabilir.

Gizlilik koruyucu kimlik doğrulama, ZKP’nin en doğrudan uygulama alanlarından biridir. Kullanıcı, uygun tasarlanmış bir protokolde belirli bir secret’a veya credential’a sahip olduğunu açıklamadan kanıtlayabilir. Fakat bu, geleneksel parola doğrulamanın yerine otomatik olarak geçmez. Kayıt aşamasındaki commitment yapısı, salt, offline tahmin saldırılarına karşı koruma, rate limiting ve credential issuer güven modeli ayrıca tasarlanmalıdır.

Üyelik ispatı da önemli bir kullanım alanıdır. Kullanıcı, belirli bir gruba veya listeye dahil olduğunu, listedeki kimliğini açıklamadan kanıtlayabilir. Bu tür sistemlerde Merkle tree membership proof, accumulator veya anonymous credential yapıları kullanılabilir. Ancak hangi üyelik listesinin doğru kabul edildiği, listeyi kimin güncellediği ve iptal/revocation mekanizmasının nasıl çalıştığı ayrıca değerlendirilmelidir.

Blockchain ve gizlilik sistemleri, ZKP’nin en aktif üretim kullanımının görüldüğü alanlardandır. Zcash’in shielded işlem yapıları, işlem geçerliliğini zk-SNARK’larla ispatlayarak miktar ve adres bilgilerini gizleyebilir. Fakat Zcash ekosisteminde transparent ve shielded kullanım ayrımı vardır; tüm işlemler otomatik olarak aynı gizlilik seviyesine sahip değildir. Ağ analizi, kullanım alışkanlıkları ve metadata hâlâ gizlilik profilini etkileyebilir.

StarkNet ve StarkEx gibi sistemler, hesaplama doğruluğunu STARK tabanlı ispatlarla temsil eden ölçeklenebilirlik çözümleridir. Burada ZKP yalnızca gizlilik için değil, çok sayıda işlemin geçerliliğini tek bir doğrulanabilir proof ile temsil etmek için kullanılır. Bu proof, işlenen veri miktarına göre kompakt olabilir; ancak SNARK proof’larına kıyasla daha büyük olabileceği unutulmamalıdır.

Uyum ve gizlilik dengesi, kurumsal bağlamda ZKP’nin öne çıktığı alanlardan biridir. Bir kuruluş, belirli bir düzenleyici gerekliliği sağladığını içsel verileri doğrudan açmadan ispat etmek isteyebilir. Örneğin yeterli sermaye eşiğinin sağlandığı, bir rezervin belirli yükümlülüğü karşıladığı veya bir kullanıcının belirli bir risk sınıfında olduğu ispatlanabilir. Ancak bu tür sistemler yalnızca kriptografik proof’tan ibaret değildir; veri kaynağının güvenilirliği, denetim modeli, credential issuer ve yasal kabul süreci birlikte düşünülmelidir.

Yaş, üyelik ve yetki kanıtı günlük hayata daha yakın senaryolardır. “18 yaşından büyüğüm” bilgisini doğum tarihini açıklamadan kanıtlamak, “bu hizmete aboneyim” bilgisini abonelik detaylarını paylaşmadan aktarmak veya “bu yetkiye sahibim” bilgisini rolün tam içeriğini ifşa etmeden doğrulatmak ZKP’nin hedeflediği gizlilik koruyucu senaryolardandır. Ancak her örnekte ispatlanan değerin güvenilir bir issuer veya commitment tarafından bağlanmış olması gerekir.

ZKP otomatik olarak tamamen anonim bir sistem kurmaz. Sıfır bilgi özelliği yalnızca proof içeriğinin witness hakkında bilgi sızdırmamasını hedefler. Sistemin kimlik gizliliği sağlayıp sağlamadığı ayrıca tasarlanmalıdır. Bir blockchain’de ZKP kullanılsa bile işlem grafiği analizi, timing verileri, adres tekrar kullanımı veya ağ katmanı gözlemleri kullanıcılar arasında bağlantı kurulmasına izin verebilir.

ZKP Ekosistemi ve Geliştirici Araçlarına Genel Bakış

ZKP sistemleri geliştirmek için doğrudan matematiksel formülasyonla çalışmak pratikte zordur. Bu nedenle devre veya circuit dili olarak adlandırılan domain-specific language’ler ve araç zincirleri geliştirilmiştir. Bu araçlar, geliştiricinin ispat edilmek istenen hesaplamayı constraint sistemi olarak ifade etmesine yardım eder.

Circom, R1CS tabanlı ZKP devreleri yazmak için kullanılan yaygın bir DSL’dir. Circom ile yazılan devre, ispat edilmek istenen hesaplamanın kısıtlamalar biçiminde ifade edildiği bir yapıdır. snarkjs ile birlikte Groth16, PLONK veya FFLONK gibi proving system’lere bağlanabilir. Groth16 devreye özgü ceremony isterken, PLONK ve FFLONK universal Powers of Tau parametrelerini kullanabilir. Circom dokümantasyonu Groth16 için trusted setup’ın iki parçadan oluştuğunu, Powers of Tau aşamasının devreden bağımsız; Phase 2 aşamasının ise devreye bağlı olduğunu açıklar.

Noir, daha yüksek seviyeli ve Rust benzeri söz dizimine sahip bir ZK DSL olarak tasarlanmıştır. Noir’in önemli hedeflerinden biri backend-agnostic olmaktır; yani aynı dil ve ara temsil üzerinden farklı proving backend’lerle çalışabilmeyi amaçlar. Bu esneklik geliştirici deneyimi açısından avantajdır. Ancak üretim olgunluğu yalnızca dilin kendisiyle değil, kullanılan backend, sürüm, denetim geçmişi, bağımlılıklar ve ekosistem desteğiyle birlikte değerlendirilmelidir.

ZoKrates, ZKP devreleri yazmak, witness üretmek, setup yapmak, proof oluşturmak ve doğrulamak için kullanılan bir DSL ve araç setidir. Öğrenme ve prototipleme ortamlarında kavramsal akışı anlamak için faydalıdır. Desteklediği proving scheme’ler sürüme ve yapılandırmaya göre değişebilir; bu nedenle ZoKrates’i belirli tek bir backend’e veya eski bir uygulama detayına indirgememek gerekir.

Prover ve verifier ayrımı bu araçların temel kavramsal çerçevesini oluşturur. Prover, witness’ı bilerek proof üretir. Bu süreç hesaplama maliyeti açısından genellikle pahalıdır. Verifier ise proof, public input ve doğrulama parametreleriyle ispatı kontrol eder. Blockchain bağlamında verifier rolü zincir üstündeki akıllı sözleşme olabilir; bu nedenle verifier maliyeti doğrudan gas veya işlem ücretine dönüşebilir.

Trusted setup gerektiren sistemlerde proving key ve verification key gibi dosyalar setup sürecinden türetilir. Ancak final proving key veya verification key dosyalarının bir sunucuda durması tek başına toxic waste’in saklandığı anlamına gelmez. Toxic waste, setup sırasında kullanılan gizli trapdoor materyalidir. Final parametre dosyaları üretim sistemi için gerekli olabilir; kritik risk, trapdoor materyalinin saklanması veya törenin güven modelinin belirsiz olmasıdır.

Trusted setup gerektirmeyen sistemlerde doğrulama parametreleri aynı toxic-waste güven varsayımına dayanmaz. STARK ve Bulletproofs gibi transparent yapılarda farklı güvenlik varsayımları ve farklı uygulama riskleri vardır. Bu nedenle “verification key setup’tan gelir” gibi bir ifade, yalnızca Groth16 gibi trusted setup gerektiren SNARK bağlamında doğru kabul edilmelidir.

ZKP araçlarının büyük kısmı araştırma ve erken benimsenme ekosistemiyle yakından ilişkilidir. Bazı sistemler ciddi mühendislik ve denetim süreçlerinden geçmiştir; ancak bu, tüm ZKP ekosisteminin aynı olgunluk seviyesinde olduğu anlamına gelmez. Bir aracın GitHub’da popüler olması, üretim güvenilirliği için yeterli kanıt değildir. Bağımsız denetim, aktif bakım, sürüm stabilitesi, dokümantasyon kalitesi ve gerçek üretim referansları birlikte değerlendirilmelidir.

Komut & Araç Okuryazarlığı

ZKP araçlarının doğrudan terminalde test edilmesi bu modülün ana hedefi değildir. Ama bir ileri kriptografi uzmanı, bu araçların çıktılarını, yapılandırmalarını ve belgelerini okuyabilmelidir. Özellikle constraint sayısı, witness, proof, verification key, proving key, setup transcript’i ve kullanılan eğri gibi kavramları ayırt etmek gerekir.

Circom / snarkjs Devre Çıktısını Kavramsal Okuma

Bir Circom derlemesi sonucunda R1CS dosyası, constraint sayısı, wire sayısı ve devreye ilişkin çeşitli raporlar üretilebilir. snarkjs üzerinden proof üretildiğinde proof.json, public.json, verification_key.json ve proving system’e bağlı başka dosyalar görülebilir.

Constraint sayısı prover maliyetiyle yakından ilişkilidir. Devre karmaşıklaştıkça constraint sayısı artar; bu da daha fazla bellek ve daha uzun proof üretim süresi anlamına gelebilir. Ancak constraint sayısı tek başına güvenlik göstergesi değildir. Az constraint içeren bir devre yanlış problemi modelliyorsa hızlı ama güvensiz olabilir.

proof.json içinde Groth16 bağlamında pi_a, pi_b, pi_c gibi eliptik eğri noktaları yer alabilir. verification_key.json ise proof doğrulaması için gereken public parametreleri içerir. Kullanılan eğri BN254 veya BLS12-381 gibi farklı güvenlik ve performans profillerine sahip olabilir. Eğri seçimi, ekosistem desteği ve güvenlik seviyesi birlikte okunmalıdır.

Groth16 gibi trusted setup gerektiren SNARK’larda verification key setup sürecinden türetilir ve belirli bir devreyle ilişkilidir. PLONK/FFLONK gibi universal setup kullanan sistemlerde süreç farklıdır. snarkjs’in Groth16 için circuit-specific ceremony, PLONK ve FFLONK için universal Powers of Tau yaklaşımını ayırması bu farkı gösterir.

Bir proof’un kriptografik olarak doğrulanması, devrenin doğru yazıldığı anlamına gelmez. Devre hatalı constraint içeriyorsa proof doğru biçimde doğrulanabilir; fakat yanlış bir önermeyi kanıtlıyor olabilir. Bu yüzden ZKP sistemlerinde en kritik güvenlik noktalarından biri devre denetimidir.

ZoKrates ile Kavramsal Prototipleme

ZoKrates gibi araçlarda tipik akış şu şekilde özetlenebilir: devre yazılır, compile edilir, setup yapılır, witness hesaplanır, proof üretilir ve verifier ile doğrulanır. Bu akış öğrenme açısından yararlıdır; çünkü prover ve verifier rollerini somutlaştırır.

Witness, prover’ın bildiği gizli ve ara değerleri içerebilir. Bu nedenle witness verifier ile paylaşılmamalıdır. Proof ise witness’ın kendisini açmadan, public input’larla birlikte constraint sisteminin sağlandığını kanıtlamak için kullanılır.

VERIFIED çıktısı dikkatli yorumlanmalıdır. Bu çıktı, proof’un mevcut verification key ve public input’lar altında tanımlı constraint sistemiyle tutarlı olduğunu gösterir. Devrenin doğru problemi modellediğini, güvenli yazıldığını veya iş mantığının doğru olduğunu kanıtlamaz. Bu ayrım ZKP araç okuryazarlığının temelidir.

Proof, ait olmadığı verification key ile doğrulanmamalıdır. Normal koşullarda farklı devreye ait proof ve verification key uyuşmazlığı doğrulamayı başarısız kılar. Ancak uygulama yanlış verification key’i beklenen iş mantığının yerine bağlarsa, başka bir relation/devre için geçerli olan proof yanlış semantikle kabul edilebilir. Bu uygulama entegrasyonu hatasıdır ve ciddi güvenlik riski doğurabilir.

İleri Seviye Güvenli Analiz / Kontrol Listesi

Bir ZKP sistemi değerlendirilirken önce sistemin ZKP’yi hangi amaçla kullandığı netleştirilmelidir. Amaç gizlilik sağlamak mı, hesaplama doğruluğunu ispat etmek mi, ölçeklenebilirlik mi, uyumluluk kanıtı mı, kimlik doğrulama mı? Bu ayrım, hangi güvenlik özelliklerinin kritik olduğunu belirler.

Güvenlik modeli açıkça okunmalıdır. Sistem completeness, soundness ve zero-knowledge özelliklerini hangi modelde sağlıyor? Computational mı, statistical mı, perfect mi? Hangi kriptografik varsayımlara dayanıyor? Pairing tabanlı mı, ayrık logaritma tabanlı mı, hash tabanlı mı? Post-kuantum saldırgan modeli bu varsayımları nasıl etkiliyor?

Trusted setup gerekip gerekmediği ayrıca değerlendirilmelidir. Gerekiyorsa setup töreni nasıl yürütülmüş? Tek taraflı mı, MPC ceremony mi? Katılımcı sayısı kaç? Transcript yayımlanmış mı? Katkılar doğrulanabilir mi? Toxic waste’in imhasına ilişkin prosedür var mı? Az katılımcılı veya belgelenmemiş setup doğrudan sahte proof üretildiğini göstermez; ancak güven varsayımını zayıflatır ve risk olarak değerlendirilmelidir.

Devre güvenliği ZKP sisteminin en kritik katmanlarından biridir. Devre bağımsız güvenlik denetiminden geçmiş mi? Range sınırları doğru mu? Public ve private input ayrımı doğru yapılmış mı? Constraint’ler beklenen iş mantığını gerçekten zorluyor mu? Devrede eksik constraint varsa proof doğrulanabilir ama sistem yanlış sonucu kabul edebilir.

Proof ve verification key yönetimi kontrol edilmelidir. Verification key doğru kaynaktan mı geliyor? Hash veya imzayla bütünlüğü doğrulanıyor mu? Devre sürümü ile verification key sürümü eşleşiyor mu? Proving key ve verification key dosyaları ile toxic waste aynı şey değildir; bu ayrım operasyon ekibi tarafından anlaşılmış mı?

Araç olgunluğu sorgulanmalıdır. Kullanılan framework bağımsız denetimden geçmiş mi? Aktif bakımı var mı? Üretim kullanımında referansları var mı? Backend değiştiğinde güvenlik varsayımı da değişiyor mu? ZKP araçlarında sürüm ve backend seçimi, klasik yazılım kütüphanelerine göre daha büyük kriptografik etki yaratabilir.

Yanlış yorumlama risklerinden biri “proof doğrulandı, sistem güvenli” varsayımıdır. Proof doğrulanması yalnızca proof’un belirli relation için geçerli olduğunu gösterir. Sistemin doğru relation’ı seçip seçmediği, relation’ın doğru problemi modelleyip modellemediği, witness’ın doğru kaynaktan gelip gelmediği ve uygulama mantığının sonucu doğru yorumlayıp yorumlamadığı ayrıca incelenmelidir.

Bir diğer risk, sıfır bilgi özelliğini genel anonimlik garantisi sanmaktır. Proof witness hakkında bilgi sızdırmayabilir; fakat ağ katmanı, zamanlama, kullanıcı hesabı, IP adresi, işlem grafiği veya uygulama logları kimlik bağlantısı kurabilir. ZKP gizlilik mimarisinin yalnızca bir bileşenidir.

Geliştirici ve güvenlik ekibine öneri dili şu ayrımı net biçimde kurmalıdır:

“Bu bileşende proof doğrulaması çalışıyor; ancak bu sonuç devrenin doğru problemi modellediğini kanıtlamaz. Güvenlik değerlendirmesi için devre constraint’lerinin bağımsız denetimi, setup töreninin güven modeli, verification key bütünlüğü ve proof sonucunun iş mantığına doğru bağlandığı uçtan uca testler gereklidir.”

Analitik Senaryo

Durum

Yeni kurulan bir fintech şirketi, kullanıcıların kredi skoru aralığını açıklamadan “kredi skoru yeterliliğini” ispat etmesini sağlayan ZKP tabanlı bir doğrulama bileşeni geliştirmiştir. Bileşen, open source bir Circom/snarkjs pipeline üzerine kuruludur. Sistem önümüzdeki ay üretim ortamına alınacaktır. Güvenlik ekibine bu bileşeni değerlendirme görevi verilmiştir.

İlk Değerlendirme

Mimari fikir genel olarak anlamlıdır. Kullanıcı gerçek kredi skorunu açıklamadan, skorun belirli bir eşik üzerinde olduğunu ispatlamak isteyebilir. Bu bir range proof veya karşılaştırma devresiyle modellenebilir. Ancak ZKP kullanmak, sistemin tüm güvenlik yükümlülüklerini otomatik olarak sağladığı anlamına gelmez.

İlk kritik soru şudur: İspatlanan skor nereden geliyor? Kullanıcı circuit’e kendi seçtiği bir skor değerini koyuyorsa sistem yalnızca “kullanıcının seçtiği değer eşik üstünde” önermesini kanıtlar. Gerçek kredi skorunun ispatlanması için skorun güvenilir bir kurum tarafından imzalanmış credential’a, commitment’a veya doğrulanabilir veri kaynağına bağlanması gerekir.

Kontrol Edilecek Noktalar

Önce kullanılan proving system belirlenmelidir. Circom/snarkjs ile Groth16 kullanılıyorsa devreye özgü setup gerekir. PLONK veya FFLONK kullanılıyorsa universal Powers of Tau parametreleriyle farklı bir setup modeli olabilir. Bu ayrım yapılmadan setup riski doğru değerlendirilemez.

Trusted setup’ın nasıl yürütüldüğü sorgulanmalıdır. Setup tek taraflı ve kapalı biçimde geliştirici ekip tarafından mı yapıldı? Yoksa çok katılımcılı bir MPC ceremony mi kullanıldı? Transcript yayımlandı mı? Katkılar doğrulanabilir mi? En az bir dürüst katılımcı varsayımı makul mü? Bu sorular setup güven modelini belirler.

Sunucuda duran dosyanın ne olduğu ayrıştırılmalıdır. Final proving key, verification key veya .zkey dosyalarının saklanması üretim için normal olabilir. Fakat setup sırasında kullanılan gizli trapdoor materyalinin saklanması toxic waste riskidir. “Parametre dosyası sunucuda duruyor” ifadesi tek başına toxic waste’in saklandığını kanıtlamaz.

Devre denetlenmelidir. Range sınırı doğru mu? Örneğin “skor ≥ 700” isteniyorsa circuit gerçekten bu koşulu mu zorluyor? Negatif değer, overflow, field modulus wraparound veya yanlış bit decomposition gibi sorunlar var mı? Public input ve private witness ayrımı doğru mu? Kullanıcının skor credential’ı gerçekten circuit’e bağlanıyor mu?

Verification key’in doğru devreden türetildiği doğrulanmalıdır. Devre güncellendiyse verification key de güncellenmiş mi? Uygulama hangi verification key’i kullanıyor? Verification key bütünlüğü hash veya imza ile sabitlenmiş mi? Yanlış verification key, sistemin yanlış relation’ı kabul etmesine neden olabilir.

Proof doğrulama sonucunun iş mantığına doğru aktarıldığı uçtan uca test edilmelidir. Verifier “true” döndürse bile uygulama bu sonucu yanlış kullanıcıya, yanlış oturuma veya yanlış credential bağlamına bağlıyorsa protokol güvenliği bozulabilir.

İncelenecek Çıktı

verification_key.json dosyasının oluşturulma tarihi, hash değeri ve hangi devre sürümüne ait olduğu kontrol edilmelidir. proof.json içindeki alanların beklenen proving system ve eğriyle uyumlu olup olmadığı incelenmelidir. Devrenin constraint sayısı, beklenen kredi skoru aralığı kontrolüyle makul biçimde ilişkili mi değerlendirilmelidir.

Setup törenine ilişkin belge aranmalıdır. Kaç katılımcı var? Katılımcılar bağımsız mı? Transcript doğrulanabilir mi? Eğer yalnızca geliştirici ekibin yerel makinesinde setup yapılmışsa, bu durum üretim için zayıf bir güven modelidir.

Güvenli Doğrulama Yaklaşımı

Devrenin range proof mantığını doğru uyguladığı, ZKP konusunda deneyimli bağımsız bir ekip tarafından gözden geçirilmelidir. Özellikle field arithmetic kaynaklı hatalar, eksik constraint’ler ve public/private input karışıklıkları incelenmelidir.

Verification key’in doğru devreden türetildiği hash ile doğrulanmalı ve deployment sürecinde sabitlenmelidir. Proof doğrulama servisi yalnızca proof’un doğrulanmasına değil, proof’un doğru kullanıcı, doğru credential, doğru issuer ve doğru oturum bağlamıyla ilişkili olduğuna da bakmalıdır.

Trusted setup riski kabul edilebilir değilse, çok katılımcılı güvenilir bir törenle yeniden setup yapılmalı veya trusted setup gerektirmeyen bir yapıya geçiş değerlendirilmelidir. Ancak STARK veya Bulletproofs gibi alternatiflere geçiş de performans, proof boyutu ve entegrasyon maliyeti açısından ayrıca analiz edilmelidir.

Yanlış Yorumlama İhtimali

Geliştirici ekibi “proof doğrulanıyor, sistem güvenli” değerlendirmesi yapabilir. Bu yorum eksiktir. Proof doğrulaması, mevcut constraint sistemiyle witness’ın tutarlı olduğunu gösterir. Devrenin kredi skoru problemini doğru modellediğini, skorun güvenilir bir kaynaktan geldiğini veya iş mantığının sonucu doğru kullandığını kanıtlamaz.

Bir başka yanlış yorum, final proving key veya verification key dosyalarını toxic waste ile karıştırmaktır. Bu dosyalar üretim sistemi için gerekli olabilir. Kritik olan, setup sırasında kullanılan gizli trapdoor materyalinin saklanıp saklanmadığı ve setup töreninin güven modelidir.

Riskin Pratik Karşılığı

Trusted setup zayıfsa ve toxic waste bir tarafça biliniyorsa, attacker eşiği karşılamadan geçerli proof üretebilir. Bu, kredi kararlarının manipüle edilmesi anlamına gelir.

Devre kısıtlama hataları varsa, proof doğrulansa bile yanlış aralıktaki skorlar geçerli kabul edilebilir. Örneğin field overflow nedeniyle düşük bir değer yüksek gibi yorumlanabilir veya credential bağlantısı eksikse kullanıcı sahte bir skoru proof’a sokabilir.

Verification key yanlış relation’a bağlıysa, sistem doğru görünen ama iş mantığı açısından alakasız proof’ları kabul edebilir. Bu risk özellikle devre sürümleri hızlı değişen erken aşama ZKP projelerinde önemlidir.

Önerilen Güvenli Yaklaşım

Üretim öncesinde üç adım tamamlanmadan sistem çevrimiçi alınmamalıdır.

Birinci adım, devrenin ZKP konusunda uzman bağımsız bir ekip tarafından denetlenmesidir. Denetim yalnızca kod kalitesine değil, constraint sisteminin semantik doğruluğuna odaklanmalıdır.

İkinci adım, trusted setup güven modelinin netleştirilmesidir. Groth16 kullanılıyorsa devreye özgü setup töreninin güvenilir biçimde yürütüldüğü belgelenmelidir. Mümkünse çok katılımcılı MPC ceremony kullanılmalı veya universal/transparent alternatifler değerlendirilmelidir.

Üçüncü adım, proof doğrulama sonucunun iş mantığına doğru bağlandığının uçtan uca test edilmesidir. Proof, kullanıcı oturumu, credential issuer, skor commitment’ı ve doğrulama zamanı aynı bağlamda doğrulanmalıdır.

Bu değerlendirme teknik yönetime şu dille aktarılabilir:

“Kriptografik proof üretimi ve doğrulaması çalışıyor görünmektedir; ancak bu tek başına sistemin güvenli olduğunu kanıtlamaz. Üretim öncesinde devre doğruluğu, trusted setup güven modeli, verification key bütünlüğü ve proof sonucunun iş mantığına doğru bağlandığı bağımsız olarak doğrulanmalıdır.”

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

Zero-knowledge proof Sıfır bilgi ispatı; bir önermenin doğruluğunu, witness’ı açıklamadan kanıtlayan kriptografik yapı.

Completeness Tamlık; doğru önerme ve dürüst prover durumunda verifier’ın ispatı kabul etmesi.

Soundness Sağlamlık; yanlış önermeyi veya witness bilmeyen prover’ı kabul etme olasılığının çok düşük olması.

Zero-knowledge özelliği Verifier’ın proof sürecinden witness hakkında tanımın izin verdiği modelin ötesinde bilgi öğrenmemesi.

Perfect zero-knowledge Gerçek transcript ile simülatör transcript’inin dağılım olarak aynı olması.

Statistical zero-knowledge Gerçek ve simüle transcript dağılımlarının istatistiksel olarak çok yakın olması.

Computational zero-knowledge Gerçek ve simüle transcript’lerin verimli ayırt ediciler tarafından ayırt edilememesi.

Prover İspat eden; witness’ı bilen ve proof üreten taraf.

Verifier Doğrulayıcı; proof’u ve public input’ları kontrol eden taraf.

Witness Prover’ın bildiği gizli değerler; verifier ile paylaşılmaz.

Statement İspatlanmak istenen açık önerme veya relation tanımı.

Public input Proof doğrulamasında açıkça kullanılan giriş değerleri.

Interactive proof Prover ve verifier arasında çok turlu mesaj alışverişi içeren ispat sistemi.

Non-interactive proof Verifier’ın aktif challenge üretmesine gerek kalmadan tek proof mesajıyla doğrulanabilen ispat.

Sigma protokolü Commit → challenge → response üç adımlı etkileşimli ispat çerçevesi.

Commitment Prover’ın ilk adımda gönderdiği bağlayıcı değer.

Challenge Verifier’ın ürettiği veya Fiat–Shamir ile transcript’ten türetilen meydan okuma değeri.

Response Prover’ın challenge’a verdiği yanıt.

Schnorr protokolü Ayrık logaritma bilgisini sırrı açıklamadan ispatlayan klasik Sigma protokolü.

Chaum–Pedersen protokolü İki ayrık logaritma ilişkisinin eşitliğini ispatlamak için kullanılan Sigma protokolü.

AND proof Birden fazla önermenin tamamının doğru olduğunu gösteren konjunktif ispat.

OR proof Birden fazla önermeden en az birinin doğru olduğunu, hangisi olduğunu açıklamadan gösteren disjunktif ispat.

Fiat–Shamir dönüşümü Etkileşimli public-coin ispatlarda verifier challenge’ını transcript hash’iyle değiştirerek etkileşimsiz proof üreten teknik.

Domain separation Farklı protokol ve bağlamların hash/transcript içinde karışmaması için kullanılan ayrıştırma yaklaşımı.

zk-SNARK Kısa ve hızlı doğrulanabilir etkileşimsiz bilgi argümanı; birçok yaygın yapıda trusted setup gerekir.

zk-STARK Trusted setup gerektirmeyen, hash tabanlı ve ölçeklenebilir ispat sistemi ailesi.

Bulletproofs Trusted setup gerektirmeyen kısa/logaritmik proof’lar sunan, özellikle range proof için bilinen yapı.

Trusted setup Bazı proof sistemlerinde ortak parametrelerin güvenli biçimde üretildiği başlangıç süreci.

Toxic waste Trusted setup sırasında oluşan ve imha edilmesi gereken gizli trapdoor materyali.

MPC ceremony Çok katılımcılı setup töreni; güvenlik genellikle en az bir dürüst katkı varsayımına dayanır.

Universal setup Belirli boyut sınırı içinde farklı devreler için yeniden kullanılabilen ortak setup parametreleri.

Circuit / Devre İspat edilmek istenen hesaplamanın kısıtlamalar biçiminde ifade edilmiş hâli.

R1CS Rank-1 Constraint System; ZKP devrelerinin matematiksel kısıtlama biçimlerinden biri.

Constraint Devrede sağlanması gereken matematiksel kısıtlama.

Proving key Prover’ın proof üretmek için kullandığı, proving system’e özgü parametre dosyası.

Verification key Verifier’ın proof doğrulamak için kullandığı parametre dosyası; trusted setup gereken sistemlerde setup’tan türetilebilir.

Proof size Proof’un bayt cinsinden büyüklüğü.

Prover cost Proof üretmek için gereken hesaplama ve bellek maliyeti.

Verifier cost Proof’u doğrulamak için gereken hesaplama maliyeti.

Range proof Bir committed değerin belirli aralıkta olduğunu, değeri açıklamadan kanıtlayan ispat.

Credential Güvenilir bir issuer tarafından verilen ve belirli attribute’ları bağlayan kimlik/veri nesnesi.

Commitment Bir değeri gizleyip sonradan aynı değere bağlı kalmayı sağlayan kriptografik yapı.

Circom R1CS tabanlı ZKP devreleri yazmak için kullanılan DSL.

snarkjs Circom çıktılarıyla proof üretme, setup ve doğrulama süreçlerinde kullanılan JavaScript tabanlı araç zinciri.

Noir Backend-agnostic olmayı hedefleyen, Rust benzeri söz dizimine sahip ZK DSL.

ZoKrates ZKP devresi yazma, witness üretme, setup, proof üretme ve doğrulama için kullanılan DSL ve araç seti.

VERIFIED çıktısı Proof’un mevcut verification key, public input ve constraint sistemiyle tutarlı olduğunu gösterir; devrenin doğru problemi modellediğini kanıtlamaz.

Transparent proof system Trusted setup gerektirmeyen proof sistemi ailesi için kullanılan genel ifade.

Pairing tabanlı SNARK Bilinear pairing varsayımlarına dayanan SNARK ailesi; kuantum saldırgan modelinde zayıf kabul edilir.

Hash tabanlı proof system Güvenliğini büyük ölçüde hash fonksiyonları ve ilgili test protokollerinden alan proof sistemi ailesi.

Simülatör argümanı Zero-knowledge özelliğini göstermek için verifier’ın gördüklerinin witness bilinmeden de üretilebileceğini gösteren ispat yaklaşımı.

Kendini Değerlendir — İleri Kriptografi Modül 6

Bu Modülde Neler Öğrendik?

Bu modül, ZKP’nin salt teorik bir kriptografi kavramı olmadığını; aktif üretim sistemlerinde kullanılan, ancak dikkatli konumlandırma gerektiren bir mühendislik alanı olduğunu gösterdi.

Completeness, soundness ve zero-knowledge özelliklerini güvenlik modeli çerçevesinde okumak, bir ZKP sistemi hakkında konuşurken neyin garanti altında olduğunu ve neyin olmadığını doğru ifade etmemizi sağlar. Bu özelliklerin perfect, statistical veya computational modellerde sağlanabileceğini görmek, “ZKP güvenlidir” gibi genel cümlelerin neden yetersiz olduğunu ortaya koyar.

Sigma protokollerini ve Fiat–Shamir dönüşümünü incelediğimizde, etkileşimsiz ispat yapılarının arkasındaki mekanizmayı ve bu geçişte yapılan hataların güvenliği nasıl zayıflatabileceğini gördük. Challenge değerinin yalnızca commitment’tan değil, transcript, statement, public input ve domain separation bilgisinden türetilmesi gerektiğini öğrendik.

AND ve OR ispatlarını doğru biçimde ayırdık. AND ispatları konjunktif önermeleri, OR ispatları ise disjunktif önermeleri temsil eder. OR ispatlarının prover’ın hangi sırrı bildiğini açıklamadan “en az birini biliyorum” önermesini ispatlaması, anonimlik ve gizlilik koruyucu sistemler için önemli bir yapı taşıdır.

zk-SNARKs, zk-STARKs ve Bulletproofs karşılaştırması, proof boyutu, trusted setup gerekliliği, prover/verifier maliyeti ve post-kuantum beklentileri eksenlerinde anlamlı teknik kararlar vermeyi mümkün kılar. Hangi yapının hangi senaryoya uygun olduğunu veya neden uygun olmadığını mimari ekibe aktarabilecek düzeye ulaştık.

Trusted setup meselesinin üretim güvenliği açısından taşıdığı riski doğru biçimde tanımladık. Tek taraflı veya kötü yürütülen setup’ta toxic waste’i bilen taraf sahte proof üretebilir. Çok katılımcılı MPC ceremony’de ise güvenlik, en az bir katılımcının katkısını gizli tutup imha ettiği varsayımına dayanır. Bu ayrım yapılmadan setup riski doğru değerlendirilemez.

Range proof, anonim üyelik ispatı ve gizlilik koruyucu kimlik doğrulama gibi senaryoların hangi şartlarda anlamlı olduğunu gördük. Bir değerin belirli aralıkta olduğunu ispatlamak için o değerin güvenilir bir credential’a veya commitment’a bağlı olması gerekir. Aksi hâlde sistem yalnızca kullanıcının kendi seçtiği değeri ispatlamış olur.

ZKP araç ekosistemi tarafında Circom, snarkjs, Noir ve ZoKrates’in temel rollerini, prover/verifier ayrımını, devre mantığını ve setup döngüsünü kavramsal olarak anladık. Bu araçların üretim olgunluğu, denetim geçmişi, backend seçimi ve bakım durumu açısından sorgulanması gereken boyutlarını somut sorularla değerlendirebiliyoruz.

Son olarak, analitik senaryo üzerinden “proof doğrulandı” ile “sistem güvenli” arasındaki farkı ayırt ettik. Proof doğrulaması yalnızca mevcut constraint sistemiyle tutarlılık gösterir. Devrenin doğru problemi modellediği, setup’ın güvenilir olduğu, verification key’in doğru bağlandığı ve iş mantığının sonucu doğru yorumladığı ayrıca doğrulanmalıdır. Bu bakış, ZKP tabanlı bileşenleri değerlendiren güvenlik ve mimari uzmanları için doğrudan uygulanabilir bir çerçevedir.

MODÜL 7 — Kriptografik uygulama güvenliği, yan kanallar ve anahtar yönetimi

Modül özeti

Doğru primitif seçiminin uygulama, operasyon ve donanım katmanlarında nasıl bozulabileceğini ve anahtar yaşam döngüsünün kurumsal güvenliğin omurgası olduğunu bağlar.

Modül 7 — Kriptografik Uygulama Güvenliği, Yan Kanallar ve Anahtar Yönetimi

Kriptografinin tarihsel açıdan en çarpıcı başarısızlıkları çoğu zaman algoritmanın kendisinden değil, uygulama kararlarından kaynaklanmıştır. AES-GCM doğru seçilmiş olabilir; ancak aynı anahtar altında nonce tekrar edilirse gizlilik ve bütünlük aynı anda zarar görebilir. RSA-OAEP doğru şema olabilir; fakat yanlış padding parametresi, hatalı hata mesajı veya yanlış API kullanımı güvenlik modelini zayıflatabilir. SHA-256 güçlü bir hash fonksiyonu olabilir; fakat parola saklamak için tek başına kullanıldığında saldırganın çevrimdışı deneme hızını yeterince sınırlamaz. Bu modül, tam olarak bu kopuşu odağına alır: doğru algoritma yanlış uygulanırsa neden güvensizlik üretir ve bu güvensizlik nasıl tanınır?

Öğrenci bu modülde kriptografik uygulama hatalarını sınıflandırmayı, yan kanal saldırılarının algoritma güvenliğinden bağımsız bir tehdit katmanı oluşturduğunu anlamayı, anahtar yaşam döngüsünü kurumsal ölçekte yorumlamayı, kriptografik çevikliği bir mimari gereksinim olarak okumayı ve FIPS 140-3 gibi standart uyumu ile gerçek güvenlik arasındaki farkı değerlendirmeyi öğrenir.

Modülün son bölümünde HSM, Cloud KMS ve HashiCorp Vault gibi araçların kurumsal kripto mimarisindeki rolü ele alınır. Bu araçlar yalnızca “anahtar saklama yeri” değildir; erişim yetkilendirme, denetim izi, rotasyon, key wrapping, versiyonlama ve operasyonel güvenlik kararlarının bir parçasıdır.

Bu modül, daha önceki modüllerde öğrenilen formal güvenlik modellerinin, AEAD yapılarının, açık anahtar kriptografisinin, KDF mimarisinin ve TLS protokolünün gerçek dünya uygulamalarında neden ve nasıl bozulabileceğini birleştirir. İleri kriptografi bilgisinin pratik güvenlik kararlarına dönüşmesinin merkez noktasıdır.

Kazanımlar

Öğrenci bu modül sonunda:

Kriptografik uygulama hatalarını sınıflandırabilir; yanlış parametre, yanlış API, zayıf RNG, nonce/IV tekrar kullanımı ve hata mesajı sızıntısı gibi hata türlerini birbirinden ayırt edebilir.

AES-GCM, CBC, CTR, ChaCha20-Poly1305 gibi yapılarda IV/nonce gereksinimlerinin aynı olmadığını açıklayabilir; CBC için tahmin edilemez IV, GCM/CTR/ChaCha20-Poly1305 için aynı anahtar altında nonce benzersizliği ayrımını doğru kurabilir.

Timing, cache, power analysis ve fault injection gibi yan kanal saldırılarının algoritma güvenliğinden bağımsız bir tehdit katmanı oluşturduğunu açıklayabilir ve constant-time programlama ihtiyacını bu bağlamda yorumlayabilir.

Anahtar yaşam döngüsünü üretim, dağıtım, saklama, kullanım, rotasyon/yenileme, arşivleme ve imha aşamalarıyla kurumsal ölçekte değerlendirebilir.

KEK/DEK ayrımını, key wrapping mantığını ve KEK rotasyonu ile DEK rotasyonu arasındaki farkı doğru yorumlayabilir.

Kriptografik çevikliği bir mimari tasarım ilkesi olarak tanımlayabilir; algoritma değişiminin kod, protokol, sertifika, depolama ve operasyon katmanlarına etkisini analiz edebilir.

FIPS 140-3 ve CMVP mantığını açıklayabilir; standart uyumunun modül seviyesinde bir validasyon olduğunu, uygulama entegrasyonunun güvenliğini otomatik olarak garanti etmediğini ifade edebilir.

HashiCorp Vault, Cloud KMS ve HSM gibi araçların anahtar yönetimi mimarisindeki rollerini karşılaştırabilir; audit log, key rotation ve erişim yetkilendirme çıktılarını yorumlayabilir.

Kriptografik uygulama güvenliği bulgularını geliştirici, güvenlik mühendisi ve mimari ekibe aktarabilecek teknik dilde ifade edebilir.

Güvenli varsayılanların, secret handling pratiklerinin ve bellek temizlemenin neden yalnızca “iyi alışkanlık” değil, kriptografik güvenlik gereksinimi olduğunu açıklayabilir.

Kriptografik Uygulama Hataları

Kriptografi dünyasında “güvenli algoritma” ile “güvenli uygulama” arasındaki mesafe düşünüldüğünden daha büyüktür. IND-CCA güvenli bir şema seçmek, o şemanın doğru parametrelerle, doğru API ile ve doğru hata davranışıyla kullanıldığını garanti etmez. Pek çok gerçek dünya güvenlik kırılması tam bu boşlukta gerçekleşir.

Doğru algoritmanın yanlış kullanımı bu hata sınıfının en yaygın biçimidir. AES-GCM güvenli bir AEAD yapısıdır; ancak aynı anahtar altında aynı nonce ile iki farklı mesaj şifrelenirse CTR tabanlı şifreleme aynı keystream’i tekrar kullanır. Bu durumda ciphertext’lerin XOR’u plaintext’lerin XOR’unu verir; plaintext’lerden biri biliniyor veya tahmin edilebiliyorsa diğeri kısmen ya da tamamen açığa çıkabilir. Ayrıca AES-GCM’nin authentication bileşeni olan GHASH yapısı da zayıflayabilir ve sahte tag üretme riski ortaya çıkabilir. AES-GCM, Poly1305 kullanmaz; Poly1305, ChaCha20-Poly1305 yapısının MAC bileşenidir. GCM, NIST SP 800-38D’de Galois/Counter Mode olarak tanımlanır ve RFC 5116 da AES-GCM’de aynı key+nonce tekrarının gizlilik ve bütünlük açısından yıkıcı olduğunu açıklar.

Yanlış parametre seçimi de benzer şekilde çalışır. RSA-OAEP’i doğru seçmek, padding parametrelerini, hash fonksiyonunu ve label kullanımını bilinçli yapılandırmayı gerektirir. PBKDF2 kullanmak, iterasyon sayısını güncel tehdit modeline ve sistem performansına göre kalibre etmek anlamına gelir. 10.000 iterasyonlu PBKDF2 yapılandırmaları güncel sistemler için genellikle zayıf kabul edilir; ancak bu noktayı “NIST 600.000 iterasyon öneriyor” şeklinde yazmak doğru değildir. NIST SP 800-63B, password hashing cost factor değerinin pratikte mümkün olan en yüksek seviyede seçilmesini ve zamanla artırılmasını ister; OWASP ise FIPS uyumluluğu gereken PBKDF2-HMAC-SHA256 kullanımları için 600.000 veya üzeri iterasyon önerir.

Argon2id seçmek de yalnızca algoritma adını değiştirmek değildir. Memory-cost, time-cost ve parallelism parametreleri hedef ortamın donanımına, beklenen kullanıcı yoğunluğuna ve saldırgan modeline göre ayarlanmalıdır. Kütüphane varsayımlarının her zaman yeterli olduğunu düşünmek tehlikelidir; bazı kütüphaneler geriye dönük uyumluluk nedeniyle güvenlik açısından zayıf veya eski varsayılanları koruyabilir.

Zayıf RNG kullanımı kriptografik sistemlerin temel kırılganlıklarından biridir. ECDSA’da nonce’un düzgün üretilmemesi, özel anahtarın açığa çıkmasına yol açabilir. PlayStation 3 imza sisteminde görülen ECDSA nonce hatası bu riskin gerçek dünyadaki en bilinen örneklerindendir. Math.random() gibi kriptografik kalite taşımayan fonksiyonların nonce, IV, salt veya anahtar üretimi için kullanılması ciddi bir uygulama hatasıdır. Kriptografik rastgelelik, işletim sistemi düzeyi CSPRNG’den veya güvenilir kriptografik kütüphanenin sunduğu güvenli rastgelelik API’sinden alınmalıdır.

Hatalı hata mesajları özellikle simetrik kriptografide kritik bir sızıntı vektörüdür. CBC modunda padding doğrulaması yapan bir sistemde “padding hatalı” ve “MAC hatalı” mesajlarının ayrı döndürülmesi padding oracle saldırısının temelini oluşturabilir. Kriptografik işlemlerde hata mesajları genel, tek tip ve zamanlama açısından ayrıştırılması zor olacak şekilde tasarlanmalıdır. Başarı/başarısızlık dışında ayrıntılı bilgi sızdırmayan bir tasarım esas alınmalıdır.

Kriptografik API yanlışları, güvenli bir kütüphanenin bile güvensiz sonuç üretmesine yol açabilir. Python cryptography kütüphanesindeki yüksek seviye API’lar daha güvenli varsayımlar sunarken, hazmat arayüzü düşük seviye kriptografik ilkelere erişim sağlar ve yanlış kullanım riski yüksektir. Bu tür API’lar yalnızca protokol tasarımı, nonce/tag yönetimi, hata davranışı ve güvenlik modeli tam olarak anlaşıldığında kullanılmalıdır. Genel uygulama şifrelemesi için Fernet, AESGCM veya ChaCha20Poly1305 gibi daha yapılandırılmış ve yüksek seviye arayüzler tercih edilmelidir.

Bir kütüphanenin güvenli olması, o kütüphanenin her API’sinin güvenli biçimde kullanılacağı anlamına gelmez. Güvenlik, API seçiminde, parametre konfigürasyonunda ve çağrı sırasında korunur. Üretim sisteminde kütüphane entegrasyonundan önce dokümantasyonun uyarı, not ve kullanım sınırı bölümleri okunmalıdır.

Şifreleme ve bütünlük doğrulamasının birbirinden ayrı düşünülmesi de yaygın bir uygulama hatasıdır. CBC modunda şifreleme yapıp ayrıca HMAC eklemek doğru tasarlanırsa güvenli olabilir; fakat alıcı tarafta MAC doğrulanmadan önce ciphertext şifre çözülüyor ve plaintext/padding işleniyorsa oracle riski doğar. Encrypt-then-MAC tasarımında gönderici önce şifreler, sonra ciphertext üzerinden MAC üretir; alıcı ise önce MAC’i doğrular, sonra şifre çözme yapar. Modern uygulama tasarımında bu karmaşıklığı azaltmak için doğrudan AEAD yapılarının tercih edilmesi çoğu zaman daha doğru yoldur.

Yan Kanal Saldırıları

Yan kanal saldırıları, algoritmanın matematiksel mantığını değil, fiziksel veya zamansal gözlemini hedefler. Bu saldırı sınıfının kritik önemi, formal olarak güvenli bir şemanın bile uygulama seviyesinde sızıntı üretebilmesidir. Algoritma güvenliği ile uygulama güvenliği arasındaki fark burada en keskin biçimde görünür.

Timing saldırılarında kriptografik işlemin tamamlanma süresi gizli bilgiyle korelasyon taşıyorsa, yeterli ölçüm alan bir saldırgan bu bilgiyi kademeli olarak çıkarabilir. RSA private key işlemleri, geçmişte timing saldırılarının klasik hedeflerinden biri olmuştur. Gizli üsle yapılan modüler üs alma sırasında bazı bit değerlerinde farklı işlem yolları veya farklı süreler oluşursa, saldırgan bu farkları istatistiksel olarak kullanabilir.

Daha erişilebilir bir örnek token veya MAC karşılaştırmasıdır. Çoğu programlama dilinin standart string eşitlik karşılaştırması ilk farklı karakterde durabilir. Bu davranış MAC veya token doğrulamasında kullanılırsa, uygun koşullarda saldırgana kaç byte’ın doğru eşleştiğine dair zamanlama sinyali verebilir. Ağ gürültüsü, rate limiting, jitter ve uygulama mimarisi saldırıyı zorlaştırabilir; buna rağmen kriptografik karşılaştırmalar hmac.compare_digest(), Go crypto/subtle.ConstantTimeCompare veya eşdeğer constant-time fonksiyonlarla yapılmalıdır. Go crypto/subtle paketi, içerikten bağımsız sürede çalışan karşılaştırma gibi dikkatli kriptografik yardımcılar sağlar; bellek temizleme için tasarlanmış bir paket değildir.

Cache saldırıları, modern işlemcilerde bellek erişim zamanının gizli veriyle korelasyon taşımasından yararlanır. Tablo tabanlı AES implementasyonlarında S-box erişimleri anahtar ve ara durum değerlerine bağlı adres örüntüleri oluşturabilir. Aynı fiziksel sistemi paylaşan veya belirli mikro mimari gözlem kanallarına erişebilen bir saldırgan, cache hit/miss zamanlamasını ölçerek bu örüntülerden bilgi çıkarmaya çalışabilir.

AES-NI donanım talimatları, tablo tabanlı AES implementasyonlarındaki klasik S-box cache timing riskini büyük ölçüde azaltır. Çünkü AESENC/AESDEC gibi talimatlar klasik tablo aramalarını kullanmaz. Ancak AES-NI kullanımı tüm yan kanal ve uygulama güvenliği risklerini tek başına ortadan kaldırmaz. Modun uygulanışı, tag doğrulama, hata mesajları, bellek yönetimi, key schedule materyali ve sistem düzeyi mikro mimari riskler ayrıca değerlendirilmelidir.

Power analysis, özellikle akıllı kartlar, HSM’ler ve gömülü kripto donanımı için kritik bir tehdittir. Saldırgan, kriptografik işlem sırasında tüketilen elektrik gücünü ölçerek gizli anahtar bitleri hakkında bilgi çıkarmaya çalışır. Simple Power Analysis tek veya az sayıda izden görsel/örüntüsel bilgi çıkarmaya çalışırken, Differential Power Analysis çok sayıda ölçümü istatistiksel olarak işler.

Bu saldırı doğrudan yazılım ve donanım tasarımını etkiler. Bazı işlemler, gizli bitlerin değerine göre farklı güç tüketimi üretebilir. Maskeleme ve blinding teknikleri bu korelasyonu azaltmak için kullanılır. RSA blinding, private key işlemlerinde girdiyi rastgeleleştirerek timing, güç analizi ve bazı başka yan kanal korelasyonlarını azaltmaya yardımcı olur.

Fault injection saldırılarında saldırgan voltaj dalgalanması, saat manipülasyonu, elektromanyetik müdahale veya lazer gibi yöntemlerle sistemin yanlış hesaplama yapmasını hedefler. RSA-CRT kullanan bir sistemde tek bir hatalı imza, özel anahtarın çarpanlarının GCD hesabıyla ortaya çıkarılmasına yol açabilir. Bellcore saldırısı olarak bilinen bu teknik, teorik bir riskten çok pratik karşılığı olan bir saldırı sınıfıdır.

Yazılım tarafındaki önemli karşı önlemlerden biri, kritik kriptografik işlemlerin sonucunu doğrulama adımlarıyla birleştirmektir. RSA imzası üretildikten sonra public key ile hemen doğrulanırsa, fault sonucu oluşmuş hatalı imzanın dışarı çıkması engellenebilir. Donanım tarafında ise fault detection, redundant computation, fiziksel güvenlik sınırları ve tamper response mekanizmaları devreye girer.

Constant-time programlama, gizli değerden bağımsız yürütme süresi ve bellek erişim örüntüsü sağlamayı hedefler. Bu, gizli bitlere göre farklı dallara ayrılmayan kod, gizli indekslere bağlı tablo aramaları yapmayan algoritmalar ve içerikten bağımsız karşılaştırmalar gerektirir. Bu ilke yalnızca kriptografik algoritma implementasyonlarında değil, MAC doğrulama, token doğrulama ve secret handling kodlarında da önemlidir.

Bellek temizleme de uygulama güvenliğinin sık göz ardı edilen bir boyutudur. Gizli anahtar veya parola kullanımı bittikten sonra bellekte gereksiz yere kalmamalıdır. Derleyici optimizasyonları bazen “kullanılmayan” bellek yazma işlemlerini atlayabilir; bu nedenle klasik memset() her zaman güvenli temizleme garantisi vermez. C/C++ dünyasında explicit_bzero(), SecureZeroMemory() veya güvenilir kütüphanelerin güvenli temizleme fonksiyonları tercih edilir. Rust tarafında zeroize gibi bu amaçla tasarlanmış kütüphaneler kullanılabilir. Go’da ise garbage collector, kopyalar, escape analysis ve derleyici optimizasyonları nedeniyle hassas verinin bellekten güvenli temizlenmesi ayrıca dikkat gerektirir; crypto/subtle bu amaç için değil, constant-time yardımcı işlemler için konumlandırılmalıdır.

Anahtar Yönetimi — İleri

Kriptografik güvenliğin uzun vadeli dayanıklılığı büyük ölçüde anahtarların nasıl yönetildiğine bağlıdır. Güçlü bir şifreleme algoritması, anahtarı yanlış saklayan veya yanlış kullanan bir sistemi koruyamaz. Anahtar yönetimi yalnızca “anahtarı şifreli saklayalım” meselesi değildir; yaşam döngüsü, erişim yetkisi, rotasyon, arşivleme, imha, denetim izi ve mimari ayrıştırma kararlarını kapsar.

Anahtar yaşam döngüsü üretim, dağıtım, saklama, kullanım, rotasyon/yenileme, arşivleme ve imha aşamalarıyla birlikte ele alınmalıdır. NIST SP 800-57 anahtar yönetimini anahtar yaşam döngüsü, güvenlik gücü, kullanım süresi ve kriptografik periyot gibi kavramlarla sistematik biçimde ele alır.

Üretim aşamasında anahtarlar yeterli entropiye sahip güvenilir bir CSPRNG ile üretilmelidir. Entropinin yetersiz olduğu sanal makine, gömülü sistem, erken boot veya hatalı sistem paketleme senaryolarında üretilen anahtarlar tahmin edilebilir olabilir. Debian OpenSSL RNG hatası, rastgelelik kalitesindeki küçük gibi görünen bir değişikliğin milyonlarca anahtarı zayıflatabileceğini göstermiştir.

Dağıtım aşaması, anahtarın üretimden kullanım noktasına güvenli biçimde taşınmasıdır. Açık metin üzerinden taşınan anahtar iletişim kanalına ve uç sistemlerin güvenliğine tamamen bağımlı hâle gelir. Mümkün olduğunda anahtar kurulum protokolleri kullanılmalı; master/KEK gibi uzun ömürlü anahtarlar uygulama ortamlarına açık metin taşınmamalıdır.

Saklama aşamasında anahtarın disk, veritabanı, yapılandırma dosyası, environment variable, container secret veya bellek üzerinde nasıl tutulduğu sorgulanır. Anahtarların düz metin olarak konfigürasyon dosyasına yazılması, environment variable’da uzun süreli tutulması veya loglara düşmesi yaygın ama kritik hatalardır. Anahtarlar kalıcı saklama ve aktarım sırasında açık metin bırakılmamalı; mümkünse HSM, KMS, Vault veya benzeri kontrollü sistemlerde yönetilmelidir. Kullanım sırasında plaintext anahtarın bellekte bulunması gerekiyorsa süre, erişim ve bellek sızıntısı riski en aza indirilmelidir.

KEK ve DEK ayrımı kurumsal anahtar yönetiminin temel mimari prensiplerinden biridir. DEK, gerçek veriyi şifreleyen anahtardır. KEK ise DEK’i şifrelemek veya sarmak için kullanılan üst seviye anahtardır. Bu yapı, veri şifreleme anahtarlarının merkezi ve daha güçlü korunan anahtarlara bağlı biçimde yönetilmesini sağlar.

Key wrapping, bir anahtarın başka bir anahtarla kriptografik olarak paketlenmesidir. AES Key Wrap, RFC 3394 ile tanımlanır ve inherent integrity check içerir. Padding destekli AES Key Wrap ise RFC 5649 ile tanımlanır ve farklı uzunluklardaki key material için kullanılabilir. Hangi wrap yapısının seçileceği, key materyalinin uzunluğuna, standart gereksinimine ve sistem uyumluluğuna göre belirlenmelidir.

KEK rotasyonu ile DEK rotasyonu karıştırılmamalıdır. KEK rotasyonunda mevcut DEK aynı kalabilir ve yalnızca yeni KEK ile yeniden sarılabilir; bu durumda tüm verinin yeniden şifrelenmesi gerekmez. DEK rotasyonunda ise veriyi doğrudan şifreleyen anahtar değiştiği için mevcut verinin yeni DEK ile yeniden şifrelenmesi, yeni veriler için yeni DEK kullanımı veya segment bazlı geçiş gibi ayrı stratejiler gerekir. Büyük ölçekli sistemlerde bu ayrım operasyon maliyetini doğrudan etkiler.

Key rotation, bir anahtarın belirli süre, belirli veri hacmi, belirli kullanım sayısı veya olay sonrası yenisiyle değiştirilmesidir. AES-GCM gibi nonce hassas yapılarda key rotation, aynı anahtar altında nonce alanının güvenli yönetimiyle doğrudan ilişkilidir. Aynı anahtar altında nonce tekrar etmemelidir. Rastgele 96-bit nonce kullanımında collision riski birthday bound ile büyür; yüksek hacimli sistemlerde sayaç veya protokol tarafından benzersizliği garanti edilen nonce üretimi daha denetlenebilir olabilir. Key rotation, nonce alanı yönetimi, kullanım limitleri ve anahtarın maruziyet süresini sınırlamak için planlanmalıdır. NIST SP 800-38D, GCM’de IV/nonce yönetiminin güvenliğin temel bir parçası olduğunu belirtir.

Key archival, düzenleyici uyumluluk, yasal zorunluluk veya geçmiş veriye erişim gereksinimi nedeniyle eski anahtarların imha edilmeden uzun süre saklandığı durumları kapsar. Arşivlenen anahtarlar aktif kullanım anahtarlarından izole edilmeli, erişim yetkileri daha sıkı sınırlandırılmalı ve erişim denetimleri ayrıntılı biçimde tutulmalıdır.

Key destruction veya zeroization, anahtarın güvenli biçimde ortadan kaldırılmasıdır. Yalnızca dosyayı silmek çoğu zaman yeterli değildir; disk yapısı, snapshot, backup, memory dump veya log sistemleri gizli materyalin kopyalarını tutabilir. HSM’lerde key destruction ve zeroization donanım güvenlik sınırları içinde daha güçlü biçimde ele alınabilir; ancak bu davranışın nasıl garanti edildiği ürün ve sertifikasyon dokümantasyonundan doğrulanmalıdır.

Aynı anahtar farklı kriptografik amaçlar için kullanılmamalıdır. Bir imza anahtarının şifreleme için de kullanılması, bir key agreement anahtarının imza bağlamında kullanılması veya TLS oturum anahtarının uygulama seviyesinde başka bir amaçla kullanılması güvenlik modellerini karıştırır. Her anahtarın amacı — şifreleme, imzalama, kimlik doğrulama, key wrapping, key derivation — açık biçimde tanımlanmalı ve bu amacın dışına çıkılmamalıdır. TLS 1.3 gibi modern protokoller, farklı amaçlara ait anahtar materyalini HKDF ve domain separation yoluyla ayırır.

Kriptografik Çeviklik

Kriptografik çeviklik, bir sistemin kriptografik algoritmalarını, parametrelerini ve protokollerini minimum operasyonel kesintiyle değiştirebilme kapasitesidir. Bu yalnızca teknik bir tercih değil, uzun vadeli güvenlik için mimari bir zorunluluktur.

MD5 artık collision resistance gerektiren güvenlik kullanımlarında kabul edilemez. SHA-1 çakışma saldırılarına açıktır. 1024-bit RSA modern tehdit modeline göre yetersizdir. Bu geçişlerin hızlı ve güvenilir biçimde yapılabilmesi, algoritmanın sistemin her katmanına sert biçimde gömülmemesini gerektirir. Algoritma adının kod içine hard-coded yazıldığı bir sistemde geçiş, her çağrı noktasının tek tek güncellenmesini gerektirir. Konfigürasyon, sürümleme veya negotiation mekanizmaları üzerinden algoritmanın belirlendiği sistemlerde ise geçiş daha kontrollü yönetilebilir.

TLS bu pratiği protokol düzeyinde gösterir; ancak TLS 1.2 ve TLS 1.3 cipher suite yapısı doğru ayrılmalıdır. TLS 1.2’de cipher suite adı key exchange, authentication, encryption ve MAC bileşenlerini birlikte ifade eder. TLS 1.3’te ise cipher suite temel olarak AEAD algoritmasını ve hash fonksiyonunu belirtir; key exchange ve authentication ayrı handshake uzantıları, key_share/PSK mekanizmaları ve sertifika/imza adımlarıyla yürür. Bu fark, algoritma geçişi ve güvenlik taraması yorumlarında önemlidir.

Eski algoritmaları desteklemeye devam etmek geçici uyumluluk kolaylığı sağlarken gerçek saldırı yüzeyi oluşturur. SSLv3, TLS 1.0, RC4, 3DES, MD5 ve SHA-1 gibi eski yapıların uzun süre yaşamaya devam etmesinin temel nedeni, eski istemcilerle uyumluluk baskısıdır. Bu baskı operasyonel olarak anlaşılabilir; fakat net bir deprecation timeline olmadan güvenlik riski kontrol edilemez.

Deprecation sürecinin yönetilebilir olması için üç bileşen açık olmalıdır: hangi algoritma veya protokol ne zaman devre dışı bırakılacak, geçiş döneminde hangi uyumluluk kontrolleri yapılacak ve geçiş sonrasında eski algoritmaları hâlâ kullanan sistemler nasıl tespit edilecek. Bu süreç yalnızca güvenlik ekibinin değil, ürün, operasyon, uyumluluk ve müşteri ilişkileri ekiplerinin de planlama alanıdır.

Bir kriptografik algoritmanın değiştirilmesi yalnızca kod düzeyinde etki üretmez. Kodda kütüphane çağrıları, API parametreleri ve test vektörleri değişebilir. Protokolde cipher suite listesi, handshake mesajları ve sürüm müzakeresi etkilenebilir. Sertifika katmanında imza algoritması, anahtar uzunluğu ve kök CA güveni yeniden değerlendirilir. Depolama katmanında mevcut şifreli veri, key wrapping formatı ve KDF çıktı uzunluğu etkilenebilir. Operasyonda key rotation, revokasyon, HSM/KMS desteği ve audit gereksinimleri değişebilir. Uyumluluk tarafında FIPS onaylı algoritma listeleri ve audit gereksinimleri yeniden okunmalıdır.

Post-kuantum geçiş planlaması, kriptografik çevikliğin neden kritik olduğunu somut biçimde gösterir. ML-KEM gibi yeni standartları desteklemeye hazır olmayan sistemlerin yalnızca TLS kütüphanesini güncelleyerek tümüyle PQC-ready hâle gelmesi çoğu zaman mümkün değildir. Sertifika altyapısı, protokol destekleri, HSM/KMS uyumluluğu, istemci cihazları, test ortamı ve operasyonel fallback planı birlikte düşünülmelidir.

Doğrulama ve Standart Uyumu

Kriptografik doğrulama ve standart uyumu, kurumsal güvenlik kararlarında sık başvurulan ama genellikle yanlış yorumlanan iki kavramdır.

FIPS 140-3, kriptografik modüller için güvenlik gereksinimlerini tanımlar ve ISO/IEC 19790’a dayanır. Dört güvenlik seviyesi vardır; seviyeler yükseldikçe fiziksel güvenlik gereksinimleri de artar, fakat standart yalnızca fiziksel güvenlikten ibaret değildir. Modül arayüzleri, rol ve servisler, self-test davranışları, operasyonel ortam, anahtar yönetimi ve diğer modül güvenlik özellikleri de bu çerçevenin parçasıdır. NIST, FIPS 140-3’ün 22 Eylül 2019’da yürürlüğe girdiğini ve ISO/IEC 19790’a referans verdiğini açıklar.

CMVP, NIST ve Kanada’daki Canadian Centre for Cyber Security tarafından yürütülen kriptografik modül doğrulama programıdır. Programın amacı, validasyonu yapılmış kriptografik modüllerin kullanımını teşvik etmek ve federal kurumlar için bir güvenlik ölçütü sağlamaktır. Validasyon, modülün FIPS 140 gereksinimlerine uygunluğunu gösterir; modülün uygulama içinde doğru entegre edildiğini, parametrelerin güvenli seçildiğini veya ürünün tüm operasyonel risklerinin kapandığını göstermez.

FIPS 140-3 sertifikalı bir ürün kullanmak, “kriptografimiz bütünüyle güvenli” anlamına gelmez. Sertifika, belirli bir kriptografik modülün belirli bir konfigürasyon ve güvenlik politikası çerçevesinde doğrulandığını gösterir. Hatalı nonce yönetimi, yanlış API çağrısı, zayıf access control, environment variable’da tutulan anahtar veya yanlış hata mesajı tasarımı FIPS sertifikalı modül kullanılan sistemde de aynı riski üretebilir. CMVP de bir ürünün yalnızca onaylı algoritma kullanmasının FIPS 140 gereksinimlerini karşıladığı anlamına gelmediğini özellikle belirtir.

Standart uyumu ile gerçek güvenlik arasındaki fark burada ortaya çıkar. Bir kriptografik modülün standart uyumlu olması, o standardın kapsadığı gereksinimleri belirli bir test ve validasyon süreci içinde karşıladığını ifade eder. Ancak standartlar yazıldıkları dönemin tehdit modeliyle şekillenir; ayrıca uygulama entegrasyonu, protokol bağlamı ve operasyonel güvenlik standart kapsamının dışında kalabilir.

Kurumsal kripto politikası; onaylı algoritmalar listesi, minimum anahtar uzunlukları, hash fonksiyonları, KDF gereksinimleri, parola hashing parametreleri, anahtar yaşam döngüsü kuralları ve algoritma deprecation takvimi gibi bileşenlerden oluşur. Bu politikanın FIPS, NIST SP 800-57, NIST SP 800-131A, OWASP gibi kaynaklara atıfla hazırlanması hem teknik doğruluğu güçlendirir hem de uyumluluk gereksinimlerini yönetilebilir hâle getirir.

Politikanın belgelenmesi kadar izlenebilir olması da önemlidir. Hangi sistemin hangi algoritmayı, hangi anahtar uzunluğunu, hangi kütüphane sürümünü ve hangi sertifika profilini kullandığının merkezi olarak kayıt altında tutulması gerekir. Bu envanter, audit süreçlerini kolaylaştırır ve post-kuantum geçiş planlaması gibi büyük kriptografik dönüşümlerin temel girdisini oluşturur.

Anahtar Yönetimi, HSM ve Secret Management Araçları

Kurumsal kriptografi mimarisinde anahtarların nerede üretildiği, nerede saklandığı ve erişimin nasıl denetlendiği algoritma seçimi kadar kritik bir mimari karardır. HSM, Cloud KMS ve Vault gibi araçlar benzer görülebilir; fakat güvenlik sınırları, operasyon modeli ve kullanım amaçları farklıdır.

HSM, kriptografik işlemleri ve anahtar materyalini fiziksel ve mantıksal güvenliği yüksek bir donanım ortamında yürüten özel cihazdır. Temel güvenlik hedefi, kritik private veya secret key materyalini donanım güvenlik sınırı içinde tutmak ve dışarıya plaintext olarak çıkarmamaktır. Ancak export, wrap, backup, cluster replication ve key policy davranışları HSM ürününe ve yapılandırmasına göre değişebilir. Bu nedenle kritik anahtarlar non-exportable ve sıkı policy ile yönetilmelidir.

Fiziksel kurcalama tespiti, fiziksel güvenlik sınırları, FIPS 140-2/3 güvenlik seviyesi, güvenli anahtar imha ve rol tabanlı erişim HSM’lerin temel güvenlik boyutları arasındadır. Kök CA anahtarları, kod imzalama anahtarları ve ödeme sistemleri gibi yüksek güvenlik gerektiren alanlarda HSM kullanımı yaygındır.

PKCS#11, HSM’lerle etkileşim için kullanılan üretici bağımsız kriptografik API standardıdır. Anahtar üretimi, imzalama, şifreleme ve doğrulama gibi işlemler PKCS#11 arayüzü üzerinden yapılabilir. Ancak her üreticinin uzantıları, performans karakteristikleri, yönetim arayüzleri ve policy davranışları farklı olabilir. Bu yüzden “PKCS#11 destekliyor” demek tek başına tüm operasyonel gereksinimlerin karşılandığı anlamına gelmez.

Cloud KMS servisleri, anahtar yaşam döngüsü yönetimini cloud ortamlarında yönetilen servis hâline getirir. AWS KMS, Google Cloud KMS ve Azure Key Vault gibi servisler anahtar üretimi, saklama, erişim denetimi, rotasyon, audit log ve API tabanlı kriptografik işlemler sağlar. Ancak kullanılan anahtarın software-protected, HSM-protected, external key, BYOK veya HYOK modelinde olup olmadığı ayrıca kontrol edilmelidir. “KMS kullanıyoruz” ifadesi tek başına HSM düzeyi güvence anlamına gelmez.

Cloud KMS’in avantajı operasyonel kolaylıktır. Anahtar erişimleri IAM politikalarıyla yönetilebilir, audit loglar cloud logging sistemlerine akar ve rotasyon bazı anahtar türlerinde otomatikleştirilebilir. Bunun karşılığında sağlayıcı güven modeli devreye girer. Kurum, sağlayıcının altyapısına, donanım güvenliğine, operasyonel süreçlerine ve hukuki/regülasyonel konumuna güvenmek zorundadır. Daha katı gereksinimlerde BYOK, external key management veya dedicated HSM seçenekleri değerlendirilir.

HashiCorp Vault, secret management ve kriptografik servisler sunan bir araçtır. Veritabanı parolaları, API anahtarları, TLS sertifikaları ve geçici kimlik bilgileri gibi secret’ların merkezi yönetimi için kullanılır. Transit secrets engine üzerinden “encryption as a service” yaklaşımı sunar: uygulama anahtar materyalini doğrudan almaz; veriyi Vault’a gönderir, Vault kriptografik işlemi yapar ve ciphertext veya sonuç döner. Vault Transit, veriyi kalıcı olarak saklamaz; kriptografik işlemleri data-in-transit üzerinde yürütür.

Vault Transit anahtar izolasyonu sağlar; ancak bu, uygulamanın plaintext’i hiç görmediği anlamına gelmez. Çoğu kullanımda uygulama plaintext’i Vault’a gönderir ve ciphertext alır. Bu nedenle uygulama–Vault iletişimi, TLS, kimlik doğrulama, policy, audit log ve veri sınıflandırması birlikte tasarlanmalıdır. Anahtar uygulama sürecine inmez; fakat plaintext akışı hâlâ güvenli biçimde yönetilmelidir.

Vault’un production kullanımında high availability kurulumu, seal/unseal mekanizması, auto-unseal seçimi, audit log yapılandırması, policy tasarımı ve root token yönetimi kritik kararlardır. Vault varsayılan olarak yazılım tabanlı bir secret management aracı gibi konumlanır; ancak HSM veya Cloud KMS entegrasyonlarıyla seal/unseal ve bazı anahtar koruma modelleri güçlendirilebilir. Bu nedenle Vault’un güvenlik modeli deployment mimarisine bağlıdır.

Özellik HSM Cloud KMS HashiCorp Vault

Anahtar izolasyonu Donanım güvenlik sınırı güçlüdür; key policy’ye bağlıdır. Servis modeline göre software-protected, HSM-protected veya external olabilir. Varsayılan olarak yazılım tabanlıdır; HSM/KMS entegrasyonlarıyla güçlendirilebilir.

Operasyon modeli Kurum yönetir; donanım ve erişim operasyonu karmaşıktır. Sağlayıcı yönetir; operasyon kolaylığı yüksektir. Kurum kurar/yönetir veya managed seçenek kullanır; operasyon orta-yüksek karmaşıklıktadır.

Secret management Sınırlıdır; daha çok kriptografik anahtar odaklıdır. Genellikle key management odaklıdır; secret yönetimi servise göre değişir. Güçlü secret management özellikleri sunar.

Audit log Üreticiye ve entegrasyona bağlıdır. Cloud logging/IAM entegrasyonuyla güçlüdür. Audit device yapılandırmasıyla ayrıntılı kayıt üretir.

Key rotation Ürün/API politikasına bağlıdır. Çoğu serviste otomatik veya API tabanlıdır. Transit engine’de versiyonlu anahtar rotasyonu ve rewrap akışı desteklenir.

Uygun kullanım Kök CA, ödeme, kod imzalama, yüksek güvenlikli private key. Cloud-native uygulamalar, merkezi key management, IAM tabanlı erişim. Secret management, dynamic credentials, encryption as a service, policy tabanlı erişim.

Audit log, kriptografik anahtar yönetiminde isteğe bağlı bir konfor değil, güvenliğin operasyonel ve denetlenebilirlik açısından zorunlu bir bileşenidir. Kim, ne zaman, hangi anahtarla, hangi işlemi yaptı ve bu işlem başarılı mı oldu soruları yanıtsız kalmamalıdır. Audit logların bütünlüğü de korunmalıdır; saldırgan veya içeriden tehdit, izini silmek için audit logları değiştirmeye çalışabilir.

Vault audit logları request ve response olaylarını JSON nesneleri olarak kaydeder. Varsayılan olarak çoğu string değer HMAC-SHA256 ile hashlenerek loglanır; ancak non-string değerler, header’lar ve endpoint davranışları yapılandırmaya göre ayrıca değerlendirilmelidir. Bu yüzden audit logların hassas veri içerip içermediği doğrulanmalı ve log erişimi sıkı sınırlandırılmalıdır.

Erişim yetkilerinin minimum privilege prensibiyle tanımlanması anahtar güvenliğinin operasyonel katmanını oluşturur. Bir kimliğin yalnızca encrypt çağrısı yapması gerekiyorsa decrypt yetkisi verilmemelidir. Rotation yetkisi, key deletion yetkisi ve policy yönetimi ayrı rollerde tutulmalıdır. Anahtar güvenliği yalnızca anahtarı saklamakla değil, anahtara hangi işlemin hangi kimlikle yaptırılabildiğini sınırlamakla sağlanır.

Komut & Araç Okuryazarlığı

Bu modülün konusu araç çıktısının standart okuma ile birleştirilmesini gerektirir. Aşağıdaki örnekler komut ezberi değil, güvenlik yorumu alışkanlığı kazandırmak için verilmiştir.

Python cryptography Kütüphanesi — Hazmat API Uyarısı

Python cryptography kütüphanesi, yüksek seviyeli güvenli API ile düşük seviyeli ham kriptografik arayüz arasında açık bir ayrım yapar. Hazmat arayüzleri, geliştiriciye doğrudan kriptografik ilkelere erişim verir; fakat nonce üretimi, tag doğrulama, padding seçimi ve hata davranışı gibi kararlar çağrı koduna kalır.

Genel uygulama şifrelemesi için Fernet, AESGCM veya ChaCha20Poly1305 gibi yapılandırılmış sınıflar tercih edilmelidir. Hazmat arayüzü yalnızca özel bir protokol implementasyonu gerçekten bunu gerektiriyorsa ve geliştirici güvenlik modelini tam olarak biliyorsa kullanılmalıdır.

Bir kod tabanında hazmat.primitives.ciphers.Cipher doğrudan çağrılıyorsa bu otomatik olarak açık anlamına gelmez; ancak IV/nonce yönetimi, tag doğrulama, padding ve hata davranışı ayrıca incelenmelidir. Hazmat kullanımı profesyonel kriptografi yapıldığı anlamına gelmez; güvenlik sorumluluğunun daha büyük kısmının çağrı koduna geçtiği anlamına gelir.

HashiCorp Vault — Transit Engine Audit Log Çıktısı

Vault Transit Engine, uygulamanın anahtar materyalini doğrudan görmeden şifreleme, şifre çözme, imzalama, doğrulama, HMAC ve random byte üretimi gibi kriptografik işlemler yaptırmasına olanak tanır. Transit engine, gönderilen veriyi kalıcı olarak saklamaz; kriptografik işlem yapar ve sonucu döndürür.

Transit encrypt işlemi sonucunda ciphertext genellikle şu biçimde görünür:

Buradaki v1, ciphertext’in key version 1 ile üretildiğini gösterir. Rotation sonrasında yeni encrypt çağrıları daha yeni key version ile ciphertext üretebilir. Eski ciphertext’ler eski key version ile çözülebilir; politika gerektiriyorsa rewrap endpoint’i ile en güncel key version’a taşınabilir. Vault dokümantasyonu, rotation sonrası rewrap sürecinin eski ciphertext’i yeni key version’a geçirmek için kullanılabildiğini açıklar.

Audit log incelenirken auth.display_name, auth.policies, request.path, timestamp ve response bilgileri önemlidir. Hangi kimliğin hangi transit key üzerinde encrypt/decrypt çağrısı yaptığı görülebilmelidir. Aynı kimliğin kısa sürede anormal sayıda decrypt çağrısı yapması, sızdırılmış token veya hatalı otomasyon göstergesi olabilir.

vault:v1: öneki anahtarın zayıf olduğunu göstermez; yalnızca kullanılan key version bilgisini verir. Eski versiyonlu ciphertext’in rewrap edilmesi güvenlik politikası, veri sınıflandırması ve rotasyon stratejisine göre değerlendirilmelidir.

OpenSSL ile ECDSA Anahtar Parametrelerini İnceleme

OpenSSL ile klasik EC anahtar parametreleri incelenirken amaç, eğri adını, anahtar formatını ve public key koordinatlarını doğrulamaktır. Örneğin P-256 anahtarında ASN.1 OID alanı prime256v1 olarak görülebilir. P-384 ise secp384r1 olarak görünebilir.

Bu işlem yalnızca yetkili olunan test anahtarları üzerinde yapılmalıdır. Private key dosyası üzerinde openssl ec -text -noout gibi bir komut çalıştırıldığında private key materyali terminal çıktısına gelebilir. Bu çıktı üretim sistemlerinde loglanmamalı, ekran görüntüsü alınmamalı ve paylaşılmamalıdır.

Klasik ECDSA/ECDH anahtarlarında P-256 veya P-384 gibi eğriler beklenebilir. X25519/Curve25519 anahtar anlaşması için farklı key type olarak ele alınır ve genellikle openssl pkey üzerinden incelenir. Ed25519 imza içindir; X25519 anahtar anlaşması içindir. Eğri ve key type doğrulaması, uygulamanın constant-time scalar multiplication kullandığını garanti etmez; eğri seçimi ile implementasyon güvenliği ayrı katmanlardır.

İleri Seviye Güvenli Analiz / Kontrol Listesi

Bir kriptografik uygulamanın güvenlik gözden geçirmesinde önce sistemin kriptografik envanteri çıkarılmalıdır. Hangi algoritmalar kullanılıyor? Hangi kütüphaneler hangi sürümde? Anahtarlar nerede üretiliyor, nerede saklanıyor ve kimler erişebiliyor? Key rotation belgelenmiş mi? Secret’lar kod, environment variable, CI/CD logları veya container image içinde kalıyor mu?

Şifreleme modları incelenirken AEAD kullanılıp kullanılmadığı kontrol edilmelidir. AEAD yoksa bütünlük doğrulamasının nasıl yapıldığı, MAC’in hangi veri üzerinde hesaplandığı ve doğrulamanın şifre çözmeden önce yapılıp yapılmadığı sorgulanmalıdır. Salt şifreleme, bütünlük ve kimlik doğrulama sağlamaz.

IV/nonce yönetimi kullanılan moda göre ayrı değerlendirilmelidir. CBC için IV tahmin edilemez olmalıdır. GCM, CTR ve ChaCha20-Poly1305 gibi nonce tabanlı yapılarda temel şart aynı anahtar altında nonce’un tekrar etmemesidir. Sayaç tabanlı nonce doğru tasarlanırsa güvenli olabilir; hatta yüksek hacimli sistemlerde rastgele nonce’a göre daha denetlenebilir olabilir. Sabit değer, resetlenen sayaç, çoklu instance çakışması veya snapshot geri dönüşü ciddi risk üretir.

Hata mesajları şifre çözme, padding, MAC/tag doğrulama ve format hatalarını dışarıya farklı biçimde yansıtıyor mu kontrol edilmelidir. Yanıt süreleri de farklılaşmamalıdır. Kriptografik hata yönetimi, kullanıcıya ayrıntılı teknik neden vermek yerine tek ve genel doğrulama başarısızlığı üretmelidir.

Anahtar yönetiminde DEK’lerin açık metin saklanıp saklanmadığı, KEK ile sarılıp sarılmadığı, KEK’in nerede tutulduğu ve anahtar kullanım yetkilerinin minimum privilege ile sınırlandırılıp sınırlandırılmadığı incelenmelidir. Master/KEK anahtarların uygulama environment variable’larına indirilmesi yüksek riskli bir tasarımdır.

Kütüphane kullanımında düşük seviye veya tehlikeli API’ların çağrılıp çağrılmadığı kontrol edilmelidir. API dokümantasyonundaki uyarılar okunmalı, varsayılan parametrelerin güncel güvenlik politikasına uygun olup olmadığı doğrulanmalıdır. Güvenli kütüphane kullanımı, yanlış API kullanımını otomatik olarak engellemez.

Constant-time karşılaştırma, güvenli bellek temizleme, audit log, key rotation ve erişim yetkilendirme uçtan uca doğrulanmalıdır. “FIPS sertifikalı kütüphane kullanıyoruz” ifadesi parametrelerin doğru seçildiğini veya API kullanımının güvenli olduğunu göstermez. “HSM kullanıyoruz” ifadesi anahtar erişim yetkilerinin doğru ayrıldığını garanti etmez. “Şifreliyoruz” ifadesi bütünlük ve kimlik doğrulamanın sağlandığını göstermez.

Teknik bulgu aktarılırken algoritma adının yanına etki ve önerilen eylem eklenmelidir. “AES-CBC kullanılıyor” demek yerine “AES-CBC kullanılıyor ve bütünlük doğrulaması şifre çözmeden önce yapılmıyor; padding oracle ve bit-flipping riskleri oluşabilir; AES-GCM veya ChaCha20-Poly1305 gibi AEAD yapısına geçiş önerilir” demek daha doğru bir güvenlik dili kurar.

Analitik Senaryo

Durum

Şirket içi bir ödeme işleme uygulamasının güvenlik gözden geçirmesinde şu yapı tespit ediliyor: Uygulama her işlem verisini AES-CBC ile şifreliyor. IV bir sayaç üzerinden türetiliyor ve her işlemde 1 artırılıyor. Şifre çözme başarısız olduğunda HTTP yanıtında “padding ok/hatalı” benzeri ayrıntılı mesaj dönüyor. Kullanılan anahtar ise uygulama sunucusunun environment variable’ında açık metin olarak tutuluyor.

İlk Değerlendirme

Bu yapıda birden fazla bağımsız güvenlik sorunu bir arada bulunuyor. İlk sorun, AES-CBC’de IV’nin sayaçtan türetilmesidir. CBC’de IV’nin yalnızca benzersiz olması yeterli değildir; tahmin edilemez olması gerekir. Sayaçtan türetilen IV tahmin edilebilir olduğu için CBC bağlamında güvenlik sorunudur. GCM gibi nonce tabanlı modlarda doğru tasarlanmış sayaç güvenli olabilir; fakat bu senaryoda kullanılan mod CBC olduğu için durum farklıdır.

İkinci sorun, padding hatasının HTTP yanıtında açıkça ayrışmasıdır. Bu davranış padding oracle oluşturabilir. Saldırgan geçerli bir ciphertext üzerinde kontrollü değişiklikler yaparak uygulamanın padding davranışını gözlemleyebilir ve plaintext hakkında bilgi çıkarabilir.

Üçüncü sorun, anahtarın environment variable’da açık metin tutulmasıdır. Environment variable kullanımı bazı deployment pratiklerinde yaygın olsa da uzun ömürlü master/KEK veya veri şifreleme anahtarları için güçlü bir saklama modeli değildir. Crash dump, debug endpoint, process inspection, CI/CD logları, container metadata veya yanlış yapılandırılmış monitoring sistemleri bu değerleri açığa çıkarabilir.

Kontrol Edilecek Noktalar

HTTP yanıtlarında “invalid padding”, “decryption failed”, “MAC failed” gibi ayrımlar var mı incelenmelidir. Yanıt gövdesi kadar HTTP durum kodu ve yanıt süresi de kontrol edilmelidir. Padding hatasında erken çıkış yapılıyorsa timing oracle riski artar.

IV üretim mekanizması ayrıntılı okunmalıdır. Sayaç değeri nerede tutuluyor? Uygulama restart olduğunda sayaç sıfırlanıyor mu? Çoklu instance yapısında iki instance aynı IV değerini üretebilir mi? IV ciphertext ile birlikte açık taşınıyor mu? CBC’de IV açık taşınabilir; sorun IV’nin tahmin edilebilir olmasıdır.

Anahtarın environment variable’da nasıl verildiği kontrol edilmelidir. CI/CD pipeline, container orchestrator, process manager, log aggregation ve crash reporting sistemleri bu değeri kaydediyor mu? Anahtar rotation süreci var mı? Anahtarın hangi veri kümesini şifrelediği biliniyor mu?

İncelenecek Çıktı ve Davranış

Uygulama sunucusu loglarında environment variable dump’ı, debug çıktısı veya exception stack trace içinde anahtar geçip geçmediği incelenmelidir. HTTP yanıt gövdeleri ve yanıt süreleri test ortamında karşılaştırılmalıdır. Şifreli veri formatında IV’nin uzunluğu, konumu ve üretim biçimi ayrıştırılmalıdır.

Test yalnızca izinli ve izole ortamda yapılmalıdır. Padding oracle varlığını doğrulamak için test ortamında geçerli bir ciphertext’in son bloğunda kontrollü bit değişiklikleri yapılıp yanıtın nasıl değiştiği gözlemlenebilir. Üretim sistemine bu tür aktif denemeler yapmak operasyonel ve etik risk doğurur.

Yanlış Yorumlama İhtimali

“AES kullanılıyor, dolayısıyla şifreleme güvenli” yorumu yanlıştır. Sorun algoritmada değil; mod seçimi, IV üretimi, hata mesajı tasarımı ve anahtar saklama mimarisindedir.

“IV benzersiz, o hâlde güvenli” yorumu da CBC için eksiktir. CBC’de IV’nin tahmin edilemez olması gerekir. Benzersizlik GCM/CTR gibi nonce tabanlı yapılarda temel şarttır; CBC’nin güvenlik gereksinimi farklıdır.

“Environment variable secret saklamak için standart bir yöntemdir” yorumu da bağlama bağlıdır. Kısa ömürlü, düşük etkili ve iyi izole edilmiş secret’lar için bazı ortamlarda kullanılsa bile uzun ömürlü veri şifreleme anahtarları veya KEK’ler için daha güçlü KMS/HSM/Vault tabanlı mimari tercih edilmelidir.

Riskin Pratik Karşılığı

Padding oracle varlığında saldırgan, şifre çözme işlemine HTTP yanıtları üzerinden dolaylı erişim sağlıyorsa şifreli veriyi blok blok çözebilir. Bu, kriptografik anahtarı bilmeden plaintext elde etme riski anlamına gelir.

Anahtar environment variable’da tutuluyorsa ve bu değer log, crash dump veya process introspection yoluyla sızarsa, saldırgan yalnızca tek bir işlemi değil, aynı anahtarla şifrelenmiş tüm veriyi çözebilir. Bu risk, padding oracle riskinden bağımsız ikinci bir kritik problemdir.

Önerilen Güvenli Yaklaşım

Yeni tasarımda AES-GCM veya ChaCha20-Poly1305 gibi AEAD yapılarından biri kullanılmalıdır. AEAD yapısında nonce üretimi seçilen algoritmaya göre tasarlanmalıdır. GCM veya ChaCha20-Poly1305 için nonce aynı anahtar altında tekrar etmeyecek şekilde CSPRNG, sayaç veya protokolce garanti edilen bir yöntemle yönetilmelidir. CBC kullanılmaya devam edilecekse IV CSPRNG ile tahmin edilemez üretilmeli ve bütünlük doğrulaması Encrypt-then-MAC prensibiyle şifre çözmeden önce yapılmalıdır; ancak yeni tasarım için AEAD daha doğru varsayılandır.

Şifre çözme başarısızlığında hata türünden bağımsız tek bir genel hata yanıtı dönülmelidir. Yanıt süreleri de mümkün olduğunca ayrıştırılamaz hâle getirilmelidir. Padding, tag, format veya yetki hataları dışarıya farklı teknik ayrıntılarla yansıtılmamalıdır.

Master/KEK gibi uzun ömürlü anahtarlar environment variable yerine HSM, Cloud KMS veya Vault gibi kontrollü sistemlerde yönetilmelidir. DEK gerekiyorsa kısa süreli ve bellekte sınırlı kullanılmalı; KEK uygulamaya indirilmemelidir. Vault Transit veya Cloud KMS entegrasyonu, uygulamanın anahtar materyalini doğrudan görmeden kriptografik işlem yaptırmasını sağlayabilir. Ancak performans, plaintext veri akışı ve audit gereksinimleri ayrıca tasarlanmalıdır.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

Crypto agility Kriptografik çeviklik; bir sistemin kriptografik algoritma, parametre ve protokollerini minimum kesintiyle değiştirebilme kapasitesi.

Constant-time Gizli değerden bağımsız yürütme süresi ve bellek erişim örüntüsü sağlamayı hedefleyen programlama yaklaşımı.

Padding oracle Şifre çözme sırasında padding hatasının farklı yanıt veya süre üretmesinden yararlanan saldırı sınıfı.

Timing attack Kriptografik işlem süresinin gizli bilgiyle korelasyonunu istismar eden yan kanal saldırısı.

Side channel Zamanlama, cache, güç tüketimi veya elektromanyetik yayılım gibi dolaylı gözlemlere dayalı bilgi sızıntısı kanalı.

Cache attack CPU cache erişim zamanlarını kullanarak gizli veri hakkında bilgi çıkarmaya çalışan yan kanal saldırısı.

Power analysis Kriptografik işlem sırasında tüketilen elektrik gücünü ölçerek gizli bilgi çıkarmayı hedefleyen saldırı.

Fault injection Voltaj, saat, elektromanyetik veya fiziksel müdahaleyle sistemin hatalı hesaplama yapmasını sağlama saldırısı.

Bellcore attack RSA-CRT’de hatalı imza üzerinden özel anahtar çarpanlarının GCD hesabıyla açığa çıkarılması saldırısı.

RSA blinding RSA private key işlemlerinde girdiyi rastgeleleştirerek timing ve güç analizi korelasyonlarını azaltan teknik.

Key lifecycle Anahtar yaşam döngüsü; üretim, dağıtım, saklama, kullanım, rotasyon, arşivleme ve imha aşamalarının tamamı.

KEK Key Encrypting Key; DEK gibi alt anahtarları sarmak/şifrelemek için kullanılan üst düzey anahtar.

DEK Data Encrypting Key; asıl veriyi şifreleyen anahtar.

Key wrapping Bir anahtarın başka bir anahtarla standart biçimde sarılması; AES-KW/RFC 3394 ve AES-KWP/RFC 5649 yaygın örneklerdir.

Key rotation Anahtarın belirli süre, kullanım miktarı veya olay sonrası yenisiyle değiştirilmesi.

KEK rotation Mevcut DEK’in yeni KEK ile yeniden sarılması; çoğu durumda tüm verinin yeniden şifrelenmesini gerektirmez.

DEK rotation Veriyi şifreleyen anahtarın değişmesi; mevcut verinin yeniden şifrelenmesi veya yeni veri için yeni DEK kullanılması gerekir.

Key archival Eski anahtarların aktif kullanımdan çıkarıldıktan sonra izole ve güvenli biçimde saklanması.

Key destruction Anahtarın güvenli biçimde imha edilmesi veya zeroization süreci.

Zeroization Anahtar materyalinin güvenli biçimde silinmesi.

HSM Hardware Security Module; anahtarları donanım güvenlik sınırı içinde saklayan ve kriptografik işlemleri bu sınır içinde yürüten cihaz.

Cloud KMS Cloud tabanlı key management service; anahtar yaşam döngüsü, erişim denetimi ve kriptografik işlemler için yönetilen servis.

PKCS#11 HSM ve benzeri kriptografik token’larla etkileşim için kullanılan üretici bağımsız API standardı.

Secret management Parolalar, API anahtarları, sertifikalar ve tokenlar gibi gizli bilgilerin merkezi ve denetimli yönetimi.

FIPS 140-3 Kriptografik modüller için güvenlik gereksinimlerini tanımlayan ABD federal standardı; ISO/IEC 19790’a dayanır.

CMVP NIST ve CCCS tarafından yürütülen Cryptographic Module Validation Program.

Deprecation Güvensiz veya eski kabul edilen algoritma/protokolün kontrollü biçimde kullanım dışı bırakılması.

Memory-safe zeroing Derleyici optimizasyonlarından etkilenmeden gizli veriyi bellekten temizleme yaklaşımı.

Hazmat API Kriptografik kütüphanelerin düşük seviyeli, yanlış kullanım riski yüksek ilkel arayüzü.

Vault Transit Engine Vault’un encryption/cryptography as a service sağlayan secrets engine’i; anahtar uygulamaya inmeden işlem yapılmasını sağlar.

Audit log Kriptografik işlem, anahtar kullanımı ve erişim olaylarının zaman damgalı denetim kaydı.

Key purpose separation Her anahtarın yalnızca belirli bir kriptografik amaç için kullanılması prensibi.

Environment variable secret Uygulama ortam değişkenlerinde tutulan secret; kullanım kolaylığı sağlasa da sızıntı ve log riski taşır.

AEAD Authenticated Encryption with Associated Data; gizlilik ve bütünlüğü birlikte sağlayan şifreleme yapısı.

GHASH AES-GCM’nin Galois alanı üzerinde çalışan authentication bileşeni.

Poly1305 ChaCha20-Poly1305 gibi yapılarda kullanılan one-time MAC.

Kendini Değerlendir — İleri Kriptografi Modül 7

Bu Modülde Neler Öğrendik?

Bu modül, kriptografik güvenliğin yalnızca doğru algoritmayı seçmekle bitmediğini somut biçimde ortaya koydu. Doğru seçilmiş bir algoritma, yanlış API kullanımı, hatalı hata mesajı tasarımı, tekrarlanan nonce, tahmin edilebilir IV veya açık metin saklanan anahtar nedeniyle güvensiz hâle gelebilir.

Yan kanal saldırıları artık soyut bir tehdit değil; timing davranışı, cache erişim örüntüsü, güç tüketimi ve fault injection üzerinden gerçekleşen somut bir tehdit katmanı olarak anlaşılmalıdır. Savunma için constant-time programlama, donanım hızlandırma, blinding, masking, güvenli karşılaştırma ve kritik sonuç doğrulama gibi teknikler gerekir.

Anahtar yönetimi, yaşam döngüsü bütünlüğünde ele alındı. Üretimden imhaya kadar her aşamanın ayrı güvenlik gereksinimi olduğu görüldü. KEK/DEK hiyerarşisi, key wrapping, rotasyon, arşivleme, imha ve anahtar amaç ayrımı kurumsal kriptografi mimarisinin temel parçalarıdır.

Kriptografik çeviklik, post-kuantum geçişiyle birlikte artık teorik değil pratik bir gereksinimdir. Bir algoritmanın değişimi kod, protokol, sertifika, depolama, operasyon ve uyumluluk katmanlarını aynı anda etkileyebilir. Bu yüzden geçiş planı önceden tasarlanmış bir mimari kabiliyet olmalıdır.

FIPS 140-3 ve CMVP gibi standart uyumu mekanizmalarının gerçek güvenliği otomatik olarak garanti etmediği netleşti. Validasyon modül seviyesinde bir güvence sağlar; uygulama entegrasyonu, parametre seçimi, nonce yönetimi, erişim kontrolü ve hata davranışı ayrıca değerlendirilmelidir.

HSM, Cloud KMS ve HashiCorp Vault aynı ihtiyaca farklı güvenlik ve operasyon modelleriyle cevap verir. HSM donanım güvenlik sınırı sunar; Cloud KMS yönetilen anahtar yaşam döngüsü sağlar; Vault secret management ve Transit Engine ile uygulamalara policy tabanlı kriptografik servis sunar. Bu araçların her biri ancak doğru policy, audit log, erişim denetimi ve rotasyon stratejisiyle güvenli mimarinin parçası olur.

Bu modülün en önemli çıktısı şudur: kriptografik güvenlik algoritmayı doğru seçmekle başlar; fakat uygulama güvenliği, anahtar yönetimi, yan kanal farkındalığı, hata mesajı tasarımı, güvenli API kullanımı ve kurumsal geçiş planlamasıyla tamamlanır.

MODÜL 8 — Eşik kriptografisi, MPC ve dağıtık güven

Modül özeti

Tekil private key riskini matematiksel olarak dağıtır; fakat tarafların gerçek bağımsızlığı ve protokol mesajlarının güvenli taşınması operasyonel olarak en az kripto kadar kritiktir.

Modül 8 — Eşik Kriptografisi, MPC ve Dağıtık Güven

Kriptografik güven modelleri uzun yıllar boyunca tek noktaya —bir anahtara, bir sunucuya, bir yetkiye— odaklandı. Eşik kriptografisi bu merkezi yapıyı sorgular ve güveni birden fazla taraf arasında dağıtmayı matematiksel olarak mümkün kılar. Tek bir özel anahtarın hiçbir zaman tek bir noktada tam olarak oluşmadığı sistemler artık yalnızca akademik araştırma konusu değildir; kripto varlık saklama, kurumsal imza altyapısı, dağıtık validator sistemleri ve gizlilik koruyucu hesaplama gibi alanlarda üretim düzeyinde önemli bir gereksinim hâline gelmiştir.

Bu modül, Shamir’in Gizli Paylaşım Şeması’ndan doğrulanabilir gizli paylaşıma, eşik imza protokollerinden güvenli çok taraflı hesaplamaya kadar uzanan yapıları güvenlik modeli ve pratik sınırları çerçevesinde ele alır. Öğrenci, dağıtık güven kavramını matematiksel sezgiyle kavramakla birlikte bu sistemlerin operasyonel karmaşıklığını, güven modeli farklılıklarını ve üretim ortamına taşınırken ortaya çıkan gerçek zorlukları da analiz edebilmelidir.

Modül boyunca (t,n) eşik notasyonu tutarlı biçimde kullanılacaktır. Bu notasyonda n toplam taraf sayısını, t ise sırrı yeniden inşa etmek veya threshold işlemi gerçekleştirmek için gereken minimum taraf sayısını ifade eder. Shamir’in Gizli Paylaşım Şeması’nda bu yapı için polinom derecesi t−1 olur; herhangi t pay sırrı yeniden elde etmeye yeterken, t−1 veya daha az pay sır hakkında bilgi-teorik anlamda bilgi vermez. Shamir paylaşımında degree t−1 polinom kullanımı ve t pay ile Lagrange interpolasyonu yapılması standart anlatımdır.

Modül, önceki modüllerde incelenen RSA/ECC anahtar yönetimi, AEAD güvenlik hedefleri, kriptografik çeviklik ve protokol güvenliği kavramlarını dağıtık güven perspektifinden yeniden okur. Öğrenciyi “özel anahtarı nasıl koruyabiliriz?” sorusundan “özel anahtarın hiçbir zaman tek parça hâlde var olmaması gerekir mi?” sorusuna taşır. NIST’in Multi-Party Threshold Cryptography projesi de eşik şemaları, MPC ilkelerini kriptografik ilkelere uygulayarak güveni birden fazla taraf arasında dağıtan yapılar olarak konumlandırır.

Kazanımlar

Bu modül sonunda öğrenci:

Shamir’in Gizli Paylaşım Şeması’nın matematiksel yapısını ve (t,n) eşik mantığını güvenlik modeli bağlamında açıklayabilir; t pay ile reconstruction yapılabildiğini, t−1 veya daha az payın bilgi-teorik gizlilik sağladığını ve polinom derecesinin t−1 olduğunu doğru ifade edebilir.

Feldman ve Pedersen VSS yapılarının neden gerekli olduğunu, pay doğrulamanın dağıtık güven modeline ne kattığını ve gizlilik-doğrulanabilirlik dengesini değerlendirebilir.

Feldman VSS’nin esas katkısının public commitment tabanlı pay doğrulama olduğunu; Pedersen VSS’de taahhütlerin bilgi-teorik gizlilik sağladığını, bağlayıcılığın ise ayrık logaritma ilişkisine dayalı hesaplamalı varsayıma bağlı olduğunu açıklayabilir.

Threshold ECDSA, threshold EdDSA/Schnorr ve threshold BLS imza şemalarının çalışma mantığını; özel anahtarın yeniden birleştirilmemesi gerektiği fikrinin protokole nasıl yansıdığını ve custody sistemlerinde bu yapıların kullanım gerekçesini analiz edebilir.

Threshold ECDSA’da k^{-1}(H(m)+r·d) yapısının dağıtık biçimde hesaplanmasının neden karmaşık olduğunu; threshold Schnorr/EdDSA tarafında FROST gibi protokollerin nonce commitment ve binding factor mantığıyla güvenliği nasıl güçlendirdiğini açıklayabilir. FROST, RFC 9591’de iki turlu threshold Schnorr imza protokolü olarak tanımlanır.

BLS threshold signature ile BLS aggregate signature arasındaki farkı ayırt edebilir; threshold BLS’de aynı shared secret key’in paylarından signature share üretildiğini, aggregate BLS’de ise farklı public key’lere ait imzaların birleştirildiğini ifade edebilir.

Güvenli çok taraflı hesaplamayı honest-but-curious ve malicious model çerçevesinde konumlandırabilir; ayrıca dürüst çoğunluk, dishonest majority, static/adaptive corruption, abort/fairness ve ağ senkronluğu gibi ek güven modeli eksenlerinin önemini kavrayabilir.

Garbled circuit ve oblivious transfer kavramlarını saldırı yüzeyiyle birlikte yorumlayabilir; bu yapıların hangi güvenlik modeli altında tarafların kendi girdileri ve çıktı dışında ek bilgi öğrenmesini engellemeyi hedeflediğini açıklayabilir.

Dağıtık kripto sistemlerinin performans, iletişim ve operasyonel risklerini akademik modelden ayırarak üretim gerçekliğiyle karşılaştırabilir.

Share refresh, resharing, participant replacement ve backup/recovery gibi kavramları birbirinden ayırabilir; share refresh’in temel amacının sırrı değiştirmeden payları yenileyerek zaman içinde biriken compromise riskini azaltmak olduğunu açıklayabilir.

MPC ve eşik kriptografi araç ekosistemini üretim olgunluğu, denetlenebilirlik ve bakım maliyeti açısından değerlendirebilir; demo araçla üretim sistemi arasındaki farkı somutlaştırabilir.

Eşik kriptografisine geçiş kararı içeren bir mimari öneride riskleri, güven varsayımlarını ve operasyonel gereksinimleri doğru biçimde ifade edebilir.

Gizli Paylaşım Şemaları

Klasik anahtar yönetiminde bir özel anahtar tek bir noktada tutulur ve bu nokta tehlikeye girdiğinde sistemin tamamı risk altına girer. Gizli paylaşım şemaları bu merkezi güven yapısını dağıtmak için geliştirilmiştir. Temel fikir, bir sırrı tek bir tarafta saklamak yerine birden fazla taraf arasında matematiksel olarak bölmek ve yalnızca belirli eşik sayıda tarafın birleşmesiyle sırrı yeniden elde edebilmektir.

Shamir’in Gizli Paylaşım Şeması, 1979’da önerilen ve sonlu alan aritmetiği üzerinde polinom interpolasyonuna dayanan klasik bir yapıdır. Bu modülde (t,n) notasyonu kullanılacaktır. Burada n toplam pay sayısını, t ise sırrı geri getirmek için gereken minimum pay sayısını ifade eder. Bu notasyonla Shamir SSS’de sabit terimi sır olan t−1 dereceli rastgele bir polinom seçilir. n katılımcıya bu polinomun farklı noktalardaki değerleri, yani paylar, dağıtılır. Herhangi t farklı pay bir araya geldiğinde Lagrange interpolasyonu ile polinomun sabit terimi ve dolayısıyla sır geri elde edilebilir. t−1 veya daha az pay ise sır hakkında bilgi-teorik anlamda bilgi vermez.

Bu bilgi-teorik güvenlik, saldırganın hesaplama gücünden bağımsızdır. Yani saldırgan sınırsız hesaplama gücüne sahip olsa bile, t−1 veya daha az payla sırrı diğer olası sırlar arasından ayırt edemez. Bu güçlü garanti, payların gerçekten rastgele polinomdan üretilmesine, sonlu alan aritmetiğinin doğru uygulanmasına ve payların gizli tutulmasına bağlıdır.

Eşik parametresi hem güvenliği hem de erişilebilirliği belirler. t=1 olduğunda herhangi bir pay sırrı geri getirebilir; bu durumda güvenlik çok zayıf, erişilebilirlik çok yüksektir. t=n olduğunda tüm payların birleşmesi gerekir; bu durumda güvenlik daha sıkı, erişilebilirlik ise daha kırılgandır. Pratik sistemlerde t değeri, kaç tarafın tehlikeye girebileceği ve kaç tarafın çevrimdışı kalabileceği sorularına göre seçilir.

Bir (2,3) sisteminde üç paydan herhangi ikisi sırrı geri getirebilir; bir pay tek başına bilgi vermez. Bir (3,5) sisteminde beş paydan herhangi üçü yeterlidir; iki veya daha az pay sır hakkında bilgi vermemelidir. Bu örnekler basit görünse de üretim sistemlerinde tarafların gerçekten bağımsız olup olmadığı, aynı yönetim hesabına mı bağlı oldukları, aynı bulut ortamında mı çalıştıkları ve aynı operasyon ekibi tarafından mı kontrol edildikleri güvenlik sonucunu doğrudan etkiler.

Shamir SSS’de kritik güven varsayımlarından biri dealer üzerindedir. Dealer, sırrı başlangıçta bölüp payları dağıtan taraftır. Dealer kötü niyetliyse katılımcılara tutarsız paylar dağıtabilir, beklenen sır yerine başka bir sır paylaşabilir veya bazı katılımcılara geçersiz pay gönderebilir. Bu durum klasik Shamir paylaşımında katılımcılar tarafından doğrudan tespit edilemez. VSS, yani doğrulanabilir gizli paylaşım, bu problemi çözmeye yönelik geliştirilmiştir. Merkezi dealer güvenini tamamen azaltmak isteyen yapılarda ise DKG, yani dağıtık anahtar üretimi, değerlendirilir.

Shamir paylaşımının bilgi-teorik güvenliği, payların güvenli biçimde dağıtıldığı varsayımına da bağlıdır. Pay dağıtımı açık, dinlenebilir veya değiştirilebilir bir kanal üzerinden yapılırsa saldırgan payları ele geçirebilir ya da değiştirebilir. Bu yüzden pay dağıtımı kimlik doğrulamalı ve gizli kanallar üzerinden yapılmalıdır. Payların saklandığı uç sistemler de en az payın kendisi kadar önemlidir; çünkü yeterli sayıda pay ele geçirilirse sır geri getirilebilir.

Reconstruction aşaması güvenlik açısından özel dikkat ister. Yeterli sayıda pay bir araya geldiğinde sır genellikle bir noktada yeniden oluşur. Bu merkezi reconstruction noktası kötü tasarlanırsa, paylaşım şemasının getirdiği dağıtık güven avantajının önemli bir bölümü kaybedilir. Bu nedenle eşik imza protokolleri, sırrı yeniden inşa etmek yerine paylar üzerinde doğrudan kriptografik işlem yapmayı hedefler. NIST de threshold şemaların, secret key’i reconstruct etmeden kriptografik operasyon gerçekleştirmeyi amaçladığını vurgular.

Basit eğitim testlerinde t payla reconstruction yapıldığında doğru sır elde edilmelidir. t−1 veya daha az payla reconstruction yapılmamalı ya da kütüphane hata vermelidir. Eksik payla yanlış veya anlamsız bir değer dönmesi tek başına güvenlik kanıtı değildir. Güvenlik, t−1 veya daha az payın tüm olası sırlarla uyumlu dağılım verebilmesi üzerinden anlaşılır.

Doğrulanabilir Gizli Paylaşım

Shamir SSS, payların gizliliği ve eşik mantığı açısından güçlüdür; ancak pay alan katılımcı, aldığı payın gerçekten dealer’ın yayımladığı veya protokolün beklediği polinomla tutarlı olup olmadığını kendi başına doğrulayamaz. Kötü niyetli veya hatalı çalışan bir dealer, farklı katılımcılara tutarsız paylar dağıtabilir. Bu durum reconstruction aşamasında sırrın geri getirilememesine veya protokolün sabote edilmesine yol açabilir.

Doğrulanabilir Gizli Paylaşım, yani VSS, katılımcıların aldıkları payların tutarlılığını kontrol edebilmesini sağlar. Buradaki amaç, payın doğru polinomdan geldiğini veya public commitment’larla uyumlu olduğunu gösterebilmektir. VSS, özellikle dağıtık anahtar üretimi ve eşik imza protokollerinde temel bir yapı taşıdır.

Feldman VSS, Shamir paylaşımına public commitment tabanlı doğrulanabilirlik ekler. Dealer, polinom katsayılarına karşılık gelen grup elemanlarını, örneğin g^{a_i} biçimindeki commitment’ları, kamuya açık olarak yayımlar. Katılımcı aldığı payı bu commitment’larla tutarlılık açısından kontrol edebilir. Böylece dealer’ın payları rastgele veya tutarsız dağıtması daha kolay tespit edilir.

Feldman VSS’nin ana katkısı gizlilikten çok doğrulanabilirliktir. Commitment’lar herkese açık olduğu için sistemin gizlilik garantisi bilgi-teorik değil, kullanılan grubun ayrık logaritma probleminin zorluğu gibi hesaplamalı varsayımlara bağlıdır. Eğer sır veya polinom katsayıları düşük entropili seçilirse, public commitment’lar ek risk doğurabilir. Bu nedenle Feldman VSS, “gizliliği bilgi-teorik olarak korur” şeklinde anlatılmamalıdır.

Pedersen VSS, gizlilik tarafında daha güçlü bir yapı sunar. Pedersen commitment’larında ek rastgelelik kullanılır ve taahhütler genel biçimde g^{a_i} h^{b_i} gibi iki tabanlı bir yapıya dayanır. Bu commitment’lar bilgi-teorik olarak gizlidir; yani commitment değeri, taahhüt edilen katsayı hakkında doğrudan bilgi vermez. Buna karşılık bağlayıcılık, g ve h arasındaki ayrık log ilişkisinin bilinmemesi gibi hesaplamalı varsayımlara dayanır. Pedersen commitment’larının perfect hiding ve computational binding özelliği bu ayrımın temelidir.

Bu nedenle Feldman ve Pedersen VSS arasındaki fark, yalnızca “biri daha güçlüdür” şeklinde okunmamalıdır. Feldman VSS daha sade ve doğrulanabilirlik açısından etkilidir; fakat gizlilik tarafında public commitment’ların hesaplamalı varsayımlara dayandığı unutulmamalıdır. Pedersen VSS gizlilik tarafında daha güçlüdür; ancak doğru parametre üretimi, güvenilir grup seçimi ve commitment bağlayıcılığı için hesaplamalı varsayımlar önemlidir.

VSS, katılımcıların aldıkları payları doğrulamasını sağlar; ancak kötü niyetli katılımcıların reconstruction aşamasında sahte pay sunması ayrı bir problemdir. Plain Shamir SSS bu sahte payları kendi başına ayırt edemez. Feldman veya Pedersen VSS’de paylar commitment’lara karşı doğrulanabilir; fakat kötü niyetli katılımcıları ayıklama, complaint/dispute mekanizması, robuste reconstruction veya publicly verifiable secret sharing gibi ek yapılar protokol tasarımına göre ayrıca gerekir.

Dağıtık güven açısından VSS’nin en önemli katkısı, dealer’ın tamamen görünmez biçimde hata yapmasını engellemesidir. Katılımcılar kendi paylarını doğrulayabildiğinde, hatalı paylar erken aşamada tespit edilebilir. Ancak VSS dealer güvenini tümüyle ortadan kaldırmaz. Merkezi dealer istemeyen sistemlerde DKG protokolleri kullanılır. DKG’de taraflar birlikte anahtar paylarını üretir; özel anahtar hiçbir zaman tek bir dealer tarafından tam olarak bilinmez.

Eşik İmza Şemaları

Gizli paylaşım şemalarının imzalama süreçlerine uygulanması, özel anahtarın hiçbir zaman tek bir noktada tam olarak oluşmadığı imza sistemleri üretir. Bu fikir özellikle yüksek değerli varlıkların güvenliğinde, kripto para cüzdanlarında, kurumsal imza altyapılarında ve bazı sertifika yetkilisi mimarilerinde önemli bir gereksinim olarak öne çıkar.

Threshold imza sistemlerinde amaç, standart doğrulayıcılar tarafından normal imza gibi kabul edilen bir imzayı, birden fazla tarafın paylarıyla üretmektir. NIST’in threshold kriptografi yaklaşımında da threshold-produced signature, mümkün olduğunda geleneksel imza doğrulama algoritmasıyla doğrulanabilir olmalıdır.

Threshold ECDSA, pratikte yaygın ihtiyaç duyulan ama teknik olarak karmaşık bir alandır. ECDSA imza denklemi s = k^{-1}(H(m)+r·d) mod q yapısına dayanır. Burada d özel anahtar, k ise her imza için benzersiz ve gizli olması gereken nonce değeridir. Threshold ECDSA’da hem d hem de k dağıtık biçimde ele alınır; hiçbir taraf tam özel anahtarı veya tam nonce’u bilmemelidir.

Threshold ECDSA’nın zorluğu, bu imza denkleminin MPC içinde güvenli hesaplanmasından kaynaklanır. Dağıtık nonce üretimi, nonce inverse hesaplaması, r·d terimi, imza paylarının doğrulanması ve malicious taraflara karşı koruma protokolü karmaşık hâle getirir. Tek bir taraf nonce’u tam bilmese bile, kendi nonce payını zayıf rastgelelikle üretmesi veya protokol mesajlarını kötü niyetli biçimde seçmesi güvenliği etkileyebilir.

Threshold ECDSA’nın avantajı, çıkan imzanın standart ECDSA imzası olmasıdır. Doğrulayıcı taraf, imzanın threshold protokolle mi yoksa tek bir özel anahtarla mı üretildiğini bilmek zorunda değildir. Bu özellik, mevcut blockchain ağları ve sertifika doğrulama altyapılarıyla uyumluluk açısından önemlidir. Bedeli ise daha karmaşık protokol, daha fazla iletişim turu ve daha yüksek implementasyon riskidir.

Threshold EdDSA veya daha genel ifadeyle threshold Schnorr tabanlı yapılar, ECDSA’ya kıyasla daha doğal bir cebirsel forma sahiptir. Ancak bu, tek kullanıcılı Ed25519 nonce formülünün basitçe taraflara bölünebileceği anlamına gelmez. Pratik threshold Schnorr protokolleri nonce payları, nonce commitment’ları, binding factor’lar, imza payı doğrulama ve identifiable abort gibi mekanizmalar kullanır.

FROST, bu alanda güncel ve iyi bilinen bir yaklaşımdır. RFC 9591, FROST’u iki turlu Flexible Round-Optimized Schnorr Threshold signing protokolü olarak tanımlar. FROST, önceki Schnorr threshold yapılarında görülen bazı forgery risklerine karşı nonce commitment ve binding factor mantığını kullanır; imza üretimi için threshold sayıda tarafın iş birliğini gerektirir.

BLS threshold signatures, eşik imza sistemleri içinde daha doğal bir birleştirme yapısına sahiptir. Threshold BLS’de katılımcılar aynı shared secret key’in paylarına sahiptir. Her katılımcı aynı mesaj üzerinde kendi signature share’ini üretir. Yeterli sayıda signature share, Lagrange katsayılarıyla birleştirilerek tek bir geçerli BLS imzasına dönüştürülür. Bu işlem, doğrulayıcı tarafından normal BLS imzası gibi kontrol edilebilir.

BLS threshold signature ile BLS aggregate signature karıştırılmamalıdır. Threshold BLS’de pay sahipleri aynı grup özel anahtarının paylarıyla tek bir imza üretir. BLS aggregation ise farklı public key’lere ait tam imzaların tek bir aggregate signature hâline getirilmesidir. Aggregate imza senaryolarında rogue-key saldırıları, proof-of-possession veya message augmentation gibi ek savunmalar gerekir. BLS imza taslakları aggregation özelliğini açıkça ele alır; fakat bu özellik threshold share combining ile aynı güvenlik modeli değildir.

Ethereum’un proof-of-stake konsensüs katmanı BLS imzaları ve aggregation’dan yararlanır. Ancak bu, her Ethereum validator imzasının otomatik olarak threshold BLS olduğu anlamına gelmez. Distributed Validator Technology gibi yaklaşımlar validator key’ini threshold mantığıyla dağıtabilir; bu ayrı bir mimari katmandır. Bu ayrım yapılmazsa BLS aggregation ile threshold BLS aynı şeymiş gibi anlaşılır.

Custody sistemlerinde threshold imzaların pratik değeri yüksektir. Geleneksel yaklaşımda özel anahtar tek parça hâlinde bir HSM’de, donanım cüzdanda veya güvenli depoda tutulabilir. Threshold imza yapısında ise özel anahtar hiçbir zaman tek parça oluşmaz; imza üretmek için belirlenmiş sayıda tarafın koordineli katılımı gerekir. Bu tasarım tek bir private key dosyasının veya tek cihazın ele geçirilmesi riskini önemli ölçüde azaltır.

Buna rağmen threshold imza tüm single point of failure sorunlarını kendiliğinden ortadan kaldırmaz. Koordinatör servis, aynı bulut hesabı, aynı CI/CD pipeline, aynı yönetici kimliği, aynı güvenlik sınırındaki taraflar veya tek tedarikçi bağımlılığı yeni tekil ya da korelasyonlu hata noktaları oluşturabilir. Threshold kriptografi, özel anahtar materyalini dağıtır; operasyonel bağımlılıkların da dağıtık ve bağımsız tasarlanması gerekir.

Threshold imza protokollerinin birden fazla versiyonu ve implementasyonu vardır. Özellikle threshold ECDSA protokolleri aktif araştırma ve denetim konusu olmaya devam etmektedir. Üretim ortamında bağımsız kriptografik denetimden geçmiş, aktif bakımı süren, güvenlik modeli açıkça dokümante edilmiş ve test vektörleri bulunan implementasyonlar tercih edilmelidir. Demo amaçlı prototipler, gerçek varlık koruma sistemleri için doğrudan kullanılmamalıdır.

Güvenli Çok Taraflı Hesaplama

Güvenli çok taraflı hesaplama, yani Multi-Party Computation, birden fazla tarafın kendi girdilerini birbirine açıklamadan ortak bir fonksiyonu hesaplayabilmesini hedefler. Eşik imzalar bu fikrin belirli bir kriptografik ilkeye uygulanmış hâlidir; MPC ise daha genel bir çerçeve sunar.

MPC güvenlik modellerinde en temel ayrımlardan biri honest-but-curious ve malicious model ayrımıdır. Honest-but-curious, yani semi-honest modelde tarafların protokol kurallarına uyduğu; ancak gördükleri mesajlardan diğer tarafların girdileri hakkında ek bilgi çıkarmaya çalıştıkları varsayılır. Bu model daha iyimserdir ve çoğu zaman daha verimli protokoller sağlar.

Malicious modelde taraflar protokol kurallarından sapabilir, sahte mesaj gönderebilir, hesaplamayı sabote edebilir, çıktı üretimini engelleyebilir veya diğer tarafların girdileri hakkında ek bilgi elde etmeye çalışabilir. Bu model gerçek dünya güvenliği açısından daha güçlüdür; fakat ek doğrulama, sıfır bilgi ispatı, commitment, consistency check ve daha fazla iletişim maliyeti gerektirebilir.

Semi-honest ve malicious ayrımı temel başlangıçtır; fakat MPC güvenlik modeli yalnızca bu iki başlıkla bitmez. Dürüst çoğunluk veya dishonest majority varsayımı, static veya adaptive corruption, abort/fairness garantisi, senkron veya asenkron ağ modeli, taraf sayısı ve tarafların çevrimdışı kalma ihtimali de güvenlik sonucunu etkiler. Bu yüzden bir MPC protokolünü değerlendirirken “malicious secure” ifadesinin hangi ağ, çoğunluk ve bozulma modelinde geçerli olduğu okunmalıdır.

Yao’nun garbled circuit yapısı, iki taraflı güvenli hesaplama için klasik bir yaklaşımdır. Hesaplama bir mantık devresi olarak ifade edilir. Bu devre karıştırılmış biçimde evaluator tarafına verilir. Evaluator, kendi girdisi ve protokol aracılığıyla aldığı gerekli etiketlerle devreyi değerlendirir. Doğru güvenlik modelinde ve oblivious transfer ile birlikte uygulandığında tarafların kendi girdileri ve fonksiyon çıktısı dışında ek bilgi öğrenmesini engellemeyi hedefler.

Oblivious transfer, MPC’nin temel yapı taşlarından biridir. Basit biçimde, alıcı bir seçenek indeksine karşılık gelen veriyi gönderenden alır; gönderen hangi değerin seçildiğini öğrenmez, alıcı ise seçmediği değerleri öğrenemez. OT, garbled circuit protokollerinin yanı sıra çok sayıda modern MPC yapısının temel bileşenidir. Verimli OT extension tekniklerinin gelişmesi, pratik MPC sistemlerini mümkün kılan en önemli adımlardan biridir.

MPC’nin üretim ortamında görülen başlıca kullanım alanları arasında private set intersection, dağıtık imzalama, gizlilik koruyucu analitik, finansal denetim ve bazı gizlilik koruyucu makine öğrenmesi senaryoları yer alır. Reklam teknolojisinde iki kuruluş ortak müşteri kümesini ham listeleri paylaşmadan hesaplamak isteyebilir. Finansal denetimde kuruluşlar belirli toplam veya eşik koşullarını ham veriyi açmadan kanıtlamak isteyebilir. Fakat her senaryoda veri kalitesi, tarafların güven sınırları, output leakage ve operasyon maliyeti ayrıca değerlendirilmelidir.

Çoğu threshold imza ve MPC protokolü online aşamada taraflar arasında etkileşim gerektirir. Bazı yapılar offline preprocessing ile online gecikmeyi azaltır; örneğin bazı ara rastgelelikler veya correlated randomness önceden hazırlanabilir. Eşik imza sistemlerinde her zaman tüm n tarafın katılması gerekmez; t uygun tarafın katılımı yeterli olabilir. Fakat bu tarafların aynı anda erişilebilir olması, mesaj turlarını tamamlaması ve kimlik doğrulamalı güvenli kanallarla konuşması gerekir.

Dağıtık Kripto Sistemlerinin Sınırları

Eşik kriptografi ve MPC güçlü güvenlik modelleri sunar; ancak bu garantilerin üretim gerçekliğine dönüşmesi kolay değildir. Akademik protokol güvenliği ile üretim sistemi güvenliği aynı şey değildir. Bir protokol makalede belirli varsayımlar altında güvenli olabilir; fakat gerçek sistemde ağ kesintileri, taraf başarısızlığı, güncelleme hataları, içeriden tehditler ve operasyonel merkeziyetçilik bu varsayımları bozabilir.

Performans ve iletişim maliyeti ilk büyük sınırdır. Threshold ECDSA gibi protokoller tek taraflı imzalamanın ötesinde ek iletişim turları ve MPC hesaplamaları gerektirir. Garbled circuit tabanlı genel MPC protokolleri hesaplama ve ağ trafiği açısından ağır olabilir. BLS threshold yapıları bazı senaryolarda daha doğal ve verimli bir birleştirme sunar; fakat pairing maliyeti, curve seçimi ve protocol-specific güvenlik ayrıntıları yine değerlendirilmelidir.

Güven modeli karmaşıklığı ikinci sınırdır. (t,n) eşik sisteminde gizlilik genellikle t−1 veya daha az payın ele geçirilmesine karşı korunur; t veya daha fazla pay ele geçirilirse sır veya imza yetkisi riske girebilir. Malicious MPC protokollerinde tolerans sınırı protokolün varsaydığı corrupt party sayısına göre ayrıca belirlenir. Bu nedenle t yalnızca matematiksel bir parametre değil, tehdit modelinin operasyonel ifadesidir.

Tarafların bağımsızlığı pratikte en çok gözden kaçan konulardan biridir. Üç taraf farklı makinelerde çalışıyor olabilir; fakat hepsi aynı bulut hesabında, aynı Kubernetes cluster’ında, aynı CI/CD pipeline’ında ve aynı yönetici grubu tarafından yönetiliyorsa gerçek güven dağılımı sınırlıdır. Bir içeriden tehdit veya merkezi yönetim hatası aynı anda birden fazla tarafı etkileyebilir.

Operasyonel riskler arasında taraf kaybı, pay kaybı, taraf başarısızlığı, network partition, timeout yönetimi ve güncelleme uyumsuzluğu yer alır. Bir tarafın payı kaybolursa sistem eşiğe bağlı olarak çalışmaya devam edebilir; fakat çok fazla pay kaybolursa sır veya imza yetkisi kalıcı olarak kullanılamaz hâle gelebilir. Bu problem için share recovery, backup, participant replacement veya resharing prosedürleri gerekir.

Share refresh farklı bir kavramdır. Share refresh, sırrın kendisini değiştirmeden payları yenileyerek zaman içinde biriken compromise riskini azaltır. Örneğin saldırgan geçen ay bir payı, bu ay başka bir payı ele geçirmişse ve paylar hiç yenilenmiyorsa zaman içinde eşiğe ulaşabilir. Share refresh protokolleri, aynı sır korunurken payları değiştirir ve eski payların yeni paylarla birleştirilerek sırra ulaşmasını engellemeyi hedefler. Pay kaybı sorununu çözmek için ise ayrıca recovery veya resharing mekanizmaları gerekir.

Akademik MPC protokolleri farklı varsayımlar altında analiz edilir. Bazıları dürüst çoğunluk veya senkron ağ isterken, bazıları dishonest majority, asynchronous network, malicious adversary veya adaptive corruption modellerini hedefler. Üretim değerlendirmesinde “bu protokol güvenli” cümlesi yeterli değildir; “hangi taraf sayısında, kaç corrupt party’ye kadar, hangi ağ varsayımında, abort durumunda ne garanti ediyor?” soruları sorulmalıdır.

Bir mimari değerlendirmede “threshold imza kullanalım” önerisi yalnızca kriptografik doğruluk sorusu değildir. Hangi protokol implementasyonu kullanılacak? Denetlenmiş mi? Taraflar gerçekten bağımsız mı? Pay yenileme prosedürü var mı? Taraf başarısızlığında imzalama nasıl devam edecek? Audit loglar hangi taraflarda tutulacak? Bu soruların yanıtı çoğu zaman algoritma seçiminden daha zor ve daha önemlidir.

MPC ve Eşik Kriptografi Araç Ekosistemi

Eşik kriptografi ve MPC araç ekosistemi hâlâ hızlı gelişen bir alandır. Bazı bileşenler üretim olgunluğuna yaklaşmış veya belirli sektörlerde ciddi şekilde kullanılmaya başlamış olsa da akademik prototip ile bağımsız denetimden geçmiş üretim bileşeni arasındaki mesafe hâlâ büyüktür. Bu nedenle araç seçimi, klasik bir yardımcı kütüphane seçimi gibi görülmemelidir.

Threshold imza servislerinin kullanım mantığı genellikle şu biçimdedir: her taraf bir istemci veya node çalıştırır; imzalama isteği geldiğinde taraflar protokol turlarını tamamlayarak nihai imzayı birlikte üretir. Bu servislerin bir bölümü doğrudan MPC protokol kütüphanesi üzerine kuruludur; bir bölümü ise daha üst seviye API, policy engine ve operasyon paneli sunar.

Araç kategorileri arasında araştırma amaçlı açık kaynak prototipler, ticari MPC kütüphaneleri, kripto varlık saklama servislerinin içine gömülü threshold imza modülleri ve standartlaşma sürecindeki referans implementasyonlar sayılabilir. Bu kategoriler arasında güvenlik analizi, denetim kalitesi, bakım aktifliği, protokol versiyonu ve olay müdahale kabiliyeti açısından ciddi farklar vardır.

Kurumsal kripto varlık saklamada threshold imzalar iki ana modelde karşımıza çıkar. Birincisi self-custody with MPC modelidir; kurum kendi taraflarını ve güven sınırlarını yönetir. İkincisi ise MPC hizmet sağlayıcısı modelidir; hizmet sağlayıcı tarafların bir bölümünü işletir veya imzalama akışının koordinasyonunu sağlar. İkinci modelde dağıtık güven kavramı, hizmet sağlayıcıya olan operasyonel ve hukuki bağımlılıkla birlikte değerlendirilmelidir.

Demo implementasyonlar protokolün kavramsal doğruluğunu göstermek için faydalıdır. Ancak güvenli bellek yönetimi, constant-time davranış, yan kanal dayanıklılığı, hata yönetimi, malicious taraflara karşı koruma ve production audit açısından yetersiz kalabilir. Üretim ortamına taşınacak bir threshold imza implementasyonu için protokolün güncel akademik analizle uyumlu olması, bağımsız kriptografik denetimden geçmiş olması, aktif bakım ekibine sahip olması, test vektörleri sunması ve sorumlu açıklama sürecinin bulunması gerekir.

Dağıtık güven sistemlerinde operasyonel izleme ayrıca tasarlanmalıdır. Hangi tarafın imzalama turuna katılıp katılmadığı, kaç başarılı ve başarısız imzalama oturumu gerçekleştiği, pay yenileme operasyonlarının zamanında tamamlanıp tamamlanmadığı, hangi taraflarda timeout görüldüğü ve anormal abort oranlarının olup olmadığı izlenmelidir. Geleneksel PKI’da HSM audit log bu izlemenin bir kısmını sağlar; MPC sistemlerinde ise çok taraflı ve korelasyonlu bir audit mekanizması gerekir.

Bir MPC veya eşik imza kütüphanesi değerlendirilirken ilk sorulması gereken soru şudur: Bu kütüphane hangi protokolü, hangi güven modelinde ve hangi adversary varsayımı altında uyguluyor? Dokümantasyonda protokol referansı, güven modeli, bağımsız denetim, sürüm uyumu ve known limitations açıkça yer almıyorsa üretim kullanımı için risk yüksektir.

Komut & Araç Okuryazarlığı

Eşik kriptografi ve MPC alanında araç okuryazarlığı iki katmana ayrılır: kavramsal protokol akışını anlama ve mevcut kütüphane/servis çıktılarını değerlendirme. Bu alanda OpenSSL veya Wireshark kadar oturmuş, tek tip bir standart araç ekosistemi henüz yoktur. Bu nedenle araç okuryazarlığı daha çok dokümantasyon okuma, güven modeli sorgulama, test vektörü kontrolü ve denetim çıktısı yorumlama şeklinde gelişir.

Basit Shamir Pay Hesaplamasını Doğrulama

Eğitim ortamında Python üzerinde küçük ve sentetik bir Shamir SSS betiği kullanılabilir. Buradaki amaç üretim anahtarı paylaşımı yapmak değil, (t,n) eşik mantığını kavramaktır.

Bir (t,n) Shamir paylaşım testinde beklenen davranış şudur: t pay Lagrange interpolasyonu ile orijinal sırrı üretir. t−1 veya daha az payla reconstruction yapılmamalı ya da kütüphane hata vermelidir. Eğer basit bir betik eksik payla bir değer döndürüyorsa, bu değer güvenlik kanıtı veya anlamlı reconstruction sonucu olarak yorumlanmamalıdır. Bu yalnızca yanlış sayıda noktayla bir polinom uydurma denemesidir.

Öğrenci çıktıda başlangıç sırrıyla reconstruction sonucunun eşleşip eşleşmediğine, kullanılan sonlu alan modülünün doğru seçilip seçilmediğine ve pay indekslerinin benzersiz olup olmadığına bakmalıdır. Aynı x koordinatına sahip iki pay kullanmak interpolasyonu bozar. Pay indekslerinin sıfır olmaması da önemlidir; çünkü f(0) zaten sırdır ve bir katılımcıya doğrudan verilmemelidir.

Bu tür testler protokolü kavramsal düzeyde anlamak için değerlidir. Ancak testin doğru çıktı vermesi, kütüphanenin yan kanal dayanıklılığı, güvenli bellek yönetimi, malicious dealer davranışı veya üretim güvenliği hakkında garanti vermez. Üretim kullanımı için ayrı protokol analizi ve bağımsız denetim gerekir.

Threshold İmza Kütüphanesi Dokümantasyonu ve Güven Modeli Okuması

Bir threshold ECDSA, threshold Schnorr/FROST veya BLS kütüphanesi değerlendirildiğinde ilk olarak dokümantasyonda protokol referansı aranmalıdır. Kütüphane hangi akademik çalışmaya, hangi RFC’ye veya hangi teknik spesifikasyona dayanıyor? Uygulanan sürüm hangi güvenlik modelini hedefliyor? Semi-honest mi, malicious secure mı, adaptive corruption’a karşı iddiası var mı?

İkinci adım bağımsız denetim geçmişini okumaktır. “Security audit” başlığı varsa, denetimi kimin yaptığı, hangi tarihte yaptığı, hangi commit veya sürümü kapsadığı, hangi bulguların açık kaldığı ve düzeltmelerin doğrulanıp doğrulanmadığı incelenmelidir. Eski bir denetim, güncel protokol veya güncel kod sürümünü kapsamıyor olabilir.

Üçüncü adım bakım aktifliğidir. Son commit tarihi, issue yanıtları, güvenlik duyuruları, test vektörleri, CI süreçleri ve sürüm notları incelenmelidir. Açık kaynak olması tek başına güvenlik anlamına gelmez. Kaynak kodun görünür olması, bağımsız kriptografik analizin yerini tutmaz.

Dokümantasyonda pay yenileme, participant replacement, identifiable abort, timeout yönetimi, secure channel gereksinimi ve audit logging gibi operasyonel başlıklar yoksa kütüphane yalnızca kriptografik çekirdeği sunuyor olabilir. Bu durumda üretim sistemi için ek mimari katman gerekir.

İleri Seviye Güvenli Analiz / Kontrol Listesi

Eşik kriptografi ve MPC sistemlerini değerlendirirken önce tehdit modeli netleştirilmelidir. Kaç tarafın tehlikeye girebileceği, tarafların birbirinden gerçekten bağımsız olup olmadığı, aynı kuruluş içindeki farklı ekiplerin gerçek bağımsızlık sağlayıp sağlamadığı ve hangi operasyonel senaryolarda imzalama veya hesaplama yapılacağı bu analizin girdisini oluşturur.

Şema seçimi kullanım amacına göre yapılmalıdır. Sır yalnızca yedeklenmek mi isteniyor, yoksa sır hiçbir zaman reconstruct edilmeden imzalama mı yapılacak? Basit SSS mi yeterli, yoksa VSS veya DKG mi gerekiyor? Threshold ECDSA mı, FROST/Schnorr mu, BLS mi daha uygun? Bu kararlar mevcut doğrulama ekosistemi, blockchain/protokol uyumluluğu, performans ve güven modeliyle birlikte verilmelidir.

Eşik parametresi tehdit modeliyle uyumlu olmalıdır. (t,n) sisteminde t−1 veya daha az payın ele geçirilmesine karşı gizlilik korunur; t veya daha fazla pay ele geçirilirse sır veya imza yetkisi riske girer. Diğer yandan t çok yüksek seçilirse erişilebilirlik düşer ve taraf başarısızlıkları sistemi kilitleyebilir.

Dealer güveni ayrıca kontrol edilmelidir. İlk anahtar üretimi merkezi dealer üzerinden mi yapılıyor? Dealer’ın tüm sırrı gördüğü bir model mi var? DKG kullanılıyorsa hangi protokol uygulanıyor? DKG’nin VSS ve complaint mekanizmaları nasıl çalışıyor? Bu sorular merkezi güveni anlamak için kritiktir.

Reconstruction noktası dikkatle incelenmelidir. Eğer sistem Shamir paylarını yalnızca backup için kullanıyorsa reconstruction sırasında sır tek noktada oluşabilir. Bu durumda o noktanın güvenliği ayrıca tasarlanmalıdır. Eğer sistem threshold imza kullanıyorsa özel anahtar reconstruct edilmeden imza üretildiği doğrulanmalıdır.

Pay yenileme prosedürü belgelenmelidir. Share refresh, sırrı değiştirmeden payları yenileyerek zaman içinde biriken compromise riskini azaltır. Pay kaybı için ise share recovery, backup, participant replacement veya resharing prosedürleri ayrıca gerekir. Bu ayrımlar operasyon dokümanında net değilse olay anında ciddi karışıklık yaşanabilir.

Taraf başarısızlığı senaryoları test edilmelidir. Bir taraf yanıt vermezse süreç nasıl ilerliyor? t taraf bulunabildiği sürece imzalama tamamlanıyor mu? Timeout, retry ve abort davranışı nasıl? Kötü niyetli taraf yanlış mesaj gönderdiğinde kimlik tespiti yapılabiliyor mu? Bu sorular yalnızca kriptografik protokolün değil, üretim sisteminin güvenliğinin parçasıdır.

İletişim kanalları kimlik doğrulamalı ve şifreli olmalıdır. MPC protokol mesajları çoğu zaman hassas ara değerler, commitment’lar veya imza payları içerir. Bu mesajların değiştirilmesi veya replay edilmesi protokolün güvenliğini etkileyebilir. Bu nedenle taraflar arası iletişimde mutual authentication, replay koruması ve güvenilir transport katmanı gerekir.

Protokol implementasyonu bağımsız denetimden geçmiş olmalıdır. Denetim belgesi mevcut, güncel ve ilgili sürümü kapsıyor olmalıdır. Test vektörleri varsa referans implementasyonla karşılaştırma yapılmalıdır. Güvenlik modeli, kullanılan eğri/grup, random oracle varsayımı, malicious tolerans seviyesi ve known limitations açıkça belgelenmelidir.

Operasyonel izleme çıktılarında anormal imzalama oturumu başarısızlığı, beklenmedik taraf yanıtsızlığı, pay doğrulama hatası, sık abort, beklenmeyen coordinator değişimi veya pay yenileme başarısızlığı olası saldırı ya da yapılandırma sorununa işaret edebilir. Bu gözlemler audit log üzerinden izlenebilir hâle getirilmelidir.

“Threshold imza kullanıyoruz, dolayısıyla özel anahtar güvende” ifadesi tek başına yeterli değildir. Eşik imzanın güvenliği güven modelinin doğru kurgulanmasına, uygun implementasyon seçimine, operasyonel pay yönetimine, taraf bağımsızlığına ve iletişim güvenliğine bağlıdır. Bu bileşenlerden herhangi birinin zayıflığı kriptografik garantiyi pratikte boşa çıkarabilir.

Bir threshold imza sistemi değerlendirildiğinde mimari ekibe şu başlıklar sade biçimde aktarılmalıdır: kullanılan protokol ve güven modeli, bağımsız denetim durumu, taraf bağımsızlığının gerçekte nasıl sağlandığı, pay yenileme ve recovery prosedürü, taraf başarısızlığı senaryosu, iletişim güvenliği ve operasyonel izleme mekanizması.

Analitik Senaryo

Durum

TEST-APP01 üzerinde çalışan bir demo dijital varlık saklama sistemi, threshold ECDSA tabanlı imzalama kullanacak şekilde yapılandırılmıştır. Sistem, (2,3) eşik parametresiyle üç taraf arasında dağıtılmış özel anahtar payları kullanmaktadır. Güvenlik mühendisi security_engineer, sistem tasarımını incelemek üzere görevlendirilmiştir.

İlk Yorum

(2,3) eşik yapısı teorik olarak üç taraftan herhangi ikisinin katılımıyla imzalamaya izin verir. Bir tarafın payının kaybı ya da geçici olarak çevrimdışı kalması sistemi hemen kullanılamaz hâle getirmez. Tek bir payın ele geçirilmesi de tek başına imza yetkisi vermez. Ancak bu matematiksel özelliklerin pratik güvenliğe dönüşebilmesi için tarafların gerçekten ayrı güven sınırlarında bulunması gerekir.

İlk sorular şunlardır: Bu üç taraf gerçekten birbirinden bağımsız mı? Aynı kuruluşun farklı departmanları mı, farklı kuruluşlar mı, yoksa aynı bulut hesabında çalışan üç servis mi? Aynı CI/CD hattından dağıtılıyorlar mı? Aynı yönetici kimlikleriyle erişiliyorlar mı? Eğer iki taraf aynı güvenlik sınırında bulunuyorsa (2,3) eşiği matematiksel olarak doğru olsa bile pratik güven dağılımı zayıflar.

Kontrol Edilecek Noktalar

İlk olarak anahtar üretim süreci incelenmelidir. Paylar merkezi bir dealer tarafından mı üretilmiş, yoksa DKG protokolü mü kullanılmış? Dealer kullanıldıysa dealer tüm özel anahtarı üretim anında gördü mü? Dealer’ın güvenliği nasıl sağlandı ve üretim sonrası sır gerçekten imha edildi mi? DKG kullanıldıysa hangi protokol versiyonu uygulandı ve bu protokol hangi güvenlik modeline dayanıyor?

Ardından threshold ECDSA implementasyonu incelenmelidir. Hangi akademik protokole dayanıyor? Semi-honest mı, malicious model mi hedefleniyor? Nonce üretimi nasıl yapılıyor? İmza payları doğrulanıyor mu? Kötü niyetli taraf yanlış mesaj gönderirse tespit edilebiliyor mu? Identifiable abort desteği var mı?

İletişim güvenliği ayrıca kontrol edilmelidir. Taraflar arasındaki MPC mesajlaşması şifreli ve kimlik doğrulamalı mı? Mesajlar replay’e karşı korunuyor mu? Taraflar birbirlerinin kimliğini sertifika, mTLS, imza anahtarı veya başka güvenilir mekanizmayla doğruluyor mu? Protokol mesajlarının plaintext veya kimlik doğrulamasız taşınması, doğru threshold protokol seçilmiş olsa bile güvenliği zayıflatabilir.

Pay saklama ve erişim kontrolleri incelenmelidir. Her pay farklı güvenlik sınırında mı saklanıyor? Paylar HSM, KMS, secure enclave veya güçlü erişim politikalarıyla korunuyor mu? Aynı root kullanıcı, aynı cloud IAM rolü veya aynı deployment secret’ı iki paya erişebiliyor mu? Bu tür ortak erişim noktaları eşiği pratikte düşürür.

İncelenecek Çıktı ve Yapılandırma

Kütüphane dokümantasyonunda protokol referansı, güvenlik modeli, denetim belgesi, test vektörleri ve sürüm notları aranır. Bağımsız denetimin hangi sürümü kapsadığı özellikle kontrol edilir. Denetim belgesi eski bir commit’e aitse güncel kod için doğrudan güvence sağlamaz.

Pay yenileme ve recovery prosedürünü anlatan operasyonel doküman incelenir. Periyodik share refresh planı var mı? Bir taraf kalıcı olarak kaybolursa participant replacement nasıl yapılacak? Pay yedekleri nerede tutuluyor? Backup mekanizması eşiği dolaylı olarak düşürüyor mu?

Audit ve izleme tarafında başarılı imza oturumları, başarısız imza oturumları, taraf timeout’ları, abort olayları ve pay yenileme işlemleri izlenebiliyor mu kontrol edilir. Bir taraf olağan dışı sıklıkta imzalama isteğine katılıyorsa veya belirli saatlerde beklenmedik abort üretiyorsa bu durum güvenlik sinyali olabilir.

Güvenli Doğrulama Yaklaşımı

Tüm tarafların gerçekten ayrı güven sınırlarında konumlandırıldığı doğrulanmalıdır. Bu ayrım yalnızca farklı makinelerde çalışmak anlamına gelmez; kimlik yönetimi, ağ ayrımı, yönetici yetkileri, deployment pipeline, log erişimi ve fiziksel/kurumsal kontrol de ayrıştırılmalıdır.

İletişim kanalları kimlik doğrulamalı ve şifreli olmalıdır. MPC turlarındaki mesajlar, protokolün varsaydığı sıradan mesajlar gibi değil, kriptografik state’in parçası olarak değerlendirilmelidir. Bu nedenle mesaj bütünlüğü, replay koruması ve taraf kimliği doğrulaması şarttır.

Kütüphane bağımsız denetimden geçmiş olmalı, denetim güncel sürümü kapsamalı ve güvenlik modeli açıkça belirtilmelidir. Demo kütüphane, akademik prototip veya uzun süredir bakımı yapılmayan repository üretim ortamında kullanılmamalıdır.

Pay yenileme prosedürü ve taraf başarısızlığı senaryoları yalnızca belgelenmiş olmamalı, test ortamında düzenli olarak denenmelidir. Gerçek olay anında hangi tarafların katılacağı, hangi yetkilendirme adımlarının gerekeceği ve recovery sürecinin ne kadar süreceği önceden bilinmelidir.

Yanlış Yorumlama İhtimali

Demo ortamında “çalışıyor” gözlemi üretim güvenliği anlamına gelmez. Özellikle demo kütüphanelerde güvenli bellek temizleme, constant-time davranış, malicious taraflara karşı koruma, hata yönetimi veya audit altyapısı eksik olabilir. Testlerin geçmesi, kriptografik denetim yapıldığı anlamına gelmez.

(2,3) eşik kullanmak tek başına dağıtık güven sağlamaz. Eğer iki taraf aynı güvenlik sınırındaysa, aynı kimlik altyapısıyla yönetiliyorsa veya aynı saldırgan tarafından birlikte ele geçirilebiliyorsa eşik parametresi pratikte beklenen korumayı sağlamaz.

“Özel anahtar hiçbir zaman oluşmuyor” ifadesi de dikkatli yorumlanmalıdır. Doğru threshold signing protokolünde özel anahtar reconstruct edilmez; fakat protokol payları, nonce payları, ara değerler ve imza payları yine hassastır. Bu değerlerin loglanması, bellekte gereksiz kalması veya yanlış iletilmesi güvenliği zayıflatabilir.

Riskin Pratik Karşılığı

Eğer üç taraftan ikisi aynı kuruluşun aynı güvenlik sınırında bulunuyorsa, bir içeriden tehdit veya merkezi yönetim hesabı iki paya birden erişebilir. Bu durumda (2,3) eşik matematiksel olarak doğru olsa bile pratikte tek bir organizasyonel hata imza yetkisi doğurabilir.

Eğer threshold ECDSA implementasyonu nonce üretimini doğru yönetmiyorsa, ECDSA’nın klasik nonce riskleri dağıtık bağlamda yeniden ortaya çıkabilir. Kötü tasarlanmış nonce payları veya malicious taraf davranışı private key payları hakkında bilgi sızdırabilir.

Eğer pay yenileme yapılmıyorsa, saldırgan zaman içinde farklı taraflardan paylar toplayarak eşiğe ulaşabilir. Farklı dönemlerde sızmış eski payların birleşmesi, share refresh yapılmayan sistemlerde ciddi bir uzun vadeli risktir.

Önerilen Güvenli Yaklaşım

Taraflar gerçek anlamda ayrışık güven sınırlarında konumlandırılmalıdır. Mümkünse farklı yönetim hesapları, farklı ağ segmentleri, farklı operasyon ekipleri ve farklı erişim politikaları kullanılmalıdır. Aynı kuruluş içinde kalınacaksa bile görev ayrımı ve erişim ayrımı güçlü biçimde tasarlanmalıdır.

Threshold ECDSA için bağımsız denetimden geçmiş, aktif bakımı süren ve malicious model desteği açıkça belgelenmiş bir implementasyon tercih edilmelidir. Mümkün olan protokol bağlamlarında threshold Schnorr/FROST veya threshold BLS gibi daha doğal threshold yapıları değerlendirilmelidir; ancak mevcut ekosistem uyumluluğu kararın temel girdisi olmalıdır.

Pay yenileme, recovery ve participant replacement prosedürleri üretim öncesinde belgelenmeli ve test edilmelidir. Audit loglar, imzalama oturumları ve abort olayları merkezi olarak izlenmeli; ancak bu loglar hassas pay veya ara protokol değerleri içermemelidir.

Bu değerlendirme mimari ekibe şu dille aktarılabilir:

“(2,3) threshold ECDSA yapısı tek bir private key dosyasının ele geçirilmesi riskini azaltır; ancak üretim güvenliği tarafların gerçek bağımsızlığına, denetlenmiş implementasyona, güvenli iletişim kanallarına, pay yenileme prosedürüne ve operasyonel izlemeye bağlıdır. Demo sistemin çalışması, bu güvenlik koşullarının sağlandığını göstermez.”

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

Secret Sharing Gizli paylaşım; bir sırrı birden fazla paya bölüştürme yöntemi.

Threshold Eşik; sırrı yeniden elde etmek veya threshold işlem yapmak için gereken minimum taraf/pay sayısı.

(t,n) threshold Toplam n paydan herhangi t payın reconstruction veya işlem için yeterli olduğu eşik yapısı.

Shamir’s Secret Sharing (SSS) Shamir’in Gizli Paylaşım Şeması; t−1 dereceli polinom ve Lagrange interpolasyonuna dayalı gizli paylaşım.

Reconstruction Yeniden inşa; yeterli sayıda payla sırrın geri elde edilmesi.

Lagrange interpolation Polinom interpolasyonu yöntemi; Shamir SSS’de t paydan sabit terimi, yani sırrı, geri elde etmek için kullanılır.

Dealer Sırrı başlangıçta bölüp payları dağıtan taraf.

VSS Verifiable Secret Sharing; katılımcıların aldıkları payların tutarlılığını doğrulayabildiği gizli paylaşım yapısı.

Feldman VSS Public commitment’lar ile Shamir paylarının doğrulanmasını sağlayan VSS türü.

Pedersen VSS Ek rastgelelik ve Pedersen commitment kullanarak bilgi-teorik gizlilik sağlayan VSS yaklaşımı.

Commitment Bir değere bağlanmayı sağlayan, bazı yapılarda değeri gizleyen kriptografik taahhüt.

Perfect hiding Taahhüdün saklanan değer hakkında bilgi-teorik olarak bilgi sızdırmaması.

Computational binding Taahhüdün farklı bir değere açılmasının hesaplama açısından zor olması.

DKG Distributed Key Generation; merkezi dealer olmadan tarafların birlikte anahtar payları üretmesi.

Share refresh Sırrı değiştirmeden payların yenilenmesi; zaman içinde biriken compromise riskini azaltır.

Resharing Pay yapısının veya katılımcı kümesinin değiştirilmesi; participant replacement ile birlikte kullanılabilir.

Participant replacement Bir tarafın sistemden çıkarılıp yeni tarafın eklenmesi süreci.

Threshold ECDSA ECDSA imzasının özel anahtar reconstruct edilmeden paylarla üretildiği eşik imza yapısı.

Threshold Schnorr Schnorr imzasının threshold sayıda tarafla üretildiği imza yapısı.

FROST Flexible Round-Optimized Schnorr Threshold; iki turlu threshold Schnorr imza protokolü.

Threshold EdDSA EdDSA/Schnorr-benzeri imzaların threshold biçimde üretilmesi için kullanılan yaklaşım ailesi.

BLS Threshold Signature Aynı shared secret key’in paylarıyla üretilen BLS signature share’lerinin Lagrange interpolasyonu ile tek imzaya dönüştürüldüğü yapı.

BLS Aggregate Signature Farklı public key’lere ait imzaların tek aggregate imzada birleştirilmesi. Threshold BLS ile aynı şey değildir.

Signature share Threshold imza protokolünde bir tarafın kendi payıyla ürettiği imza katkısı.

Signature aggregation Birden fazla imzanın tek bir doğrulanabilir imza yapısında birleştirilmesi.

Rogue-key attack Aggregate/multisignature sistemlerinde kötü niyetli public key seçimiyle doğrulamayı yanıltmaya çalışan saldırı sınıfı.

Proof of possession Public key sahibinin ilgili private key’e sahip olduğunu kanıtlaması; rogue-key riskini azaltmak için kullanılır.

MPC Multi-Party Computation; tarafların girdilerini açıklamadan ortak bir fonksiyonu hesaplamasını sağlayan protokol alanı.

Honest-but-curious model Tarafların protokolü izlediği ancak gördüklerinden ek bilgi çıkarmaya çalıştığı model.

Malicious model Tarafların protokolden sapabildiği, sahte mesaj gönderebildiği ve aktif saldırı yapabildiği model.

Honest majority Tarafların çoğunluğunun dürüst olduğu varsayımı.

Dishonest majority Saldırganın tarafların çoğunluğunu kontrol edebileceği daha zor güvenlik modeli.

Adaptive corruption Saldırganın protokol sürecinde hangi tarafları bozacağını dinamik olarak seçebilmesi.

Fairness Taraflardan birinin sonucu öğrenirken diğerinin öğrenememesi gibi dengesizlikleri engelleme hedefi.

Garbled Circuit Yao’nun iki taraflı güvenli hesaplama yapısı; fonksiyon mantık devresi olarak karıştırılmış biçimde değerlendirilir.

Oblivious Transfer (OT) Alıcının seçtiği veriyi aldığı, gönderenin seçimi bilmediği ve alıcının diğer verileri öğrenmediği temel MPC yapı taşı.

Private Set Intersection (PSI) İki tarafın veri kümelerinin kesişimini ham verileri açıklamadan hesaplamasını sağlayan MPC uygulaması.

Custody Kripto varlık saklama; özel anahtar veya imza yetkisinin güvenli yönetilmesi süreci.

DVT Distributed Validator Technology; validator anahtarının ve imzalama yetkisinin dağıtık biçimde yönetildiği mimari yaklaşım.

Security Audit Report Bağımsız güvenlik denetimi raporu; bir implementasyonun belirli kapsamda incelendiğini gösterir, mutlak güvenlik kanıtı değildir.

Identifiable abort Protokolü bozan veya hatalı mesaj gönderen tarafın tespit edilebildiği abort mekanizması.

Coordinator Threshold/MPC protokollerinde turları yöneten veya mesajları düzenleyen bileşen; güven modeli içinde ayrıca değerlendirilmelidir.

Kendini Değerlendir — İleri Kriptografi Modül 8

Bu Modülde Neler Öğrendik?

Bu modül, eşik kriptografisini, özel anahtarın hiçbir noktada tam olarak oluşmaması fikrini ve dağıtık güven kavramını güvenlik modeli, operasyonel gerçeklik ve araç ekosistemi açısından birlikte ele aldı.

Shamir SSS’nin matematiksel güvencesini, polinom interpolasyonunun eşik mantığına nasıl dönüştüğünü ve (t,n) notasyonunun doğru kullanımını öğrendik. Bu notasyonda t pay reconstruction için yeterlidir; t−1 veya daha az pay ise sır hakkında bilgi-teorik anlamda bilgi vermez. Polinom derecesi t−1 olarak seçilir.

Feldman ve Pedersen VSS yapılarının neden gerekli olduğunu ve katılımcıların aldıkları payları doğrulayabilmesinin dağıtık güven modeline ne kattığını gördük. Feldman VSS’nin doğrulanabilirlik sağladığını, Pedersen VSS’nin bilgi-teorik gizlilik ve hesaplamalı bağlayıcılık ayrımıyla daha güçlü gizlilik profili sunduğunu netleştirdik.

Threshold ECDSA, threshold EdDSA/Schnorr ve BLS threshold imza şemalarının çalışma mantığını tek taraflı imzalamayla karşılaştırmalı olarak analiz ettik. Threshold ECDSA’nın k^{-1}(H(m)+r·d) yapısı nedeniyle karmaşık MPC protokolü gerektirdiğini; FROST gibi threshold Schnorr protokollerinin nonce commitment ve binding factor gibi mekanizmalarla daha doğal bir yapı sunduğunu gördük.

BLS tarafında threshold signature ile aggregate signature arasındaki farkı ayırdık. Threshold BLS, aynı shared key’in paylarıyla signature share üretip bunları tek imzaya dönüştürür. BLS aggregation ise farklı public key’lere ait imzaların tek aggregate imzada birleştirilmesidir. Ethereum proof-of-stake bağlamında BLS aggregation kullanımı ile DVT/threshold validator yaklaşımlarını karıştırmamak gerektiğini öğrendik.

MPC’yi honest-but-curious ve malicious model çerçevesinde konumlandırdık; ayrıca dürüst çoğunluk, dishonest majority, adaptive corruption, fairness ve ağ modeli gibi ek eksenlerin güvenliği belirlediğini gördük. Garbled circuit ve oblivious transfer kavramlarını saldırı yüzeyiyle birlikte okuyabildik.

Akademik modelin üretim gerçekliğinden hangi noktalarda ayrıştığını açıkça gördük: taraf başarısızlığı, ağ kesintisi, aynı güvenlik sınırında çalışan taraflar, içeriden tehdit, pay kaybı, audit eksikliği ve bakım görmeyen kütüphaneler. Threshold imza kullanmak, bu riskleri otomatik olarak ortadan kaldırmaz; yalnızca özel anahtarın tek noktada bulunması riskini azaltır.

Share refresh’in temel amacının kayıp payı çözmek değil, sırrı değiştirmeden payları yenileyerek zaman içinde biriken compromise riskini azaltmak olduğunu öğrendik. Pay kaybı için recovery, resharing, backup veya participant replacement gibi ayrı operasyonel mekanizmalar gerekir.

Eşik kriptografi ve MPC araç ekosistemini olgunluk, denetlenebilirlik ve bakım aktifliği kriterlerine göre değerlendirebildik. Demo implementasyon ile bağımsız denetimden geçmiş üretim bileşeni arasındaki farkı somutlaştırdık.

Son olarak bu modülde edindiğimiz en değerli becerilerden biri mimari önerileri doğru çerçeveleyebilmektir. “Threshold imza kullanıyoruz” ifadesinin tek başına yeterli olmadığını; güven modeli kurgusu, taraf bağımsızlığı, pay yenileme prosedürü, iletişim güvenliği, operasyonel izleme ve bağımsız denetim gibi bileşenlerin birlikte değerlendirilmesi gerektiğini açık ve sade biçimde aktarabiliyoruz.

MODÜL 9 — Post-kuantum kriptografi ve geçiş stratejileri

Modül özeti

Kuantum tehdidini problem türlerine ayırır; NIST PQC ilk standartlarını, hibrit tasarım dilini ve kurumsal envanter + geçiş önceliklendirmesini bir arada okutur.

Modül 9 — Post-Kuantum Kriptografi ve Geçiş Stratejileri

Kriptografi tarihinin en kapsamlı paradigma değişimlerinden biri artık yalnızca akademik bir tartışma olmaktan çıktı. Post-kuantum kriptografi, yani PQC, uzun yıllar teorik araştırmaların konusu olarak görülürken NIST’in 2024 yılında ML-KEM, ML-DSA ve SLH-DSA standartlarını resmileştirmesiyle birlikte kurumsal güvenlik planlamasının doğrudan parçası hâline geldi. NIST, FIPS 203 ile ML-KEM’i, FIPS 204 ile ML-DSA’yı ve FIPS 205 ile SLH-DSA’yı 13 Ağustos 2024’te yayımladı; ayrıca FALCON tabanlı FN-DSA’nın FIPS 206 olarak geliştirme süreci devam etmektedir.

Bu modül, öğrencinin “kuantum bilgisayarlar RSA’yı kıracak” düzeyindeki genel bilgiden çıkıp tehdidin gerçek kriptografik boyutunu, standartlaşma sürecinin mimarisini, hibrit geçiş tasarımlarını ve kurumsal ortamda ne zaman, neyin, nasıl değiştirilmesi gerektiğini analiz edebileceği bir seviyeye ulaşmasını hedefler.

Modül boyunca Shor algoritmasının asimetrik kriptografiyi neden doğrudan etkilediği, Grover algoritmasının ise simetrik kriptografi ve hash fonksiyonları üzerinde neden daha sınırlı ama yine de dikkate alınması gereken bir etki oluşturduğu incelenir. Bu ayrım geçiş planlamasının merkezindedir. RSA, klasik Diffie-Hellman ve ECC gibi çarpanlara ayırma veya ayrık logaritma problemlerine dayanan yapılar kuantum tehdidinden kökten etkilenirken, AES ve SHA-2 gibi simetrik/hash tabanlı yapılar genellikle parametre değerlendirmesiyle daha yönetilebilir bir risk profiline sahiptir.

Post-kuantum kriptografi aileleri; kafes tabanlı, kod tabanlı, hash tabanlı, çok değişkenli ve izogeni tabanlı yaklaşımlar üzerinden ele alınır. Bu ailelerin güvenlik varsayımları, anahtar boyutları, imza veya ciphertext boyutları, performans etkileri ve standartlaşma durumları birbirinden farklıdır. NIST’in 2025 yılında HQC’yi ML-KEM’e yedek/çeşitlilik sağlayacak kod tabanlı KEM olarak standartlaştırmak üzere seçmesi, bu alandaki güncelliğin hâlâ devam ettiğini gösterir.

Modülün önemli bir bölümü hibrit geçiş mimarilerine ayrılır. Hibrit anahtar anlaşması, klasik ve post-kuantum bileşenlerden elde edilen sırları güvenli bir KDF ile birleştirerek geçiş döneminde daha dengeli bir güvenlik profili hedefler. Buradaki doğru güvenlik sezgisi şudur: bileşenlerden en az biri güvenli kaldığı sürece nihai oturum sırrının güvenli kalması hedeflenir. Bu nedenle hibrit tasarımda KDF, transcript bağlama ve domain separation ayrıntıları kritik önemdedir.

Özellikle “harvest-now-decrypt-later” tehdidi, uzun ömürlü veriler için PQC geçişini teorik bir gelecek problemi olmaktan çıkarır. Bugün kaydedilen şifreli trafik veya arşivlenmiş veri, gelecekte kriptografik olarak anlamlı kuantum bilgisayarlar ortaya çıktığında çözülebilir. Bu durum sağlık, finans, devlet, savunma, kritik altyapı ve uzun süre gizli kalması gereken ticari sırlar açısından bugünden planlama yapılmasını gerektirir.

Modülün sonunda öğrenci, kurumsal kriptografik envanter çıkarma, geçiş önceliklerini güvenlik modeliyle ilişkilendirme, hibrit geçişin teknik gerekçesini açıklama, OQS/liboqs gibi araçların üretim dışı test ve prototipleme bağlamındaki rolünü anlama ve PQC geçişini geliştirici, güvenlik ve mimari ekiplerle doğru dille tartışabilme yetkinliği kazanır.

Kazanımlar

Bu modül sonunda öğrenci:

Shor algoritmasının RSA, klasik Diffie-Hellman ve ECC üzerindeki etkisini; Grover algoritmasının ise simetrik şifreleme ve hash fonksiyonlarına olan daha sınırlı etkisini güvenlik modeli düzeyinde açıklayabilir.

Preimage direnci ile collision direncini ayırt ederek hash fonksiyonlarının kuantum saldırgan modelindeki durumunu daha doğru yorumlayabilir.

Kafes tabanlı, kod tabanlı, hash tabanlı, çok değişkenli ve izogeni tabanlı PQC ailelerini anahtar boyutu, imza/ciphertext boyutu, performans ve güvenlik varsayımı açısından karşılaştırabilir.

ML-KEM, ML-DSA ve SLH-DSA standartlarının kapsamını, eski CRYSTALS-Kyber, CRYSTALS-Dilithium ve SPHINCS+ adlarıyla ilişkisini ve hangi kullanım senaryolarına karşılık geldiğini açıklayabilir.

HQC’nin kod tabanlı bir KEM olarak NIST tarafından 2025’te standartlaştırma sürecine seçildiğini ve FN-DSA/FIPS 206 sürecinin FALCON tabanlı ek imza standardı olarak devam ettiğini güncel standartlaşma bağlamında konumlandırabilir.

KEM ile dijital imza işlevini birbirinden ayırabilir; ML-KEM’in anahtar kapsülleme, ML-DSA ve SLH-DSA’nın ise dijital imza için kullanıldığını ifade edebilir.

Hibrit anahtar anlaşmasının güvenlik mantığını, klasik ve post-kuantum bileşenlerin KDF ile nasıl birleştirildiğini ve bileşenlerden en az biri güvenli kaldığında birleşik sır için güvenlik hedeflendiğini açıklayabilir.

Harvest-now-decrypt-later tehdidini uzun ömürlü veri sahipleri için geçiş önceliğiyle ilişkilendirebilir.

Kurumsal bir PQC geçiş planının kriptografik envanter, risk sınıflandırması, veri gizlilik ömrü, algoritma çevikliği, uyumluluk takibi, performans testi ve tedarikçi desteği gibi bileşenlerden oluştuğunu açıklayabilir.

OQS/liboqs ve OQS OpenSSL Provider araçlarının araştırma, eğitim, prototipleme ve geçiş testi için kullanılabileceğini; ancak üretim güvenliği kanıtı olarak yorumlanmaması gerektiğini değerlendirebilir. OQS projesi, liboqs ve uygulama entegrasyonlarına üretim ortamında veya hassas veriyi korumak için güvenilmesini önermediğini açıkça belirtir.

PQC algoritmalarının test vektörü çıktıları, benchmark sonuçları, anahtar/ciphertext/imza boyutları ve standart belgelerindeki gereksinimleri ileri seviyede okuyabilir.

Bir kurumun TLS altyapısı, VPN sistemleri, PKI yapısı, yazılım imzalama zinciri, veri arşivleri ve anahtar sarmalama mekanizmalarını PQC geçişi açısından farklı risk profilleriyle sınıflandırabilir.

Crypto agility kavramını PQC geçişiyle ilişkilendirerek algoritma değişiminin mimari, protokol, depolama, sertifika, tedarik zinciri ve operasyon tarafındaki etkilerini teknik ekibe aktarabilir.

Kuantum Tehdidi

Kuantum bilgisayarların kriptografiye etkisini anlamak için tehdidi tek bir cümleye indirgememek gerekir. “Kuantum bilgisayarlar tüm kriptografiyi kıracak” ifadesi hem fazla geniştir hem de teknik olarak yanlıştır. Gerçek etki, kullanılan kriptografik problemin türüne bağlıdır. Shor algoritması ile Grover algoritması farklı risk sınıfları oluşturur.

Shor algoritması, yeterli ölçekte ve hata düzeltmeli kuantum bilgisayar üzerinde büyük tam sayı çarpanlara ayırma ve ayrık logaritma problemlerini polinom zamanda çözebilir. Bu, RSA’nın dayandığı çarpanlara ayırma problemini, klasik Diffie-Hellman’ın dayandığı sonlu alan ayrık logaritma problemini ve ECC’nin dayandığı eliptik eğri ayrık logaritma problemini doğrudan etkiler. Bu nedenle RSA-2048, klasik DH ve P-256 gibi ECC tabanlı yapıların uzun vadeli kuantum güvenliği yoktur.

Forward secrecy bu noktada dikkatli yorumlanmalıdır. Bugünkü klasik ECDHE tabanlı TLS oturumları, klasik saldırgan modelinde geçmiş trafiği uzun vadeli sunucu anahtarı sızıntısına karşı korur. Ancak pasif saldırgan bugün ECDHE key exchange mesajlarını ve şifreli trafiği kaydederse, gelecekte yeterli kuantum kapasiteye ulaştığında klasik ECDH problemini çözmeyi deneyebilir. Bu nedenle forward secrecy, harvest-now-decrypt-later tehdidine karşı tek başına post-kuantum koruma sağlamaz.

Grover algoritması ise simetrik kriptografiyi aynı biçimde kökten yıkmaz. Grover, yapılandırılmamış aramada karekök hızlanma sağlar. Basitleştirilmiş güvenlik sezgisiyle, k-bit simetrik anahtar arama maliyeti yaklaşık k/2-bit seviyesine iner. Bu nedenle uzun vadeli ve yüksek güvenlik gerektiren sistemlerde AES-256 tercih etmek daha muhafazakâr bir yaklaşımdır. Buna rağmen AES-128’in bugün genel olarak güvensiz ilan edilmesi doğru değildir; NIST’in PQC geçiş rehberliği de mevcut uygulamaların AES-128, AES-192 ve AES-256 kullanmaya devam edebileceğini, simetrik algoritmalar için gelecekte ihtiyaç olursa ayrıca rehberlik yayımlanacağını belirtir.

Hash fonksiyonlarında kuantum etkisi kullanım amacına göre ayrılmalıdır. 256-bit hash çıktısı için preimage direnci Grover mantığıyla yaklaşık 128-bit seviyesine iner. Ancak collision direnci farklıdır: 256-bit çıktılı bir hash fonksiyonunda klasik birthday bound nedeniyle collision direnci zaten yaklaşık 128-bit seviyesindedir. Bu yüzden “SHA-256 kuantum sonrasında yaklaşık 128-bit çakışma direnci sağlar” demek doğru bir teknik ifade değildir. Preimage, second-preimage ve collision güvenliği ayrı ayrı değerlendirilmelidir.

Bu ayrım geçiş önceliklendirmesi için kritiktir. Asimetrik kriptografi kuantum tehdidiyle köklü bir değişim gerektirirken, simetrik kriptografi ve hash fonksiyonlarında çoğu zaman parametre ve kullanım amacı değerlendirmesi yapılır. AES-256, SHA-384 veya SHA-512 gibi daha geniş güvenlik marjı sunan ilkeller uzun vadeli sistemlerde tercih edilebilir; ancak asıl acil geçiş alanı public-key kriptografi, anahtar anlaşması ve dijital imzadır.

Kriptografik güvenlik yalnızca “bugün bu sistemi kim kırabilir?” sorusuyla değil, “bu verinin ne kadar süre gizli kalması gerekiyor?” sorusuyla da değerlendirilmelidir. Tıbbi kayıtlar, devlet sırları, finansal anlaşmalar, kritik altyapı planları, patent bilgileri ve gizli ticari belgeler on yıllarca korunması gereken veri sınıflarıdır. Eğer bu veriler bugün RSA veya ECDH tabanlı kanallardan geçiyorsa, pasif bir saldırgan bu trafiği kaydedip gelecekte kuantum kapasitesiyle çözmeye çalışabilir. Bu senaryo harvest-now-decrypt-later olarak adlandırılır ve PQC geçişinin bugünden planlanması gerektiğini gösteren en güçlü argümanlardan biridir.

Post-Kuantum Kripto Aileleri

Post-kuantum kriptografi tek bir algoritma ailesinden oluşmaz. Farklı matematiksel varsayımlara dayanan birden fazla yaklaşım vardır. Her ailenin güvenlik dayanağı, performansı, anahtar boyutu, imza veya ciphertext boyutu ve standartlaşma olgunluğu farklıdır.

Kafes tabanlı kriptografi, güncel PQC standartlaşmasının ağırlık merkezlerinden biridir. Learning With Errors, Module-LWE, Short Integer Solution ve ilişkili kafes problemleri üzerine kurulur. ML-KEM ve ML-DSA bu ailenin NIST tarafından standartlaştırılmış iki temel örneğidir. ML-KEM, Module-LWE probleminin zorluğuyla ilişkilendirilir ve FIPS 203 içinde ML-KEM-512, ML-KEM-768 ve ML-KEM-1024 olmak üzere üç parametre setiyle tanımlanır. Bu parametre setleri artan güvenlik gücü ve azalan performans sırasıyla verilmiştir.

Kafes tabanlı yapıların avantajı genellikle iyi performans ve makul anahtar/ciphertext boyutları sunmalarıdır. Ancak “makul” ifadesi klasik ECDH veya ECDSA ile aynı boyutta oldukları anlamına gelmez. ML-KEM public key ve ciphertext boyutları klasik elliptic curve key exchange yapılarına kıyasla belirgin biçimde büyüktür. Bu fark TLS handshake, sertifika zinciri, IoT cihazları, düşük bant genişlikli ortamlar ve yüksek hacimli bağlantı senaryolarında ayrıca ölçülmelidir.

Kod tabanlı kriptografi, hata düzeltme kodlarının çözülme zorluğuna dayanır. McEliece sistemi 1970’lere kadar uzanan çok eski ve uzun süre analiz edilmiş bir yaklaşımdır. Bu ailedeki temel pratik zorluk anahtar boyutlarının çok büyük olabilmesidir. Bu durum bazı protokoller için bant genişliği ve depolama açısından maliyet yaratır. Buna rağmen kod tabanlı kriptografi post-kuantum çeşitlilik için önemlidir. NIST, 2025 yılında HQC’yi ML-KEM’e yedek olacak kod tabanlı KEM olarak standartlaştırmak üzere seçmiştir; bu nedenle kod tabanlı aileyi artık “NIST standardı yok” şeklinde bırakmak güncel değildir.

Hash tabanlı imzalar, güvenliğini büyük ölçüde kriptografik hash fonksiyonlarının güvenliğine dayandırır. SLH-DSA, SPHINCS+ algoritmasının NIST tarafından standartlaştırılmış adıdır ve FIPS 205 içinde yer alır. SLH-DSA stateless bir hash tabanlı dijital imza standardıdır. Hash tabanlı yapılar güvenlik varsayımı açısından muhafazakâr kabul edilir; ancak SLH-DSA imza boyutu ML-DSA’ya kıyasla belirgin biçimde büyüktür ve imzalama performansı bazı senaryolarda daha ağır olabilir.

Stateful hash tabanlı imza şemaları da vardır. XMSS ve LMS bu kategoriye girer. Bu yapılarda imzalayan tarafın durum takibini doğru yapması gerekir; aynı durumun tekrar kullanılması güvenliği bozabilir. SLH-DSA’nın stateless olması operasyonel açıdan önemli bir avantajdır; çünkü imzalayan tarafın state yönetimi hatasıyla aynı tek kullanımlık imza bileşenini yeniden kullanması gibi riskleri azaltır. Bunun bedeli daha büyük imza boyutu ve performans maliyetidir.

Çok değişkenli polinom sistemlerine dayanan imza yapıları, küçük imza boyutu gibi avantajlar sunabilmiştir; ancak NIST sürecinde bu ailedeki birçok aday kırılmış veya ciddi güvenlik sorunlarıyla karşılaşmıştır. Bu nedenle çok değişkenli yapılar araştırma açısından önemli olsa da güncel NIST ana standartları içinde üretim geçişinin merkezinde değildir.

İzogeni tabanlı yaklaşımlar, eliptik eğriler arasındaki izogeni problemleri üzerine kurulur. Bu alanda özellikle SIDH/SIKE’in 2022’de klasik bir saldırıyla kırılması, izogeni tabanlı hattın NIST üretim standardı bağlamındaki güvenini ciddi biçimde zayıflatmıştır. Burada dikkatli ifade kullanmak gerekir: “SIDH/SIKE kırıldı” demek doğrudur; “tüm izogeni tabanlı kriptografi kırıldı” demek fazla geniş ve teknik olarak hatalı olur.

Aile Temel varsayım Anahtar boyutu İmza / ciphertext boyutu Performans NIST durumu

Kafes tabanlı LWE, Module-LWE, SIS ve ilişkili kafes problemleri Orta Orta Genellikle iyi ML-KEM, ML-DSA standartlaştı

Kod tabanlı Hata düzeltme kodlarını çözme zorluğu Genellikle büyük Değişken Değişken HQC, ML-KEM’e yedek KEM olarak seçildi

Hash tabanlı imza Hash fonksiyonu güvenliği Küçük public key Büyük imza İmzalama/doğrulama parametreye bağlı SLH-DSA standartlaştı

Çok değişkenli Çok değişkenli polinom sistemleri Küçük/orta Genellikle küçük imza hedefi Değişken Birçok aday kırıldı veya ilerleyemedi

İzogeni tabanlı Eğriler arası izogeni hesaplama Küçük hedeflenmişti Küçük hedeflenmişti Yavaş olabilirdi SIDH/SIKE kırılması nedeniyle üretim güveni zayıfladı

NIST Post-Kuantum Standartları

NIST, 2016’da başlattığı post-kuantum kriptografi standartlaşma sürecini 2024’te ilk resmi standartların yayımlanmasıyla önemli bir aşamaya taşıdı. FIPS 203 ML-KEM’i, FIPS 204 ML-DSA’yı, FIPS 205 ise SLH-DSA’yı tanımlar. Bu üç standart, günümüzün en çok incelenmiş PQC yapılarını kurumsal geçiş planlamasının temel referansları hâline getirmiştir.

ML-KEM, Module Lattice-Based Key Encapsulation Mechanism anlamına gelir ve CRYSTALS-Kyber algoritmasının standartlaştırılmış adıdır. Kullanım amacı anahtar kapsülleme mekanizmasıdır. KEM, iki tarafın açık kanal üzerinden ortak bir sır kurmasına imkân verir. Gönderen, alıcının public key’iyle bir ciphertext/kapsül ve shared secret üretir; alıcı kendi private key’iyle kapsülü açarak aynı shared secret değerine ulaşır. Bu shared secret daha sonra simetrik şifreleme, kimlik doğrulama veya oturum anahtarı üretimi için KDF içinde kullanılır.

ML-KEM, klasik RSA key transport veya ECDH gibi anahtar kurma mekanizmalarının post-kuantum karşılığı olarak düşünülmelidir. Ancak ML-KEM bir dijital imza algoritması değildir. ML-KEM-512, ML-KEM-768 ve ML-KEM-1024 olmak üzere üç parametre seti vardır. Parametre seçimi hedef güvenlik seviyesi, performans, bant genişliği ve protokol profiline göre yapılmalıdır. TLS hibrit geçişlerinde ML-KEM-768 sık görülen güçlü bir adaydır; ancak her sistem için otomatik tek doğru seçenek olarak yazılmamalıdır. FIPS 203, parametre setlerini artan güvenlik gücü ve azalan performans sırasıyla tanımlar.

ML-DSA, Module Lattice-Based Digital Signature Algorithm anlamına gelir ve CRYSTALS-Dilithium algoritmasının standartlaştırılmış adıdır. Dijital imza üretmek ve doğrulamak için kullanılır. FIPS 204, ML-DSA’nın veri bütünlüğü, imzalayan kimliği ve inkâr edememe gibi dijital imza hedefleri için kullanılabileceğini belirtir.

ML-DSA, ML-DSA-44, ML-DSA-65 ve ML-DSA-87 parametre setleriyle gelir. Bu parametreler güvenlik seviyesi, imza boyutu, public/private key boyutu ve performans arasında farklı dengeler sunar. ML-DSA’nın imza boyutları ECDSA veya Ed25519 gibi klasik imzalara göre belirgin biçimde daha büyüktür; bu durum sertifika zincirleri, yazılım imzalama paketleri ve düşük bant genişlikli sistemlerde hesaba katılmalıdır.

ML-DSA imzalama modları anlatılırken dikkatli olmak gerekir. ML-DSA’da hedged ve deterministik davranış seçenekleri vardır; ancak deterministik imzalamanın her zaman operasyonel riski azalttığını söylemek doğru değildir. FIPS 204’te varsayılan yaklaşım hedged imzalamadır. Hedged tasarım, taze rastgelelik ile özel anahtardan türetilen veriyi birlikte kullanarak RNG hataları, yan kanal ve fault riskleri açısından daha dengeli bir güvenlik profili hedefler. Deterministik imza seçeneği bazı senaryolarda anlamlı olabilir; fakat her ortamda otomatik olarak daha güvenli kabul edilmemelidir.

SLH-DSA, Stateless Hash-Based Digital Signature Algorithm anlamına gelir ve SPHINCS+ algoritmasının standartlaştırılmış adıdır. FIPS 205 içinde tanımlanır. SLH-DSA’nın en önemli özelliği, güvenlik varsayımının hash fonksiyonlarına dayanması ve state yönetimi gerektirmemesidir. Bu nedenle daha muhafazakâr bir imza seçeneği olarak değerlendirilebilir. Ancak bunun bedeli büyük imza boyutu ve bazı senaryolarda daha düşük performanstır.

KEM ile dijital imza ayrımı post-kuantum tasarımda çok net kurulmalıdır. NIST’in ilk PQC standartlarında ML-KEM anahtar kapsülleme için, ML-DSA ve SLH-DSA dijital imza için kullanılır. Klasik RSA dünyasında aynı matematiksel aile hem şifreleme/key transport hem de imzalama için kullanılabildiğinden bazı tasarımcılar bu alışkanlığı PQC’ye taşımaya çalışabilir. Bu doğru değildir. PQC geçişinde “anahtar kurma” ve “imza” ayrı algoritma seçimi gerektirir.

CRYSTALS-Kyber ve CRYSTALS-Dilithium adları hâlâ birçok kütüphane, makale ve geçiş dokümanında görülebilir. Ancak resmi standart adları ML-KEM ve ML-DSA’dır. Aynı şekilde SPHINCS+ için standart adı SLH-DSA’dır. Güncel teknik belgeler, uyumluluk dokümanları ve kurumsal politika metinleri resmi adları kullanmalıdır; eski adlar ise parantez içinde eşleştirme amacıyla verilebilir.

NIST’in standartlaşma süreci FIPS 203, 204 ve 205 ile tamamlanmış değildir. FALCON tabanlı FN-DSA’nın FIPS 206 olarak geliştirilmesi sürmektedir. Ayrıca HQC, ML-KEM’e yedek olacak kod tabanlı KEM olarak seçilmiştir. Bu nedenle PQC eğitimi, yalnızca 2024’te yayımlanan üç standardı değil, standart ailesinin gelişmeye devam ettiğini de göstermelidir.

Hibrit Geçiş Yaklaşımları

Hibrit anahtar anlaşması, klasik ve post-kuantum bileşenleri aynı anahtar kurma akışında birlikte kullanma fikrine dayanır. Bu yaklaşımın temel motivasyonu geçiş döneminin belirsizliğidir. Bir tarafta klasik ECDH gibi uzun yıllardır kullanılan, olgun ve iyi analiz edilmiş algoritmalar vardır; diğer tarafta kuantum saldırılara dirençli olması beklenen ama üretim ekosistemi hâlâ olgunlaşmakta olan PQC algoritmaları vardır.

Hibrit tasarımın güvenlik sezgisi doğru kurulmalıdır. Amaç, klasik ve post-kuantum bileşenlerden elde edilen sırları HKDF gibi güvenli bir KDF ile birleştirerek, bileşenlerden en az biri güvenli kaldığı sürece nihai oturum sırrının güvenli kalmasını hedeflemektir. Eğer sistemin güvenliği “her iki bileşen de güvenli kalırsa” şeklinde kurulmuş olsaydı, hibrit yapı zayıf bileşene bağlı olurdu ve geçiş dönemindeki ana faydasını kaybederdi. IETF hibrit key exchange çalışmaları da birden fazla algoritmanın paylaşılan sırlarının güvenli biçimde birleştirilmesi fikrini bu nedenle ele alır.

Bir TLS 1.3 örneği üzerinden düşünürsek, istemci ve sunucu hem X25519 gibi klasik ECDH bileşeni hem de ML-KEM-768 gibi post-kuantum KEM bileşeni üzerinden gizli değerler elde edebilir. Bu iki gizli değer doğrudan yan yana eklenip kullanılmamalıdır. Güvenli tasarımda bu değerler açık bir domain separation etiketi, protokol transcript’i ve bağlam bilgisiyle birlikte KDF’ye girer. Böylece klasik ve post-kuantum bileşenlerin hangi amaçla, hangi protokol sürümünde ve hangi oturum bağlamında kullanıldığı anahtar türetme sürecine bağlanmış olur.

TLS 1.3 mimarisi hibrit key exchange profillerine uygundur; ancak bu, tüm TLS 1.3 uygulamalarının otomatik olarak hibrit PQC desteklediği anlamına gelmez. Kullanılacak hibrit named group, kütüphane desteği, tarayıcı desteği, sunucu yapılandırması ve standartlaşma durumu ayrıca kontrol edilmelidir. Deneysel destek ile üretim standardı birbirine karıştırılmamalıdır.

Hibrit geçişin pratik etkilerinden biri mesaj boyutudur. ML-KEM public key ve ciphertext boyutları klasik elliptic curve key share değerlerinden büyüktür. Dijital imza tarafında ML-DSA ve özellikle SLH-DSA imzaları klasik ECDSA/Ed25519 imzalarından daha büyük olabilir. Bu durum TLS handshake boyutu, sertifika zinciri, ağ gecikmesi, düşük bant genişliği, IoT cihazları, VPN tünelleri ve yüksek hacimli bağlantılar üzerinde etkili olabilir.

Sertifika zincirlerinde post-kuantum imza kullanıldığında boyut problemi daha da belirginleşir. Sadece sunucu key exchange tarafını hibrit yapmak ile tüm PKI zincirini PQC imzalarına geçirmek aynı şey değildir. İkinci durumda kök CA, ara CA, sertifika profilleri, client trust store, OCSP/CRL mekanizmaları ve sertifika boyutu yönetimi birlikte ele alınmalıdır.

Performans konusu yalnızca CPU süresi değildir. ML-KEM bazı optimize ortamlarda oldukça hızlı çalışabilir; fakat anahtar ve ciphertext boyutları, bellek kullanımı, handshake paket sayısı, MTU/parçalanma etkisi ve sertifika zinciri boyutu toplam performansı belirler. Bu nedenle geçiş testleri yalnızca “anahtar üretim süresi kaç ms?” sorusuyla sınırlı kalmamalıdır. İşlem süresi, mesaj boyutu, bellek kullanımı, bağlantı başarısızlık oranı ve gerçek ağ koşullarındaki gecikme birlikte ölçülmelidir.

Kurumsal PQC Geçiş Planı

PQC geçişi yalnızca algoritma değiştirme kararı değildir. Bu süreç; altyapı, tedarik zinciri, veri sınıflandırması, uyumluluk, kütüphane desteği, donanım desteği, operasyon planı ve zaman yönetimi meselesidir. Sağlıklı geçiş planı panikle değil, envanter ve risk önceliklendirmesiyle başlar.

İlk adım kriptografik envanterdir. Kurum hangi algoritmaları, hangi sistemlerde, hangi amaçla kullandığını bilmeden geçiş planı yapamaz. Bu envanter TLS sertifikalarını, VPN altyapısını, yazılım imzalama sistemlerini, firmware imzalarını, şifreli depolama katmanlarını, KMS/HSM entegrasyonlarını, veritabanı şifrelemesini, kimlik doğrulama tokenlarını, dosya transfer sistemlerini, mobil uygulama sertifika pinning yapılarını ve üçüncü taraf tedarikçi bileşenlerini kapsamalıdır. NIST NCCoE PQC migration çalışmaları da kriptografik envanter ve geçiş planlamasını sürecin ana parçalarından biri olarak ele alır.

Envanter yalnızca algoritma adı listesi değildir. Her varlık için şu sorular sorulmalıdır: Algoritma ne için kullanılıyor? Gizlilik mi, bütünlük mü, kimlik doğrulama mı, imza mı, key wrapping mi? Anahtar ömrü ne kadar? Verinin gizlilik ömrü ne kadar? Bu mekanizma dış dünyaya açık mı? Pasif olarak kaydedilebilir mi? Tedarikçi tarafından mı yönetiliyor? Güncelleme imkânı var mı? Hangi uyumluluk gereksinimine bağlı?

Geçiş önceliğini belirleyen en önemli unsurlardan biri veri gizlilik ömrüdür. Bugün yakalanan bir trafik birkaç dakika sonra önemini kaybediyorsa harvest-now-decrypt-later riski sınırlı olabilir. Ancak veri on yıl veya daha uzun süre gizli kalmak zorundaysa, bugünkü klasik public-key koruması geleceğe yönelik risk oluşturur. Sağlık kayıtları, finansal arşivler, devlet belgeleri, kritik altyapı planları ve yüksek değerli ticari sırlar bu nedenle erken analiz edilmelidir.

PKI ve kök sertifika yapıları yüksek önceliklidir. Kök ve ara CA anahtarları uzun ömürlü güven ilişkileri kurar. Kuantum tehdit modeli yalnızca yeni TLS bağlantılarını değil, gelecekte doğrulanacak yazılım imzalarını, cihaz sertifikalarını ve uzun süre geçerli olacak güven zincirlerini de etkiler. Bu geçiş yalnızca imza algoritmasını değiştirmek değildir; trust store, sertifika profili, client desteği, zincir boyutu ve operasyonel yayılım süreciyle birlikte planlanmalıdır.

Yazılım imzalama da yüksek öncelikli alanlardan biridir. Buradaki risk harvest-now-decrypt-later değil, gelecekte sahte imza üretimi ve güven zincirinin kırılmasıdır. Firmware, bootloader, işletim sistemi güncellemeleri, paket yöneticileri ve uzun ömürlü ürünlerin yazılım güncelleme zincirleri RSA/ECDSA imzalarına dayanıyorsa, kuantum dönemde bu imzaların taklit edilebilir hâle gelmesi kritik sonuçlar doğurabilir. Güçlü bir hash fonksiyonu kullanılması tek başına yeterli değildir; imza algoritmasının kuantum kırılabilirliği ayrıca ele alınmalıdır. FIPS 204 ve 205 dijital imzaları veri bütünlüğü, imzalayan kimliği ve inkâr edememe bağlamında tanımlar.

TLS anahtar anlaşması ve VPN tünelleri özellikle hassas veri taşıyorsa yüksek öncelikli değerlendirilmelidir. Forward secrecy klasik saldırgan modelinde önemlidir; fakat kuantum sonrası dönemde klasik ECDH mesajlarının gelecekte çözülmesi HNDL riski doğurabilir. Bu nedenle hibrit TLS, hibrit VPN veya PQC uyumlu key establishment profilleri test edilmelidir.

Simetrik şifreli depolama, eğer AES-256 gibi güçlü simetrik algoritmalarla ve anahtar yönetimi doğru yapılmışsa kuantum açısından daha düşük öncelikli olabilir. Ancak bu AES anahtarları RSA/ECDH tabanlı key wrapping, klasik public-key envelope encryption veya kuantum kırılabilir bir anahtar erişim katmanıyla korunuyorsa risk simetrik algoritmada değil, anahtar sarmalama katmanındadır. Bu ayrım kurumsal analizde açıkça yazılmalıdır.

Altyapı bileşeni Kuantum tehdit profili Geçiş önceliği

Uzun vadeli şifreli arşivler HNDL riski yüksek; anahtar sarmalama katmanı ayrıca incelenmeli İlk öncelik

PKI / kök ve ara sertifikalar Uzun ömürlü güven zinciri ve imza güvenilirliği etkilenir Yüksek

TLS anahtar anlaşması Pasif kayıt + gelecekte çözme riski; hibrit geçiş anlamlı Yüksek

VPN tünelleri Uzun süre gizli kalması gereken trafik için HNDL riski Yüksek

Yazılım / firmware imzalama Gelecekte sahte imza ve güncelleme zinciri riski Yüksek

Kimlik doğrulama tokenları Algoritma ve geçerlilik süresine bağlı Bağlama göre değişken

AES-256 ile simetrik depolama Grover etkisi sınırlı; key wrapping katmanı belirleyici Düşük/orta, bağlama bağlı

Eski RSA/ECDH key wrapping HNDL ve uzun ömürlü arşiv için kritik Yüksek

Crypto agility, PQC geçişinin sürdürülebilir olmasını sağlar. Algoritmanın kod içinde sabitlenmesi, sertifika profilinin değiştirilememesi, kütüphanenin tek algoritmaya bağlı olması veya protokol negotiation mekanizmasının olmaması gelecekteki geçişleri zorlaştırır. Algoritma çevikliği; konfigürasyonla algoritma seçebilme, sürümleme, test ortamında yeni algoritma deneyebilme, sertifika profillerini güncelleyebilme ve rollback/fallback kararlarını güvenli biçimde yönetebilme kapasitesidir.

Uyumluluk ve standart takibi de geçiş planının parçası olmalıdır. ABD federal kurumları ve tedarik zincirleri, NIST ve ilgili kamu rehberleri doğrultusunda PQC geçiş planlamasını daha erken yapmak zorundadır. Benzer baskı savunma, finans, telekom, sağlık ve kritik altyapı sektörlerine yayılabilir. NIST NCCoE PQC migration FAQ içinde farklı politika, standart ve uluslararası rehberlere doğrudan referans verir; bu da geçişin yalnızca teknik değil, yönetişim meselesi olduğunu gösterir.

Post-Kuantum Kriptografi Araçları ve Geçiş Testleri

PQC algoritmalarını anlamak, test etmek ve prototiplemek için en bilinen açık kaynak girişimlerden biri Open Quantum Safe projesidir. Bu projenin iki önemli bileşeni liboqs ve OQS OpenSSL Provider’dır. liboqs, PQC algoritmalarını araştırma ve prototipleme amacıyla sunan C tabanlı bir kütüphanedir. OQS OpenSSL Provider ise OpenSSL 3.x provider mimarisiyle PQC algoritmalarını deneysel/prototip bağlamda kullanmaya imkân verir.

Bu araçların sınırı net kurulmalıdır. OQS projesi, liboqs veya uygulama entegrasyonlarının üretim ortamında ya da hassas veriyi korumak için kullanılmasını önermediğini açıkça belirtir. Bunun nedeni, bu araçların araştırma, prototipleme ve geçiş testi için tasarlanması; yüksek güvenlikli üretim kullanımı için gereken denetim ve analiz seviyesinin farklı olmasıdır.

OQS araçları yine de eğitim açısından çok değerlidir. Öğrenci algoritma adı, parametre seti, public key boyutu, private key boyutu, ciphertext boyutu, shared secret boyutu, imza boyutu ve işlem sürelerini somut çıktılar üzerinde görebilir. Bu sayede standart belge ile araç çıktısı arasında ilişki kurmayı öğrenir.

OQS OpenSSL Provider ile ML-KEM-768 anahtar çifti üretildiğinde, araç çıktısında algoritma tanımlayıcısı ve anahtar boyutları görülür. ML-KEM-768 için FIPS 203 referans boyutları nettir: encapsulation/public key 1184 byte, decapsulation/private key 2400 byte, ciphertext 1088 byte ve shared secret 32 byte’tır. “Civarında” gibi belirsiz ifade kullanmak yerine bu değerler standart referansla karşılaştırılmalıdır.

Kullanılan araç sürümü açıkça not edilmelidir. Eğitim metninde OQS OpenSSL Provider için belirli eski bir sürümü sabitlemek doğru değildir; çünkü provider aktif gelişir ve algoritma adları, group etiketleri, TLS hibrit davranışları ve çıktı formatları sürüme göre değişebilir. Daha doğru ifade “güncel OQS OpenSSL Provider + OpenSSL 3.x, izole Linux test ortamı” şeklindedir.

Test vektörleri algoritmik doğruluğu kontrol etmek için kullanılır. Bir implementasyonun NIST test vektörleriyle uyumlu çıktı üretmesi, algoritmanın standart davranışını doğru uyguladığını gösterir. Ancak test vektörlerini geçmek yan kanal güvenliği, fault saldırılarına direnç, güvenli bellek yönetimi, protokol entegrasyonu veya üretim denetimi açısından garanti vermez.

Benchmark sonuçları da dikkatli okunmalıdır. Anahtar üretim süresi, kapsülleme süresi, kapsül açma süresi, imzalama süresi, doğrulama süresi, bellek kullanımı, public key/ciphertext/imza boyutu ve handshake etkisi birlikte değerlendirilmelidir. ML-KEM performansı kullanılan donanım, derleyici optimizasyonu, kütüphane sürümü ve parametre setine göre değişebilir. Bazı ortamlarda işlem süresi kabul edilebilir seviyededir; ancak mesaj boyutları klasik ECDH’ye göre belirgin biçimde büyür. Bu nedenle benchmark, yalnızca CPU süresi değil, gerçek protokol etkisi ölçümü olarak düşünülmelidir.

Wireshark ile hibrit TLS bağlantısı izlenirken amaç gerçek kurumsal trafiği yakalamak değil, izole test ağında ClientHello ve ServerHello içindeki key share/group müzakeresini kavramsal olarak görmektir. Deneysel bir ML-KEM + X25519 hibrit grup listeleniyor ve seçiliyorsa bu geçiş prototipi açısından faydalı bir gözlemdir. Ancak başarılı bağlantı, üretim kalitesi veya güvenlik sertifikasyonu anlamına gelmez.

Komut & Araç Okuryazarlığı

OQS OpenSSL Provider ile ML-KEM Parametrelerini Doğrulama

OQS OpenSSL Provider’ın kurulu olduğu izole bir test ortamında ML-KEM-768 algoritmasıyla anahtar çifti üretildiğinde, araç çıktısında algoritma adı, public key boyutu ve private key boyutu incelenebilir. Buradaki amaç gerçek üretim anahtarı oluşturmak değil, standart parametrelerle araç çıktısı arasında bağlantı kurmaktır.

Platform olarak güncel OQS OpenSSL Provider, OpenSSL 3.x ve izole bir Linux test makinesi kullanılmalıdır. Kullanılan provider ve OpenSSL sürümü not edilmelidir; çünkü algoritma etiketleri ve desteklenen gruplar sürüme göre değişebilir.

Öğrenci çıktıda öncelikle algoritma tanımlayıcısına bakmalıdır. ML-KEM-768, ml-kem-768, kyber768 veya geçiş dönemi isimlendirmeleri görülebilir. Resmi standart adı ML-KEM’dir; eski Kyber adı bazı araçlarda uyumluluk veya geçiş etiketi olarak görülebilir. Bu durum tek başına hata değildir; fakat kullanılan kütüphanenin hangi standarda ve hangi sürüme uyduğu dokümantasyondan doğrulanmalıdır.

ML-KEM-768 için beklenen referans değerler public/encapsulation key 1184 byte, private/decapsulation key 2400 byte, ciphertext 1088 byte ve shared secret 32 byte’tır. Araç çıktısı bu değerlerle uyuşmuyorsa yanlış parametre seti, eski kütüphane sürümü, farklı encoding veya provider yapılandırma sorunu olabilir.

Bu egzersizin güvenli kullanım sınırı açıktır: yalnızca izinli ve izole test ortamında yapılmalıdır. Gerçek üretim anahtarlarıyla karıştırılmamalı, gerçek sunuculara yönelik deneysel bağlantı kurulmadan önce yazılı izin ve test kapsamı netleştirilmelidir.

liboqs Test Vektörü Doğrulaması

liboqs test suite, algoritmaların test vektörleri karşısında beklenen çıktıları üretip üretmediğini kontrol etmek için kullanılabilir. Bu süreç saldırı değil, implementasyon doğrulama pratiğidir. Ancak üretim ortamından tamamen ayrı test makinelerinde yapılmalıdır.

Beklenen çıktı, seçilen algoritma ve parametre setleri için PASS sonucudur. Herhangi bir FAIL çıktısı; kütüphane sürümü, derleme parametresi, platform bağımlı optimizasyon veya test vektörü uyumsuzluğu açısından incelenmelidir.

PASS sonucu yalnızca algoritmik doğruluğa işaret eder. Yan kanal güvenliği, fault tolerance, güvenli bellek yönetimi, production hardening, FIPS validasyonu veya protokol entegrasyonu hakkında tek başına güvence sağlamaz.

Hibrit TLS Bağlantısının Wireshark ile Kavramsal İzlenmesi

OQS OpenSSL Provider ile hazırlanmış deneysel bir istemci ve sunucu arasında X25519 + ML-KEM hibrit anahtar anlaşması içeren TLS bağlantısı kurulduğunda Wireshark ile handshake yapısı incelenebilir. Bu yalnızca izole ve izinli test ağında yapılmalıdır; gerçek kurumsal ağ trafiği yakalanmamalıdır.

Öğrenci ClientHello içindeki supported_groups ve key_share alanlarına bakarak klasik ve post-kuantum bileşenlerin nasıl listelendiğini gözlemleyebilir. ServerHello tarafında hangi grubun seçildiği incelenir. Hibrit grup seçilmişse bağlantı prototip düzeyde tamamlanmış demektir.

Bu çıktı dikkatli yorumlanmalıdır. Deneysel hibrit grubun başarıyla müzakere edilmesi, kullanılan implementasyonun üretim kalitesinde olduğu anlamına gelmez. Ayrıca sunucu PQC hibrit grubu desteklemiyorsa klasik gruba düşebilir. Bu fallback davranışı geçiş stratejisinde açıkça tanımlanmalıdır; aksi hâlde “PQC destekliyoruz” denilen ortam fiilen klasik key exchange ile çalışıyor olabilir.

İleri Seviye Güvenli Analiz / Kontrol Listesi

PQC geçişine hazırlanırken önce kriptografik envanterin güncel olup olmadığı kontrol edilmelidir. Envanter yalnızca TLS sertifikalarını değil, VPN sistemlerini, PKI zincirini, yazılım imzalama mekanizmalarını, firmware güncelleme altyapısını, dosya şifreleme sistemlerini, veritabanı şifreleme katmanlarını, anahtar sarmalama mekanizmalarını, HSM/KMS entegrasyonlarını ve üçüncü taraf bileşenleri kapsamalıdır.

Her varlık için algoritma, anahtar uzunluğu, kullanım amacı, veri gizlilik ömrü, anahtar ömrü ve güncellenebilirlik bilgisi kaydedilmelidir. Bir sistemde RSA veya ECDH kullanılması tek başına aynı önceliği doğurmaz; risk, o kullanımın neyi koruduğuna bağlıdır. Uzun vadeli gizlilik gerektiren veri taşıyan RSA/ECDH kanalları, kısa ömürlü ve düşük hassasiyetli bağlantılara göre daha erken ele alınmalıdır.

Harvest-now-decrypt-later değerlendirmesi ayrı yapılmalıdır. Hangi veri bugün pasif olarak kaydedilebilir? Bu veri kaç yıl gizli kalmalı? Trafik TLS, VPN veya başka bir public-key key exchange mekanizmasıyla mı korunuyor? Bu soruların cevabı geçiş önceliğini belirler.

İmza sistemleri için farklı bir risk dili kullanılmalıdır. Yazılım imzalama, kod imzalama, firmware imzası ve PKI zinciri gizlilik değil, uzun vadeli bütünlük ve otantiklik problemidir. Burada risk “bugün topla, sonra çöz” değil, gelecekte sahte imza üretimi ve güven zincirinin taklit edilmesidir.

Hibrit mod planlanıyorsa birleştirme mekanizması belgelenmelidir. Klasik ve post-kuantum bileşenlerden gelen sırlar hangi KDF ile birleştiriliyor? Domain separation var mı? Transcript/context bağlanıyor mu? Fallback davranışı nasıl? Bileşenlerden biri başarısız olursa bağlantı tamamen reddediliyor mu, yoksa klasik moda sessizce düşüyor mu?

Seçilen PQC kütüphanesinin test vektörleriyle uyumu doğrulanmalıdır. Ancak test vektörü başarısı üretim güvenliği anlamına gelmez. Yan kanal güvenliği, güvenli bellek yönetimi, fault attack dayanıklılığı, FIPS uyumu, tedarikçi desteği ve bakım süreci ayrıca değerlendirilmelidir.

Performans testleri hedef altyapı ölçeğinde yapılmalıdır. Laboratuvar benchmark’ı, gerçek yük altındaki sonuçlarla aynı olmayabilir. Özellikle TLS handshake boyutu, sertifika zinciri boyutu, mobil istemci performansı, IoT cihaz bellek sınırları, VPN tünel kurulumu, CDN/load balancer davranışı ve paket parçalanması gibi alanlar ayrıca ölçülmelidir.

Geçiş planı geliştirici, güvenlik, mimari, uyumluluk ve operasyon ekiplerine farklı dillerle anlatılmalıdır. Geliştirici için kütüphane ve API değişimi; güvenlik ekibi için tehdit modeli ve envanter; mimari ekip için protokol ve bağımlılık; uyumluluk ekibi için standart ve denetim takvimi; operasyon ekibi için deployment ve rollback planı gerekir.

Analitik Senaryo

Durum

Finansal hizmetler alanında faaliyet gösteren FinanceOrg adlı hayali kurum, on yıl ve üzeri saklama gereksinimi bulunan müşteri veri arşivlerine sahiptir. Güvenlik mimarisi gözden geçirme sürecinde security_engineer, mevcut arşiv şifreleme altyapısında RSA-2048 tabanlı anahtar sarmalama kullanıldığını tespit eder. Verilerin bir kısmı 15–20 yıl boyunca gizliliğini korumak zorundadır.

İlk Değerlendirme

RSA-2048 bugün klasik saldırgan modelinde birçok sistemde hâlen minimum kabul edilebilir seviyede görülebilir. Ancak 15–20 yıl gizlilik gerektiren arşiv verisi için bu rahatlatıcı bir sonuç değildir. Sorun bugünkü klasik saldırganın RSA-2048’i kolayca kırması değil, pasif bir saldırganın bugün şifreli arşiv trafiğini veya RSA-wrapped DEK materyalini toplayıp gelecekte kuantum kapasitesiyle çözmeye çalışabilmesidir.

Bu senaryo harvest-now-decrypt-later riskini doğrudan gündeme getirir. Özellikle arşiv verisi uzun süre gizli kalmak zorundaysa, geçiş planı “kuantum bilgisayar ortaya çıkınca yapılacak iş” olarak görülmemelidir. Geçmişte kaydedilmiş veriyi gelecekte korumak için önlem bugünden alınmalıdır.

Kontrol Edilecek Noktalar

Önce mevcut arşiv mimarisi ayrıştırılmalıdır. Veri doğrudan RSA ile mi korunuyor, yoksa veri bir DEK ile simetrik olarak şifrelenip DEK RSA-OAEP benzeri bir mekanizmayla mı sarılıyor? RSA key wrapping hangi padding ile yapılıyor? DEK’ler veri başına mı, dosya başına mı, müşteri başına mı, dönem başına mı üretiliyor? KEK veya RSA private key nerede tutuluyor?

Arşiv verisinin aktarım kanalları da incelenmelidir. Arşivleme sırasında veri TLS üzerinden mi taşınıyor? Bu TLS bağlantıları hangi key exchange algoritmasını kullanıyor? ECDHE klasik mi, hibrit mi? Veriler offline taşınıyorsa anahtarlar nasıl korunuyor?

Mevcut KMS/HSM altyapısının PQC veya hibrit key wrapping destekleyip desteklemediği araştırılmalıdır. Destek yoksa tedarikçi roadmap’i, geçici envelope encryption katmanı, hibrit prototip ve uzun vadeli yeniden şifreleme planı ayrıca değerlendirilmelidir.

İncelenecek Çıktı ve Yapı

İlk incelenecek belgeler kriptografik envanter, KMS/HSM anahtar raporları, arşiv şifreleme yapılandırmaları, TLS log’ları ve veri saklama politikasıdır. Verinin gizlilik ömrü açıkça yazılmamışsa teknik geçiş önceliği doğru belirlenemez.

ML-KEM parametre seçenekleri FIPS 203 ile karşılaştırılmalıdır. ML-KEM-768 veya ML-KEM-1024 aday olabilir; ancak seçim yalnızca “en yüksek parametre daha güvenli” mantığıyla yapılmamalıdır. Performans, ciphertext boyutu, KMS desteği, istemci uyumluluğu ve veri hacmi birlikte değerlendirilmelidir.

Güvenli Doğrulama Yaklaşımı

Arşiv geçişinde hibrit yapı, “RSA + ML-KEM” gibi kaba bir ifade yerine açık bir KEM-DEM veya envelope encryption tasarımı olarak kurulmalıdır. Örneğin klasik bileşenden ve ML-KEM’den elde edilen sırlar HKDF içinde domain-separated biçimde birleştirilir; elde edilen key material DEK wrapping veya KEK türetme için kullanılır. Bu tasarımda hangi verinin hangi bağlamla KDF’ye girdiği açıkça belgelenmelidir.

Yalnızca gelecekteki arşiv akışını hibrit yapmak mevcut arşiv verisini otomatik olarak korumaz. Daha önce RSA-wrapped biçimde saklanan DEK’ler varsa, bu DEK’lerin yeniden sarılması veya verinin yeniden şifrelenmesi planlanmalıdır. Rewrap, aynı DEK’in yeni koruma katmanı ile sarılması anlamına gelir. Re-encryption ise verinin yeni DEK veya yeni şifreleme politikasıyla yeniden şifrelenmesidir. Hangi yöntemin seçileceği veri hacmi, işlem maliyeti, yasal gereksinim ve risk düzeyine bağlıdır.

Yanlış Yorumlama İhtimali

“RSA-2048 bugün kırılamıyor, bu yüzden geçişe zaman var” yaklaşımı uzun ömürlü veri için hatalıdır. Bugünkü mesele RSA-2048’in klasik saldırgan karşısındaki durumu değil, bugün kaydedilen verinin gelecekte çözülme ihtimalidir.

Bunun tersi olan “her şeyi bugün doğrudan PQC’ye geçirelim” yaklaşımı da risklidir. Kütüphane olgunluğu, standart desteği, sertifikasyon, tedarikçi uyumluluğu, performans etkisi ve operasyonel rollback planı olmadan yapılan acele geçiş yeni güvenlik ve erişilebilirlik sorunları doğurabilir.

“OQS ile prototip başarılı oldu, üretime geçebiliriz” yorumu da yanlıştır. OQS araçları algoritma davranışını ve geçiş etkilerini anlamak için değerlidir; üretim güvenlik garantisi vermez.

Riskin Pratik Karşılığı

Pasif saldırgan bugün arşiv trafiğini, RSA-wrapped DEK materyalini veya arşiv anahtar değişim kayıtlarını ele geçirebilir. Kuantum kapasitesi yeterli hâle geldiğinde RSA tabanlı koruma kırılırsa, saldırgan arşiv DEK’lerine ulaşabilir ve yıllarca gizli kalması gereken finansal müşteri verilerini çözebilir.

Bu risk yalnızca teknik veri sızıntısı değildir. Regülasyon, müşteri güveni, finansal sorumluluk, yasal bildirim yükümlülüğü ve kurumsal itibar açısından büyük sonuçlar doğurabilir.

Önerilen Güvenli Yaklaşım

FinanceOrg önce kriptografik envanteri tamamlamalı ve uzun ömürlü veri akışlarını ayrı sınıflandırmalıdır. RSA tabanlı key wrapping kullanan tüm arşiv bileşenleri belirlenmeli, veri gizlilik ömrüne göre geçiş önceliği verilmelidir.

Kısa vadede hibrit envelope encryption prototipi izole ortamda test edilmelidir. Klasik bileşen ve ML-KEM çıktılarının HKDF ile nasıl birleştirileceği, domain separation etiketleri, ciphertext formatı, key versioning ve rewrap stratejisi açıkça tanımlanmalıdır.

Orta vadede mevcut RSA-wrapped DEK’ler için rewrap veya re-encryption planı yapılmalıdır. Bu işlem veri bütünlüğü doğrulaması, backup stratejisi, işlem süresi, erişim kesintisi ve rollback planı olmadan başlatılmamalıdır.

Uzun vadede kurumun KMS/HSM tedarikçileriyle PQC destek takvimi netleştirilmeli, PKI ve yazılım imzalama zinciri için ayrı geçiş planı hazırlanmalı ve kriptografik envanter sürekli güncellenen bir yönetişim aracına dönüştürülmelidir.

Bu değerlendirme mimari ekibe şu dille aktarılabilir:

“Mevcut RSA-2048 tabanlı key wrapping yapısı bugünün klasik saldırgan modeli açısından minimum kabul edilebilir seviyede görülebilir; ancak 15–20 yıl gizlilik gerektiren arşiv verisi için harvest-now-decrypt-later riski doğurur. Geçiş, yalnızca yeni veriler için hibrit akış kurmakla sınırlı kalmamalı; mevcut DEK’lerin rewrap veya re-encryption planı, KMS/HSM desteği, performans testi ve standart uyumu ile birlikte yürütülmelidir.”

Terimler Sözlüğü

Shor algoritması Tam sayı çarpanlara ayırma ve ayrık logaritma problemlerini yeterli ölçekli kuantum bilgisayarda polinom zamanda çözebilen algoritma; RSA, klasik DH ve ECC için temel tehdittir.

Grover algoritması Yapılandırılmamış aramada karekök hızlanma sağlayan kuantum algoritması; simetrik anahtar aramasında etkili güvenlik seviyesini yaklaşık yarıya indirir.

Harvest-now-decrypt-later Şifreli verinin bugün kaydedilip gelecekte kuantum kapasitesiyle çözülmeye çalışılması stratejisi.

Post-kuantum kriptografi Hem klasik hem kuantum saldırganlara karşı güvenli olması hedeflenen kriptografik algoritma aileleri.

CRQC Cryptographically Relevant Quantum Computer; mevcut public-key kriptografiyi tehdit edecek düzeyde kuantum bilgisayar.

ML-KEM Module Lattice-Based Key Encapsulation Mechanism; CRYSTALS-Kyber’in FIPS 203 ile standartlaştırılmış adı.

ML-DSA Module Lattice-Based Digital Signature Algorithm; CRYSTALS-Dilithium’un FIPS 204 ile standartlaştırılmış adı.

SLH-DSA Stateless Hash-Based Digital Signature Algorithm; SPHINCS+’ın FIPS 205 ile standartlaştırılmış adı.

FN-DSA FALCON tabanlı, FIPS 206 olarak geliştirme süreci devam eden post-kuantum dijital imza standardı adayı.

HQC Kod tabanlı KEM; NIST tarafından ML-KEM’e yedek olacak ek post-kuantum şifreleme algoritması olarak seçilmiştir.

KEM Key Encapsulation Mechanism; public key ile kapsül ve shared secret üreten anahtar kurma mekanizması.

KEM-DEM KEM ile shared secret kurup DEM/simetrik şifreleme ile veriyi koruyan hibrit şifreleme mimarisi.

Kafes tabanlı kriptografi LWE, Module-LWE ve SIS gibi kafes problemlerinin zorluğuna dayanan PQC ailesi.

Kod tabanlı kriptografi Hata düzeltme kodlarını çözme zorluğuna dayanan PQC ailesi.

Hash tabanlı imza Güvenliğini büyük ölçüde hash fonksiyonlarına dayandıran imza şeması ailesi.

Çok değişkenli kriptografi Çok değişkenli polinom sistemlerini çözmenin zorluğuna dayanan kriptografi ailesi.

İzogeni tabanlı kriptografi Eliptik eğriler arasındaki izogeni hesaplama problemlerine dayanan kriptografi ailesi.

Hibrit anahtar anlaşması Klasik ve post-kuantum bileşenlerden elde edilen sırların KDF ile birleştirilerek oturum anahtarı türetilmesi.

Domain separation Farklı protokol, amaç veya bağlamların anahtar türetme/hash sürecinde karışmaması için kullanılan ayrıştırma yaklaşımı.

HKDF HMAC tabanlı key derivation function; hibrit sır birleştirme ve TLS key schedule gibi alanlarda kullanılır.

Crypto agility Kriptografik çeviklik; algoritma ve parametre değişimini mimari olarak mümkün kılan tasarım ilkesi.

Kriptografik envanter Bir kurumun kullandığı algoritmaları, anahtarları, protokolleri, kullanım amaçlarını ve veri gizlilik ömürlerini içeren katalog.

CBOM Cryptography Bill of Materials; yazılım/sistem içindeki kriptografik bileşenlerin izlenebilir listesini ifade eden yaklaşım.

Stateless imza İmzalama sırasında state takibi gerektirmeyen imza şeması; SLH-DSA bu sınıftadır.

Stateful hash tabanlı imza XMSS ve LMS gibi state yönetimi gerektiren hash tabanlı imza şemaları.

Benchmark Algoritmanın anahtar üretim, kapsülleme, kapsül açma, imzalama ve doğrulama performansını ölçen test.

Test vektörü Implementasyonun standart algoritma davranışıyla uyumlu olduğunu doğrulamak için kullanılan giriş-çıkış verisi.

liboqs Open Quantum Safe projesinin PQC algoritmaları için sunduğu C tabanlı araştırma/prototipleme kütüphanesi.

OQS OpenSSL Provider liboqs algoritmalarını OpenSSL 3.x provider mimarisiyle deneysel/prototip kullanıma taşıyan bileşen.

FIPS 203 ML-KEM standardı.

FIPS 204 ML-DSA standardı.

FIPS 205 SLH-DSA standardı.

FIPS 206 FN-DSA/FALCON tabanlı imza standardı için geliştirme sürecindeki FIPS belgesi.

Key wrapping Bir anahtarın başka bir anahtar veya public-key mekanizmasıyla sarılarak korunması.

Rewrap Mevcut veri anahtarını değiştirmeden, anahtarın koruma/sarma katmanını yenileme işlemi.

Re-encryption Verinin yeni anahtar veya yeni şifreleme politikasıyla yeniden şifrelenmesi.

PQC migration Kuantum kırılabilir public-key algoritmalardan post-kuantum algoritmalara kontrollü geçiş süreci.

Kendini Değerlendir — İleri Kriptografi Modül 9

Bu Modülde Neler Öğrendik?

Bu modül, post-kuantum kriptografiyi soyut bir gelecek endişesi olmaktan çıkarıp bugünkü güvenlik mimarisi, veri saklama politikası ve kurumsal geçiş planlamasıyla ilişkilendirdi.

Shor algoritmasının RSA, klasik Diffie-Hellman ve ECC gibi public-key sistemlerini kökten etkilediğini; Grover algoritmasının ise simetrik sistemlerde daha sınırlı ve parametreyle yönetilebilir bir etki oluşturduğunu öğrendik. Hash fonksiyonlarında preimage ve collision güvenliğinin aynı şey olmadığını, bu yüzden kuantum etkisinin kullanım amacına göre ayrı yorumlanması gerektiğini netleştirdik.

ML-KEM, ML-DSA ve SLH-DSA’nın NIST’in ilk resmi PQC standartları olduğunu; ML-KEM’in anahtar kapsülleme, ML-DSA ve SLH-DSA’nın ise dijital imza için kullanıldığını öğrendik. Bunun yanında HQC’nin kod tabanlı yedek KEM olarak seçildiğini ve FN-DSA/FIPS 206 sürecinin FALCON tabanlı ek imza standardı olarak devam ettiğini güncel standartlaşma bağlamına yerleştirdik.

PQC ailelerini kafes tabanlı, kod tabanlı, hash tabanlı, çok değişkenli ve izogeni tabanlı yaklaşımlar olarak karşılaştırdık. Her ailenin yalnızca güvenlik varsayımıyla değil, anahtar boyutu, imza/ciphertext boyutu, performans ve üretim olgunluğu açısından da değerlendirilmesi gerektiğini gördük.

Hibrit anahtar anlaşmasının geçiş dönemindeki rolünü doğru güvenlik mantığıyla kurduk. Hibrit tasarımın hedefi, klasik ve post-kuantum bileşenlerden en az biri güvenli kaldığında nihai oturum sırrının korunmasıdır. Bu hedefin gerçekleşmesi için HKDF gibi uygun KDF, domain separation ve transcript/context bağlama gerekir.

Kurumsal geçiş planının yalnızca “algoritmayı değiştir” adımından ibaret olmadığını gördük. Kriptografik envanter, veri gizlilik ömrü, HNDL riski, PKI geçişi, yazılım imzalama zinciri, TLS/VPN altyapısı, key wrapping katmanı, tedarikçi desteği, benchmark ve uyumluluk takibi birlikte ele alınmalıdır.

Yazılım imzalama ve PKI geçişinin gizlilikten farklı bir problem olduğunu öğrendik. Burada risk geçmiş verinin çözülmesi değil, gelecekte sahte imza üretimi ve güven zincirinin kırılmasıdır. Bu nedenle firmware, bootloader, kod imzalama ve uzun ömürlü ürün güncelleme zincirleri PQC geçişinde yüksek öncelikli alanlardır.

OQS/liboqs ve OQS OpenSSL Provider araçlarının değerini doğru konumlandırdık. Bu araçlar eğitim, araştırma, prototipleme, test vektörü doğrulama ve performans ölçümü için çok yararlıdır; ancak üretim güvenliği veya denetlenmiş FIPS uyumu anlamına gelmez. Test vektörünü geçmek algoritmik doğruluk sağlar, fakat yan kanal güvenliği ve üretim hardening garantisi vermez.

Analitik senaryo üzerinden, RSA-2048 tabanlı key wrapping kullanan uzun ömürlü finansal arşivlerde asıl riskin bugünkü klasik kırılma değil, harvest-now-decrypt-later olduğunu gördük. Yeni akışlar için hibrit envelope encryption planlanırken mevcut arşivler için rewrap veya re-encryption stratejisinin ayrıca düşünülmesi gerektiğini öğrendik.

MODÜL 10 — İleri kriptografik yapılar ve araştırma ufku

Modül özeti

Araştırma hattındaki yapıları “heyecan” yerine olgunluk, denetim, performans ve standart ekseninde konumlandırır; üretim kararı için sorulacak soruları netleştirir.

Modül 10 — İleri Kriptografik Yapılar ve Araştırma Ufku

Bu modül, ileri kriptografi eğitiminin son halkasıdır ve bilinçli olarak bir “araştırma ufku” modülü şeklinde tasarlanmıştır. Önceki modüllerde öğrencinin AEAD, ZKP, MPC, PQC, anahtar yönetimi, protokol güvenliği ve modern kriptografik tasarım ilkeleri hakkında temel analiz becerileri kazandığı varsayılır. Bu modül ise o zeminin üzerine oturarak homomorfik şifreleme, fonksiyonel şifreleme, öznitelik tabanlı şifreleme ve anonim kriptografik yapılar gibi daha ileri alanların gerçek dünya olgunluğunu, sınırlarını ve ekosistemini değerlendirme becerisi kazandırmayı hedefler.

Buradaki amaç, her yapının matematiksel iç mekanizmasını baştan sona derinlemesine öğretmek değildir. Asıl amaç, bir siber güvenlik uzmanının bu yapılarla nerede karşılaşacağını, hangi yapının üretim kalitesine daha yakın olduğunu, hangisinin hâlâ araştırma veya prototip seviyesinde kaldığını ve bu bilgilerden hareketle hangi soruları sorması gerektiğini net biçimde görmesini sağlamaktır.

Bu modülde özellikle “olgunluk değerlendirmesi” kavramı öne çıkar. Bir kriptografik yapının akademik açıdan ilginç olması, onu doğrudan üretim sistemine koymak için yeterli değildir. Standartlaşma durumu, bağımsız denetim geçmişi, topluluk desteği, performans sınırları, bakım maliyeti, güvenli parametre seçimi ve kullanım hatalarına karşı dayanıklılık, karar verme sürecinin ayrılmaz parçalarıdır.

Modülün sonunda öğrenci, ileri kriptografik yapılarla ilgili bir araştırma makalesi, ürün tanıtımı, GitHub deposu, benchmark çıktısı veya mimari öneri gördüğünde hangi soruları sorması gerektiğini bilecek; gerçekçi olmayan beklentilerden kaçınırken bu alanların gerçek potansiyelini de daha sağlıklı değerlendirebilecektir.

Kazanımlar

Bu modül sonunda öğrenci:

Homomorfik şifrelemenin kısmen ve tam homomorfik ayrımını, CKKS/BFV/BGV şemalarının hangi veri tiplerine uygun olduğunu ve performans sınırlarının neden birçok üretim kullanımını kısıtladığını açıklayabilir.

Fonksiyonel şifreleme ile öznitelik tabanlı şifrelemenin klasik şifreleme modellerinden farkını, erişim politikası kavramını ve bu yapıların gerçek kullanım senaryolarındaki operasyonel zorluklarını ilişkilendirebilir.

Kör imza, grup imzası ve ring imzasının hangi gizlilik ve hesap verebilirlik dengelerini sağladığını, hangi sistemlerde karşımıza çıkabileceğini ve birbirlerinden hangi yönlerle ayrıldıklarını açıklayabilir.

Bu modüldeki yapıların olgunluk spektrumunu değerlendirebilir; hangi yapıların sınırlı üretim kullanımında, hangilerinin ağırlıklı olarak araştırma veya prototipleme alanında olduğunu daha güvenilir biçimde sınıflandırabilir.

FHE, ZKP ve anonim kriptografi araç ekosistemini üretim olgunluğu, denetim geçmişi, performans beklentisi, bakım sağlığı ve standartlaşma durumu açısından değerlendirebilir.

Araştırma araçlarını ve prototipleme kütüphanelerini doğrudan üretim sistemlerine taşımanın neden ciddi risk oluşturduğunu somut gerekçelerle ifade edebilir.

Benchmark çıktılarını yorumlayarak bir yapının kendi altyapısında uygulanabilirliğini ön değerlendirme düzeyinde analiz edebilir.

Bu ileri yapılarla ilgili teknik iletişim kurabilir; bir araştırma önerisini veya sistem mimarisi tartışmasını gerçekçi güvenlik, performans ve olgunluk argümanlarıyla değerlendirebilir.

Homomorfik Şifreleme

Şifreli Veri Üzerinde Hesaplama Fikri

Homomorfik şifreleme, kriptografinin hem en fazla ilgi uyandıran hem de üretim beklentileri açısından en dikkatli okunması gereken alanlarından biridir. Temel fikir oldukça güçlüdür: Bir veri şifrelenir, şifreli halde başka bir tarafa gönderilir ve karşı taraf bu veriyi hiç görmeden üzerinde belirli hesaplamalar yapabilir. Hesaplamanın sonucu yine şifreli olarak döner ve yalnızca gizli anahtara sahip taraf tarafından çözülebilir.

Bu fikir, bulut ortamında hassas veriler üzerinde analiz yapma, tıbbi verileri ifşa etmeden işleme, kullanıcı verilerini doğrudan sunucuya açmadan istatistiksel analiz üretme veya gizli girdi gerektiren makine öğrenmesi çıkarımlarını gerçekleştirme gibi senaryolar açısından çok çekicidir. HomomorphicEncryption.org da homomorfik şifrelemeyi, veriler şifreliyken onlar üzerinde doğrudan hesaplama yapılmasını sağlayan bir teknoloji olarak tanımlar ve bu alan için topluluk/industry standardizasyon çalışmaları yürütür.

Homomorfik şifreleme kabaca iki ana kategori altında ele alınabilir. Kısmen homomorfik şifreleme (Partially Homomorphic Encryption, PHE), yalnızca belirli işlem türlerini destekler. Örneğin bazı şemalar toplama üzerinde, bazıları ise çarpma üzerinde homomorfik özellik gösterir. RSA’nın çarpmaya göre homomorfik özellik göstermesi klasik bir örnektir; ancak bu özellik tek başına modern anlamda güvenli bir FHE sistemi oluşturmaz. Daha çok kavramın anlaşılması için tarihsel ve pedagojik bir örnek olarak görülmelidir.

Tam homomorfik şifreleme (Fully Homomorphic Encryption, FHE) ise hem toplama hem çarpma işlemlerinin birlikte yapılabilmesine izin vererek genel hesaplamayı şifreli veri üzerinde gerçekleştirmeyi hedefler. Bu yaklaşım, teorik olarak rastgele hesaplamanın şifreli veri üzerinde yürütülebilmesini mümkün kılar. FHE fikri 1970’lerden beri tartışılsa da, ilk tam yapılandırmanın Gentry’nin 2009’daki çalışmasıyla ortaya konması bu alanın dönüm noktası olarak kabul edilir. HomomorphicEncryption.org’un açıklamalarında da FHE’nin önceki teorik fikirlerden Gentry’nin 2009’daki ilk inşasına uzanan gelişim çizgisi vurgulanır.

CKKS, BFV ve BGV: Ne Zaman Hangisi?

Günümüzde pratik FHE uygulamaları için birkaç farklı şema öne çıkar. BFV ve BGV, modüler tamsayı aritmetiği gerektiren hesaplamalar için kullanılır. Bu şemalar, sonuçların belirli bir modüler yapı içinde kesin olarak temsil edilmesinin beklendiği senaryolara daha yakındır. CKKS ise yaklaşık aritmetik üzerine kurulu bir şemadır ve gerçek veya karmaşık sayılarla yapılan yaklaşık hesaplamalar için tasarlanmıştır. Microsoft SEAL dokümantasyonu da BFV ve BGV’yi şifreli modüler tamsayı aritmetiği, CKKS’yi ise şifreli gerçek veya karmaşık sayılar üzerinde yaklaşık işlem için konumlandırır.

CKKS’deki “yaklaşık” kelimesi özellikle önemlidir. CKKS, belirli bir hata toleransıyla çalışır; sonuçlar matematiksel olarak tam kesinlikte değildir. Bu nedenle makine öğrenmesi çıkarımı, istatistiksel analiz, sinyal işleme veya küçük sayısal hataların kabul edilebilir olduğu senaryolarda CKKS tercih edilebilir. Buna karşılık kriptografik doğrulama, kesin finansal hesaplama, tam sayı mantığına dayalı kurallar veya bit düzeyinde kesin sonuç gerektiren sistemlerde BFV ya da BGV daha uygun olabilir.

CKKS değerlendirilirken yalnızca şemanın kriptografik varsayımlarına bakmak yeterli değildir. Yaklaşık aritmetik; ölçekleme, hata yayılımı, multiplicative depth, çıktıların yorumlanması ve uygulama protokolü açısından ayrıca incelenmelidir. Parametre seçimi veya hata toleransı hatalı yapılırsa sonuç yalnızca performans açısından değil, doğruluk ve uygulama katmanı gizliliği açısından da riskli hale gelebilir. Bu nedenle CKKS kullanan bir sistemde “şema güvenli mi?” sorusunun yanında “bu hesaplama modeli, hata aralığı ve çıktı yorumlama biçimi hedef uygulama için güvenli mi?” sorusu da sorulmalıdır.

Performans Gerçekliği

FHE’nin en kritik sorunu performanstır. Klasik açık veri üzerinde yapılan hesaplamaya kıyasla FHE işlemleri çoğu senaryoda birkaç mertebe daha maliyetlidir. Ancak bu maliyet tek bir sabit oranla ifade edilemez. Kullanılan şema, güvenlik parametreleri, polynomial modulus degree, coefficient modulus, multiplicative depth, batching/packing kullanımı, bootstrapping gereksinimi, donanım, derleyici ayarları ve implementasyon optimizasyonu sonuçları dramatik biçimde değiştirebilir.

Bu yüzden FHE için “her zaman şu kadar yavaştır” veya “basit bir işlem mutlaka dakikalar sürer” gibi mutlak cümleler kurmak doğru değildir. Daha doğru yaklaşım, FHE’nin çoğu pratik senaryoda ciddi performans maliyeti getirdiğini, bu maliyetin ancak hedef sistem üzerinde gerçekçi benchmark ile anlaşılabileceğini kabul etmektir. Microsoft SEAL dokümantasyonu da verimli ve verimsiz implementasyonlar arasında birkaç mertebe fark oluşabileceğini vurgular.

Bu performans gerçekliği, FHE’yi bugün için genellikle özel senaryolarla sınırlar. Güvenlik ihtiyacının performans kaybını haklı çıkardığı, veri hacminin sınırlı olduğu, hesaplamanın çevrimdışı yapılabildiği, gecikme beklentisinin düşük olmadığı veya hesaplama modelinin FHE’ye özel biçimde yeniden tasarlanabildiği durumlarda FHE anlamlı bir aday olabilir. Büyük ölçekli, gerçek zamanlı ve düşük gecikmeli sistemlerde ise FHE hâlâ dikkatli fizibilite çalışması gerektirir.

FHE teorik açıdan kriptografinin en etkileyici yapılarından biridir. Ancak üretim sistemi kararı verirken “teknik olarak mümkün” ile “operasyonel olarak uygulanabilir” arasındaki farkı gözetmek, ileri kriptografi değerlendirmesinin temel sorumluluğudur.

Fonksiyonel ve Öznitelik Tabanlı Şifreleme

Fonksiyonel Şifreleme: Kısmi Bilgiyi Güvenli Açmak

Geleneksel şifreleme modelinde bir şifreli mesajı ya tamamen çözebilirsiniz ya da hiç çözemezsiniz. Bu all-or-nothing yapı birçok kullanım için yeterlidir, fakat bazı senaryolar daha ince erişim kontrolü gerektirir. Örneğin bir hasta kaydının yalnızca teşhis bilgisini yetkili bir araştırmacıya açmak, fakat hastanın adı, iletişim bilgileri veya diğer özel alanlarını gizli tutmak isteyebilirsiniz. Klasik şifreleme bu ayrımı doğrudan kriptografik seviyede sağlamaz.

Fonksiyonel şifreleme (Functional Encryption, FE), bu soruna daha ince bir yaklaşım önerir. FE’de özel bir fonksiyon anahtarıyla yalnızca belirli bir fonksiyonun şifreli veri üzerinde hesaplanmasına izin verilir. Kullanıcı verinin tamamını elde etmez; yalnızca f(m) sonucunu öğrenir. Bu nedenle FE, klasik şifreleme modelinden farklı olarak “veriyi tamamen açmak” yerine “veri hakkında izin verilen çıktıyı elde etmek” fikrine dayanır.

Kimlik tabanlı şifreleme (Identity-Based Encryption, IBE), fonksiyonel şifreleme ile aynı geniş tasarım çizgisinde değerlendirilebilen, daha erken ve nispeten olgun bir yapıdır. IBE’de açık anahtar doğrudan bir kimlik dizisine, örneğin bir e-posta adresine karşılık gelebilir. Böylece ayrı bir sertifika altyapısı kurmadan kimlik üzerinden şifreleme yapılabilir. Bununla birlikte klasik IBE, genel amaçlı FE’nin tüm ifade gücüne sahip değildir; bu yüzden IBE’yi doğrudan “FE’nin tam karşılığı” gibi değil, FE ile ilişkili ama daha sınırlı ve daha özel bir yapı olarak okumak daha doğrudur.

IBE’nin en kritik tasarım sonucu, merkezi bir özel anahtar üreticiye (Private Key Generator, PKG) ihtiyaç duymasıdır. PKG, kullanıcıların özel anahtarlarını ürettiği için teorik olarak tüm kullanıcıların şifreli içeriklerine erişebilecek konumdadır. Bu durum escrow riski doğurur. Bazı kurumsal veya kontrollü sistemlerde bu kabul edilebilir olabilir; ancak güçlü uçtan uca gizlilik beklenen sistemlerde temel bir güven problemidir.

Öznitelik Tabanlı Şifreleme: Politika ile Şifreleme

Öznitelik tabanlı şifreleme (Attribute-Based Encryption, ABE), erişim kontrolünü öznitelikler ve politikalar üzerinden ifade eden bir şifreleme modelidir. Burada erişim, tek bir kullanıcı kimliğinden çok, kullanıcının sahip olduğu özniteliklerle ve veriye bağlı politikalarla ilişkilendirilir. Örneğin “departman = finans” ve “yetki seviyesi ≥ 3” gibi özniteliklere sahip kullanıcıların belirli bir belgeyi çözebilmesi istenebilir.

ABE iki temel yönde çalışabilir. Şifreli metin politikalı ABE’de (Ciphertext-Policy ABE, CP-ABE), erişim politikası şifreli metne gömülür; kullanıcıların özel anahtarları ise özniteliklerini taşır. Bir kullanıcı, şifreli metindeki politikayı karşılayan özniteliklere sahipse veriyi çözebilir. Anahtar politikalı ABE’de (Key-Policy ABE, KP-ABE) ise bunun tersi geçerlidir: öznitelikler şifreli metne bağlanır, erişim politikası ise özel anahtar tarafında ifade edilir. Bu ayrımın doğru kurulması önemlidir; çünkü “politika şifreli metne bağlıdır” ifadesi yalnızca CP-ABE için doğrudur.

CP-ABE, veriyi şifreleyen tarafın erişim politikasını şifreleme anında belirleyebilmesi nedeniyle pratik sistem tasarımlarına daha yakın görünür. Ancak ABE’nin teorik zarafeti, gerçek dünya karmaşıklığını ortadan kaldırmaz. Öznitelik iptali (revocation), performans sınırları, anahtar delegasyonu, politika güncellemeleri, kullanıcı özniteliklerinin yaşam döngüsü, merkezi otoriteye güven ve uygulama katmanı entegrasyonu ABE’nin üretim sistemlerine taşınmasını zorlaştırır.

Bu nedenle ABE hâlâ büyük ölçüde araştırma, prototipleme ve sınırlı özel kullanım alanlarında karşımıza çıkar. Karmaşık erişim kontrolünü şifreleme katmanında ifade etme fikri güçlüdür; ancak operasyonel maliyet ve bakım yükü gerçek sistemlerde dikkatle değerlendirilmelidir.

Anonim Kriptografik Yapılar

Kör İmzalar

Kör imza (Blind Signature), bir imzacının mesajın içeriğini görmeden imza üretmesine olanak tanıyan bir kriptografik yapıdır. Klasik senaryoda kullanıcı mesajını bir maskeleme faktörüyle örter ve imzacıya gönderir. İmzacı bu maskelenmiş mesajı imzalar. Kullanıcı daha sonra maskeyi kaldırarak gerçek mesaj üzerinde geçerli bir imza elde eder. İmzacı, hangi mesajı imzaladığını doğrudan görmez.

Bu yapının en bilinen uygulama alanlarından biri dijital nakit sistemleridir. Bir banka, müşteriye kör imzayla dijital para birimi üretebilir; fakat para daha sonra harcandığında bu paranın hangi müşteriden geldiğini doğrudan izleyemeyebilir. Kör imzalar, anonimlik ve hesap verebilirlik arasındaki gerilimi çok net gösterir. Kullanıcı gizliliği korunurken çift harcama önleme gibi problemler ayrı mekanizmalarla çözülmelidir.

Güncel standartlaşma açısından kör imzalar tamamen belirsiz bir alan değildir. Özellikle RSA kör imzaları için RFC 9474 bulunmaktadır; bu RFC, RSA tabanlı kör imza protokolünü tanımlar ve çıktı imzanın RSA-PSS imzası olarak doğrulanabildiğini belirtir. Ancak bu, tüm kör imza ailesinin her varyantı için aynı olgunlukta standartlaştığı anlamına gelmez.

Grup İmzaları

Grup imzası (Group Signature), bir grubun herhangi bir üyesinin kimliğini gizleyerek grup adına imza atmasını sağlar. Doğrulayan taraf, imzanın geçerli bir grup üyesinden geldiğini doğrulayabilir; fakat hangi üyeden geldiğini öğrenemez. Buna ek olarak grup yöneticisi, gerekli durumlarda anonimliği kaldırabilir ve imzanın hangi üyeye ait olduğunu belirleyebilir.

Bu özellik, grup imzalarını kör imzadan ayıran en kritik noktadır. Grup imzaları tamamen izlenemez anonimlik değil, denetlenebilir anonimlik sunar. Bu nedenle bazı kurumsal, regülasyon odaklı veya hesap verebilirlik gerektiren sistemlerde daha uygun olabilir. Örneğin bir kurumun çalışanlarının belirli bir yetkiye sahip olduğunu dış tarafa kanıtlaması, ancak bireysel kimliklerinin açıklanmaması gereken senaryolarda grup imzası fikri anlamlıdır.

Grup imzası ailesi, anonim dijital imza mekanizmaları bağlamında ISO/IEC 20008 ailesiyle ilişkilidir. Bu durum, grup imzalarının en azından belirli standartlaşma çerçeveleriyle ele alındığını gösterir; fakat üretim ekosistemi hâlâ sınırlıdır.

Ring İmzaları

Ring imzası (Ring Signature), kullanıcının önceden tanımlanmış merkezi bir gruba ihtiyaç duymadan, kendi belirlediği bir halka içindeki herhangi bir üyeden geliyormuş gibi imza oluşturmasına olanak tanır. Grup imzasından farkı, halkanın dinamik olarak oluşturulabilmesi ve merkezi bir grup yöneticisinin bulunmamasıdır. Bu nedenle ring imzalarında anonimlik genel olarak kalıcıdır ve merkezi bir taraf tarafından kaldırılamaz.

Bu özellik ring imzalarını güçlü bir gizlilik aracı haline getirir. Muhbir koruma sistemleri, gizli oylama tasarımları ve gizlilik odaklı kripto para sistemleri bu bağlamda tartışılabilir. Monero gibi gizlilik odaklı kripto para sistemleri, kör imza değil ring imza/RingCT çizgisiyle ilişkilendirilmelidir. Monero kaynakları RingCT’nin işlem tutarlarını gizlemek için kullanıldığını ve Monero’nun ring signature yaklaşımıyla ilişkili olduğunu açıklar.

Ring imzasının kaldırılamaz anonimliği, onu bir yandan güçlü bir gizlilik aracı yaparken diğer yandan suistimal potansiyeli açısından dikkatli değerlendirilmesi gereken bir yapıya dönüştürür. Regüle ortamlarda denetlenebilirlik gereksinimi varsa ring imzası yerine grup imzası gibi anonimliği yetkili bir tarafça kaldırılabilen yapılar daha uygun olabilir.

Anonim Yapıların Karşılaştırması

Yapı Anonimlik Modeli Hesap Verebilirlik Merkezi Otorite Tipik Kullanım

Kör imza İmzacı mesajı görmez Dış mekanizma gerekir Evet, imzacı vardır Dijital nakit, e-nakit, bazı e-oy ve token sistemleri

Grup imzası Üye kimliği doğrulayıcıya karşı gizlidir Grup yöneticisi anonimliği açabilir Evet, grup yöneticisi vardır Kurumsal kimlik, yetki kanıtı, denetlenebilir anonimlik

Ring imzası Halka içindeki imzalayan gizlidir ve anonimlik genellikle kalıcıdır Merkezi açma mekanizması yoktur Hayır Muhbir koruma senaryoları, gizlilik odaklı kripto para sistemleri

Anonimlik ve Hesap Verebilirlik Dengesi

Bu üç yapının her biri farklı bir anonimlik garantisi sunar. Bu nedenle sistem tasarımında “anonimlik istiyoruz” demek tek başına yeterli değildir. Sorulması gereken asıl soru şudur: Sistem gerçekten izlenemez anonimlik mi sunmalı, yoksa yetkili bir tarafın denetim amacıyla anonimliği kaldırabileceği denetlenebilir anonimlik mi gerekir?

Bu sorunun cevabı uygulamanın hukuki çerçevesinden tehdit modeline, kullanıcı güvenliği beklentisinden kötüye kullanım riskine kadar pek çok kararı etkiler. Özellikle finansal sistemler, devlet uygulamaları ve kurumsal kimlik senaryoları, gizlilik ile kötüye kullanım önleme arasındaki dengeyi farklı biçimlerde kurar. Kriptografik araç seçimi bu dengenin teknik tarafıdır; fakat politika ve risk kararı netleşmeden kriptografik seçim tek başına anlamlı hale gelmez.

Bu Yapıların Gerçek Dünya Konumu

Bu bölüm, modülün en kritik kısmıdır. Öğrencinin ileri kriptografik yapılar hakkında olgunluk değerlendirmesi yapabilmesi, hem fazla iyimser yorumlardan hem de haksız yere küçümseyici değerlendirmelerden kaçınmasını sağlar.

Olgunluk Spektrumu

İleri kriptografik yapıların tümü eşit olgunlukta değildir. Bu farkı görmek, gerçek dünya kararları için zorunludur. Bir yapının olgunluğu yalnızca akademik makale sayısıyla ölçülmez. Standartlaşma durumu, bağımsız güvenlik denetimi, performans kabul edilebilirliği, yazılım ekosistemi sağlığı, bakım sürekliliği ve gerçek üretim dağıtımları birlikte değerlendirilmelidir.

Yapı Standartlaşma Üretim Olgunluğu Performans Baskısı Notlar

FHE (CKKS/BFV/BGV) NIST/FIPS düzeyinde yaygın üretim standardı yok; HomomorphicEncryption.org gibi topluluk/industry standardizasyonu var Araştırma, prototip, niş ve sınırlı üretim denemeleri Çok yüksek Belirli özel senaryolarda anlamlı; geniş üretim için dikkatli fizibilite gerekir

IBE Kısmi; RFC ve standartlaşmış profil çalışmaları bulunur Sınırlı özel sistemler Orta PKG güven sorunu devam eder

CP-ABE Yaygın üretim standardı sınırlı Araştırma ağırlıklı ve sınırlı özel uygulamalar Yüksek Revocation ve politika güncelleme sorunları operasyonel zorluk yaratır

Kör imza Kısmi; RSA kör imzaları için RFC 9474 vardır Dijital nakit, token ve bazı e-oy bağlamlarında görülür Düşük-orta Kullanım bağlamına göre çift harcama ve kötüye kullanım önleme ayrıca tasarlanmalıdır

Grup imzası Kısmi; ISO/IEC 20008 ailesiyle ilişkilidir Sınırlı kurumsal ve özel senaryolar Orta Denetlenebilir anonimlik sağlar

Ring imzası Kısmi / şema ve ekosisteme göre değişken Monero gibi sistemlerde pratik kullanım vardır Değişken Ölçek, halka boyutu ve protokol tasarımı önemlidir

ZKP IETF ve diğer standartlaşma çalışmaları sürüyor Blockchain ve bazı kimlik/gizlilik sistemlerinde yaygınlaşmıştır Özellikle prover tarafında yüksek Modül 6’da detaylandırılmıştı

PQC (ML-KEM vb.) NIST FIPS standartları yayımlandı Artan üretim desteği Kabul edilebilirden orta düzeye değişken ML-KEM, NIST FIPS 203 olarak standartlaşmıştır

PQC tarafında NIST’in ML-KEM’i FIPS 203 olarak yayımlaması, post-kuantum geçişte önemli bir olgunluk göstergesidir. FIPS 203, ML-KEM-512, ML-KEM-768 ve ML-KEM-1024 parametre setlerini tanımlar. Buna karşılık FHE tarafında HomomorphicEncryption.org gibi ciddi topluluk standardizasyonu çabaları olsa da, bu durum FHE kütüphanelerinin otomatik olarak üretim güvenliği tamamlanmış ve her ortam için uygun araçlar olduğu anlamına gelmez.

Bir yapının araştırma ağırlıklı olması, onu değersiz kılmaz. Yalnızca bugün için doğru üretim seçeneği olmayabileceğini gösterir. FHE birkaç yıl önce çoğu senaryo için teorik veya deneysel görünürken bugün belirli niş alanlarda prototiplenebilir ve bazı sınırlı üretim denemelerinde değerlendirilebilir durumdadır. On yıl sonra tablo farklı olabilir. Bu dinamizmi takip etmek, ileri kriptografi uzmanının sorumluluğudur.

Siber Güvenlik Uzmanı Ne Kadar Bilmeli?

Bir siber güvenlik uzmanının bu yapıların tüm matematiksel ayrıntılarına hakim olması beklenmez ve çoğu rol için bu gerçekçi değildir. Asıl yetkinlik, yapının hangi problemi çözdüğünü bilmek, olgunluk durumunu doğru konumlandırabilmek, bir sistem önerisi geldiğinde doğru soruları sormak ve gerektiğinde uzman kriptografa doğru soruyu yöneltebilmektir.

“Bu sistem FHE kullanıyor” ifadesini duyan bir güvenlik uzmanının refleksi şu sorular olmalıdır: Hangi şema kullanılıyor? CKKS mi, BFV mi, BGV mi? Hangi güvenlik parametreleri seçildi? Hangi veri tipi işleniyor? Multiplicative depth ne kadar? Performans gerçek kullanım verisiyle ölçüldü mü? Kütüphane bağımsız denetimden geçti mi? Kullanılan API üretim için öneriliyor mu? Yan kanal güvenliği değerlendirildi mi?

Bu soruları doğal biçimde sormak, ileri kriptografi eğitiminin somut çıktısıdır. Uzman her şemanın iç matematiğini baştan yazmak zorunda değildir; fakat hangi risklerin var olduğunu ve kime hangi teknik sorunun yöneltilmesi gerektiğini bilmelidir.

Akademik Prototip ile Üretim Sistemi Arasındaki Fark

Akademik prototipler çoğu zaman belirli bir fikrin çalıştığını göstermek için tasarlanır. Bu prototipler referans implementasyon olabilir, performans optimize edilmemiş olabilir, güvenlik parametreleri yalnızca makale bağlamında seçilmiş olabilir, hata işleme ve edge case yönetimi eksik kalabilir, yan kanal güvenliği gözetilmemiş olabilir ve bağımsız güvenlik denetimi yapılmamış olabilir.

Üretim sistemi beklentileri ise çok daha geniştir. Üretim sisteminde güvenli varsayılan ayarlar, açık tehdit modeli, güvenli API tasarımı, test vektörü desteği, parametre önerileri, sürüm yönetimi, güvenlik açığı bildirim süreci, bağımsız denetim raporu, yan kanal değerlendirmesi, bakım sürekliliği ve açık dokümantasyon gerekir.

Bu farkı pratikte görmek için ilgili kütüphanenin belgelerinde “experimental”, “research only”, “not for production use” veya “proof of concept” gibi uyarıları aramak yeterlidir. Bu uyarılar varsa, araç doğrudan üretim sistemine taşınmamalı; önce risk değerlendirmesi, alternatif analizi ve gerekirse uzman kriptograf incelemesi yapılmalıdır.

İleri Kriptografik Yapılar İçin Araştırma ve Prototipleme Araçları

FHE Kütüphaneleri: Ekosisteme Genel Bakış

FHE ekosistemi son yıllarda önemli ölçüde büyümüştür. Başlıca açık kaynak kütüphaneler arasında Microsoft SEAL, OpenFHE, HElib ve TFHE sayılabilir. Her biri farklı şemaları, farklı programlama dillerini ve farklı tasarım hedeflerini destekler.

Microsoft SEAL, güncel sürümlerinde BFV, BGV ve CKKS şemalarını destekler. BFV ve BGV modüler tamsayı aritmetiğine, CKKS ise gerçek veya karmaşık sayılar üzerinde yaklaşık hesaplamaya yöneliktir. SEAL kapsamlı dokümantasyonu nedeniyle akademik prototipleme, kavram doğrulama ve eğitim amaçlı çalışmalar için sıkça tercih edilir.

OpenFHE, BFV, BGV, CKKS, TFHE ve FHEW gibi birden fazla şemayı destekleyen geniş bir açık kaynak kütüphanedir. HomomorphicEncryption.org’un açık kaynak ekosistem özetinde OpenFHE’nin BGV, BFV, CKKS, TFHE ve FHEW dahil olmak üzere başlıca FHE şemalarını desteklediği belirtilir. HElib, IBM tarafından başlatılan erken ve yaygın kullanılan FHE kütüphanelerinden biridir; özellikle BGV ve CKKS desteğiyle bilinir. TFHE ise boolean devreler ve gate-by-gate hesaplama modeli açısından öne çıkar.

Bu kütüphaneler, NIST FIPS onaylı üretim kripto modülü gibi değerlendirilmemelidir. FHE için topluluk ve endüstri odaklı standardizasyon çalışmaları bulunsa da, bir kütüphanenin bu çalışmaları desteklemesi onu otomatik olarak bağımsız denetimi tamamlanmış, her tehdit modeli için uygun ve üretime hazır bir ürün haline getirmez. Üretim sistemine taşımak için güvenlik parametreleri, API kullanımı, yan kanal riskleri, bakım sağlığı, denetim geçmişi ve performans hedefleri ayrıca değerlendirilmelidir.

ZKP ve FHE Araçlarında Üretim Olgunluğu Değerlendirmesi

ZKP araç ekosistemi, FHE araçlarıyla kıyaslandığında görünür üretim dağıtımı açısından daha olgun bir konumdadır. Zcash, Ethereum L2 sistemleri ve çeşitli blockchain altyapıları ZKP tabanlı kanıt sistemlerini üretim ölçeğinde kullanmaktadır. Bu sistemlerin kriptografik çekirdekleri çoğu durumda bağımsız denetimlerden geçmiş, gerçek saldırı yüzeyiyle karşılaşmış ve daha geniş geliştirici ekosistemleri tarafından test edilmiştir.

FHE ise ZKP kadar yaygın ve görünür büyük ölçekli üretim dağıtımına sahip değildir. Daha çok niş kullanım senaryoları, pilotlar, kavram doğrulama çalışmaları ve sınırlı üretim denemeleriyle ilerlemektedir. Performans kaybı, parametre karmaşıklığı, uygulama tasarımı zorluğu ve operasyonel maliyet, geniş ölçekli benimsemeyi hâlâ zorlaştırmaktadır. Bununla birlikte Microsoft, IBM, OpenFHE topluluğu ve akademik kurumların çalışmaları, alanın aktif ve hızla gelişen bir araştırma-uygulama hattı olduğunu göstermektedir.

Benchmark Okumak: Ne Anlama Gelir, Ne Anlatmaz?

FHE veya ZKP araçları için yayımlanan benchmark değerlerini yorumlarken birkaç temel boyuta dikkat etmek gerekir. Benchmark koşulları her zaman önemlidir: Hangi donanım kullanıldı? CPU, GPU, FPGA veya özel hızlandırıcı var mı? Hangi derleme ayarları uygulandı? Hangi şema ve parametre seti seçildi? Multiplicative depth ne kadar? Bootstrapping kullanıldı mı? Batching/packing aktif mi? Ölçülen işlem gerçek uygulamayı temsil ediyor mu, yoksa basitleştirilmiş bir demo mu?

Farklı makalelerdeki veya kütüphane belgelerindeki benchmark değerleri doğrudan karşılaştırılamaz. Bu çoğu zaman elma-portakal karşılaştırmasıdır. Daha düşük güvenlik parametresiyle çalışan bir FHE implementasyonu çok hızlı görünebilir; fakat bu performans, güvenlik seviyesini düşürerek elde edilmiş olabilir. Kendi altyapısında FHE değerlendirmesi yapan bir güvenlik uzmanı, benchmark’ı kendi donanım ölçeğinde, kendi veri boyutuyla, hedef güvenlik parametresiyle ve gerçek hesaplama mantığına yakın bir modelle yeniden ölçmeden karar vermemelidir.

Bir araç veya kütüphane için “hızlı” veya “güvenli” deniyorsa, bu iddianın hangi tehdit modelinde, hangi parametre setinde, hangi donanımda ve hangi kullanım senaryosunda geçerli olduğu mutlaka sorgulanmalıdır.

Araç Seçiminde Denetim, Topluluk, Dokümantasyon ve Güncellik

İleri kriptografik yapılar için araç seçerken dört temel kriter öne çıkar: bağımsız denetim, topluluk ve bakım aktifliği, dokümantasyon kalitesi ve standartlaşma durumu.

Bağımsız denetim, bir kütüphanenin profesyonel kripto analistleri tarafından incelenip incelenmediğini gösterir. Denetim raporu kamuya açık mı? Bulunan sorunlar ne kadar sürede giderildi? Denetim yalnızca spesifikasyonu mu, implementasyonu mu, yoksa ikisini birlikte mi kapsıyor? Denetim belirli bir sürüm için mi geçerli, yoksa güncel sürümde kapsam dışı değişiklikler var mı?

Topluluk ve bakım aktifliği, projenin son altı ila on iki ay içinde anlamlı commit’ler aldığını, güvenlik açığı bildirimlerine yanıt verildiğini ve belgelenmiş bir release politikasına sahip olduğunu gösterir. Uzun süredir güncellenmemiş bir kripto kütüphanesi, keşfedilmiş veya keşfedilmemiş zafiyetleri barındırıyor olabilir. Bakım eksikliği özellikle deneysel kripto kütüphanelerinde büyük bir risktir.

Dokümantasyon kalitesi, kütüphanenin yalnızca algoritma açıklaması değil, güvenli kullanım kılavuzları, parametre önerileri, bilinen sınırlamalar, kötüye kullanım senaryoları ve üretim uyarıları hakkında da bilgi sunup sunmadığını gösterir. İyi bir kripto kütüphanesi, kullanıcının ne yapmaması gerektiğini de açıkça belirtir.

Standartlaşma durumu ise kullanılan algoritmanın veya protokolün resmi ya da topluluk tarafından kabul görmüş bir standart çerçevesine dayanıp dayanmadığını gösterir. NIST, RFC, ISO/IEC veya alanın saygın standardizasyon girişimleri burada önemlidir. Standartlaşmamış algoritmalar, tek başına hatalı demek değildir; ancak öngörülemeyen güvenlik sorunları ve birlikte çalışabilirlik problemleri açısından daha dikkatli ele alınmalıdır.

Komut & Araç Okuryazarlığı

FHE Kütüphanesi Benchmark Çıktısı: Microsoft SEAL veya OpenFHE

Bir izole test makinesinde, örneğin LOCAL-CRYPTO01 adlı ayrı bir Linux test ortamında Microsoft SEAL veya OpenFHE kütüphanesinin benchmark suite’i çalıştırıldığında çıktı, kullanılan kütüphane, şema ve parametre setine bağlı olarak anahtar üretimi, şifreleme, şifre çözme, toplama, çarpma, yeniden ölçekleme ve rotasyon gibi işlemlerin sürelerini verebilir. Bootstrapping ölçümleri ise özellikle bunu destekleyen şema, kütüphane ve benchmark yapılandırmalarında görülür; her Microsoft SEAL veya OpenFHE çıktısında otomatik olarak bulunacağı varsayılmamalıdır. Basit işlemler milisaniye ölçeğinde kalabilirken, derin hesaplamalar, rotasyon yoğun işlemler veya bootstrapping gibi maliyetli adımlar kullanılan donanım, şema, parametre seti ve kütüphane optimizasyonuna bağlı olarak saniye ölçeğine veya daha yüksek sürelere çıkabilir.

Platform veya araç olarak Microsoft SEAL ya da OpenFHE benchmark suite kullanılabilir. Amaç, FHE’nin gerçek performans maliyetini kendi donanım ölçeğinde görmek ve akademik benchmark değerleriyle kendi ortamındaki değerler arasındaki farkı anlamaktır. Bu çalışma yalnızca izole test ortamında, gerçek üretim verisi ve üretim anahtarı kullanılmadan yapılmalıdır.

Beklenen çıktı, şema, parametre seti ve donanıma bağlı olarak değişen işlem süreleridir. Bazı işlemler milisaniye ölçeğinde hızlı görünebilirken, çarpma derinliği yüksek hesaplamalar, rotasyonlar ve destekleniyorsa bootstrapping gibi maliyetli adımlar saniye ölçeğine veya daha yüksek sürelere çıkabilir.

Öğrenci özellikle güvenlik parametresinin hangi değerde seçildiğine, polynomial modulus degree ve coefficient modulus değerlerinin hangi güvenlik seviyesine karşılık geldiğine, multiplicative depth sınırına ve bunun hesaplama karmaşıklığını nasıl kısıtladığına bakmalıdır.

Ayrıca benchmark çıktısı yorumlanırken bootstrapping’in kullanılıp kullanılmadığı, batching/packing desteğinin açık olup olmadığı, ölçülen işlemin gerçek uygulama yükünü temsil edip etmediği ve aynı testin kendi donanımında tekrarlanıp tekrarlanmadığı özellikle not edilmelidir.

Benchmark değerleri, kütüphanenin belgelediği referans değerlerle tutarlıysa ve işlemler belirtilen parametre setiyle sorunsuz tamamlanıyorsa bu beklenen bir durumdur. Ancak benchmark varsayılan güvenlik parametresinden daha düşük bir ayarla çalışıyorsa, örneğin düşük polynomial degree veya açıkça test amaçlı bir “insecure” yapılandırma kullanıyorsa, sonuçlar gerçek üretim senaryosunu yansıtmaz.

Benchmark’ın başarılı çalışması, kütüphanenin üretime hazır olduğu anlamına gelmez. Bu yalnızca belirli işlemlerin belirli parametrelerle çalışabildiğini ve performans hakkında ön fikir verdiğini gösterir. “Makalede 50 ms yazıyor, neden bizim sistemde 5 saniye?” sorusunun cevabı çoğu zaman donanım, parametre seti, batching kullanımı, optimizasyon, derleme ayarları ve gerçek hesaplama modelindeki farklarda saklıdır.

ABE ve IBE Kütüphaneleri: Olgunluk Sorgulaması

CP-ABE veya IBE için kullanılabilecek çeşitli açık kaynak kütüphaneleri mevcuttur. Charm-Crypto ve OpenABE gibi araçlar akademik prototipleme veya kavram doğrulama için incelenebilir. Ancak bu tür kütüphaneleri değerlendirirken “çalışıyor” olmaları ile “üretim için güvenli ve olgun” olmaları arasındaki fark açık tutulmalıdır.

Platform veya araç olarak GitHub depoları, belge sayfaları, issue kayıtları, release notları ve varsa akademik referanslar incelenebilir. Amaç, ABE/IBE kütüphanelerinin üretim olgunluğunu, son güncelleme tarihini, güvenlik denetimi varlığını, bilinen sınırlamalarını ve üretim uyarılarını değerlendirmektir. Bu çalışma belge ve kod incelemesi seviyesinde kalmalı; gerçek üretim sistemine entegrasyon ancak ayrı güvenlik değerlendirmesi sonrasında düşünülmelidir.

Beklenen çıktı; son commit tarihi, açık issue’ların niteliği, güvenlik denetimi belgesi, lisanslama durumu, üretim kullanımına ilişkin uyarı ifadeleri ve implementasyonun hangi akademik referansa dayandığıdır. Öğrenci özellikle “experimental”, “not recommended for production use”, “research only” gibi ifadeleri aramalıdır. Ayrıca algoritma implementasyonunun dayandığı akademik referansın zaman içinde yeni kriptoanalizlerle zayıflayıp zayıflamadığı da kontrol edilmelidir.

Aktif bakım, açık güvenlik bildirimlerine zamanında yanıt, net lisanslama, güncel belgeler ve güvenli kullanım kılavuzu olumlu sinyallerdir. Buna karşılık son commit’in çok eski olması, açık güvenlik issue’larının yanıtsız kalması, bağımsız denetim belgesinin bulunmaması, yan kanal güvenliğine dair hiçbir açıklama olmaması ve üretim uyarılarının belirsizliği riskli sinyallerdir.

Fonksiyonel doğruluk, kriptografik güvenlik anlamına gelmez. Bir ABE veya IBE kütüphanesi örnek veriyi başarıyla şifreleyip çözebilir; fakat parametre seçimi, yan kanal dayanıklılığı, revocation modeli, anahtar yaşam döngüsü, PKG güveni veya erişim politikası güncelleme mekanizması hâlâ üretim açısından yetersiz olabilir.

İleri Seviye Güvenli Analiz / Kontrol Listesi

Bu modülde araştırma ufkunu değerlendiren bir güvenlik uzmanı ya da geliştirici, aşağıdaki çerçeveyi referans alabilir.

Hazırlık aşamasında önce şu soruların cevabı aranmalıdır: Bu yapı hangi problemi çözüyor? Bu problem mevcut sistem için gerçekten kritik mi? Daha olgun seçenekler, örneğin TLS 1.3, AEAD, iyi tasarlanmış anahtar yönetimi, ZKP veya standartlaşmış PQC yapıları neden yeterli değil? Değerlendirmeye alınan araç veya kütüphane hakkında bağımsız denetim, standart kuruluşu değerlendirmesi veya güvenilir teknik dokümantasyon bulunabiliyor mu?

Kontrol edilecek noktalar arasında kütüphanenin standartlaşma durumu, son güncelleme tarihi, güvenlik parametrelerinin seviyesi, bu parametrelerin hedef güvenlik düzeyine etkisi, API’nin güvenli ve tehlikeli kullanımları ayırıp ayırmadığı, performans değerlerinin hangi koşullarda ölçüldüğü ve belgelendirilmiş sınırlamaların ne olduğu yer alır.

Güvenli doğrulama için kütüphanenin test vektörü desteği sorgulanmalı, mümkünse belgelenmiş bir referans implementasyonla karşılaştırma yapılmalı ve güvenlik denetim raporuna erişilmeye çalışılmalıdır. Bu rapor varsa hangi sürümü kapsadığı, hangi bileşenleri incelediği ve bulunan sorunların kapatılıp kapatılmadığı değerlendirilmelidir.

Not alınacak gözlemler arasında performans ölçümleri, hangi edge case’lerin test edildiği, kütüphanenin bakım topluluğunun aktifliği, yan kanal güvenliğine ilişkin belge varlığı, üretim uyarıları, lisanslama durumu ve güvenlik açığı bildirim süreci yer almalıdır.

Kaçınılması gereken yanlış varsayımlar da açık biçimde tanımlanmalıdır. Bir yapının araştırma makalesinde önerilmiş olması onun üretim için güvenli olduğu anlamına gelmez. Bir benchmark değerinin iyi görünmesi, kendi donanım ve veri ölçeğinde aynı performansın alınacağı anlamına gelmez. Bir kütüphanede üretim uyarısı bulunmaması, onun tam olgunlukta olduğu anlamına gelmez. Bir prototipin çalışması, yan kanal güvenliği, anahtar yönetimi, hata işleme ve operasyonel bakım katmanlarının hazır olduğunu göstermez.

Geliştirici ve güvenlik ekibine öneri yazarken olgunluk değerlendirmesi net biçimde aktarılmalıdır. Örneğin şu tarz bir değerlendirme kurumsal karar için daha sağlıklıdır:

“Bu yapı teknik olarak mümkündür ve belirli kullanım senaryolarında değer taşır. Ancak şu an için mevcut kütüphanelerin bağımsız denetimi tamamlanmamış, performans sınırları bizim ölçeğimizde kabul edilemez düzeyde ve güvenli parametre seçimi uzman kriptograf incelemesi gerektiriyor. Daha olgun alternatifler mevcut olduğu sürece bu alanı araştırma takibi olarak devam ettirmeyi öneririz.”

Bu yaklaşım hem teknik dürüstlüğü hem de uzun vadeli kriptografik vizyonu korur.

Analitik Senaryo

Durum: Bir FinTech startupı olan “FinProto”, kendi mobil uygulamasında FHE tabanlı bir “mahremiyet odaklı kredi skoru hesaplama” özelliği geliştirmek istemektedir. Hedef, kullanıcının gelir ve harcama verilerinin bankaya açık biçimde gönderilmeden, yalnızca şifreli haliyle işlenerek kredi skoru üretilmesidir. Güvenlik mimarisi değerlendirmesine dahil edilen security_engineer, bu mimarinin uygulanabilirliğini sorgulamak üzere çalışmaya başlar.

İlk değerlendirme şudur: Fikir teorik açıdan doğrudur. FHE’nin amacı tam da bu tür hesaplamaları şifreli veri üzerinde yapabilmektir. Ancak “teorik olarak mümkün” ile “şu an için ürüne hazır” arasında ciddi bir fark olabilir. Bu fark değerlendirilmeden mimari karar verilirse, proje teknik olarak etkileyici ama operasyonel olarak başarısız bir yöne gidebilir.

Kontrol edilecek ilk nokta, kredi skoru hesaplama modelinin karmaşıklığıdır. Model basit doğrusal bir skorlama formülü mü, karar ağacı mı, gradient boosting benzeri bir yapı mı, yoksa derin öğrenme tabanlı bir model mi? Hangi FHE şeması öneriliyor? CKKS mi kullanılacak, çünkü kayan noktalı ve yaklaşık hesaplama mı gerekiyor? Yoksa BFV/BGV gibi tamsayı modüler aritmetiğe daha uygun bir yapı mı gerekecek? Hesaplama kullanıcı cihazında mı, sunucu tarafında mı yapılacak? Mobil uygulama için kabul edilebilir gecikme süresi nedir?

İncelenecek çıktı, OpenFHE veya Microsoft SEAL gibi bir kütüphaneyle izole test ortamında gerçekçi bir kredi skoru modeline yakın sentetik hesaplamanın çalıştırılmasıdır. Bu test LOCAL-CRYPTO01 benzeri bir izole makinede yapılabilir. Kütüphanenin güvenlik denetimi, son commit tarihi, release politikası, bilinen sınırlamalar dokümanı ve parametre önerileri ayrıca incelenmelidir.

Güvenli doğrulama yaklaşımı, yalnızca “demo çalıştı” sonucuna bakmamalıdır. Benchmark, gerçek kredi skoru hesaplama karmaşıklığını temsil eden sentetik ama anlamlı bir model üzerinde çalıştırılmalıdır. Gecikme mobil kullanıcı deneyimi için kabul edilebilir mi? CKKS kullanılacaksa yaklaşık hata aralığı kredi skoru kararını etkileyebilir mi? Bu hata bazı kullanıcılar için farklı kredi kararlarına yol açabilir mi? Böyle bir fark regülasyon, açıklanabilirlik ve adalet açısından sorun doğurur mu?

Benchmark’ta “50 milisaniyede çalıştı” gibi bir sonuç görülürse bu sonucun hangi koşullarda üretildiği sorgulanmalıdır. Bu değer araştırma demosunda çok basitleştirilmiş bir model için, optimize bir donanımda, düşük güvenlik parametresiyle veya gerçek uygulamadan farklı veri boyutuyla ölçülmüş olabilir. Gerçek kredi skoru modelinde, mobil cihaz benzeri kısıtlı donanımda veya hedef güvenlik parametreleriyle sonuç çok farklı olabilir.

Riskin pratik karşılığı açıktır. FHE seçilir, geliştirme tamamlanır; fakat ürün lansmanında hesaplama süresi kullanıcı için kabul edilemez hale gelir. Örneğin 30-60 saniyelik gecikme mobil ürün için pratik olmayabilir. Kütüphane bağımsız denetimden geçmemişse regülatör veya kurumsal müşteri güvenlik onayı vermeyebilir. CKKS’in yaklaşık hata aralığı bazı kullanıcılar için yanlış veya tartışmalı kredi kararlarına yol açarsa, bu yalnızca teknik değil hukuki ve etik bir sorun haline gelebilir.

Kısa vadede mimari, kullanım amacına göre daha olgun gizlilik teknikleriyle değerlendirilebilir. Toplu analiz, raporlama veya model iyileştirme amacı varsa differential privacy tabanlı yöntemler anlamlı olabilir. Tekil kullanıcı skoru hesaplanacaksa, dikkatli tehdit modeliyle tasarlanmış TEE tabanlı yaklaşımlar, istemci taraflı hesaplama veya hibrit mimariler incelenebilir. FHE tabanlı yaklaşım ise performans, doğruluk, denetim olgunluğu ve kütüphane ekosistemi izlenerek araştırma hattında tutulabilir.

Bu yaklaşım, kısa vadede gerçekçi üretim hedeflerini korurken uzun vadeli vizyonu da kaybetmez. “FHE hazır olduğunda geçiş planımız şudur” ifadesini içeren bir crypto agility belgesi hazırlanması, hem teknik gerçekliği hem de stratejik yönü birlikte yönetmeyi sağlar.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

Homomorfik şifreleme (HE) Şifreli veri üzerinde, şifre çözülmeden aritmetik işlem yapılmasına olanak tanıyan şifreleme modeli.

Kısmen homomorfik şifreleme (PHE) Yalnızca toplama ya da çarpma gibi sınırlı işlem türlerini destekleyen homomorfik şifreleme.

Tam homomorfik şifreleme (FHE) Hem toplama hem çarpma dahil genel hesaplamayı şifreli veri üzerinde desteklemeyi hedefleyen şifreleme modeli.

CKKS Yaklaşık aritmetik üzerine kurulu FHE şeması; gerçek veya karmaşık sayılar üzerinde yaklaşık hesaplamalar için kullanılır.

BFV Tam sayı modüler aritmetiği üzerine kurulu FHE şeması.

BGV BFV ile benzer biçimde modüler aritmetik kullanan, ancak gürültü/modüler azaltma stratejileri farklı olan FHE şeması.

Multiplicative depth FHE devrelerinde zincirleme çarpma işlemlerinin maksimum derinliği; bu sınır aşıldığında gürültü birikimi hesaplamayı başarısız hale getirebilir.

Fonksiyonel şifreleme (FE) Özel bir fonksiyon anahtarıyla yalnızca belirli bir fonksiyonun şifreli veri üzerinde hesaplanmasına olanak tanıyan şifreleme modeli.

Kimlik tabanlı şifreleme (IBE) Açık anahtarın e-posta gibi bir kimlik dizisine karşılık geldiği şifreleme modeli; merkezi PKG gerektirir.

PKG (Private Key Generator) IBE sistemlerinde tüm özel anahtarları üreten merkezi güven otoritesi; escrow riski taşır.

Öznitelik tabanlı şifreleme (ABE) Erişim politikası ve öznitelikler üzerine kurulu, politikayı karşılayan özniteliklere sahip kullanıcıların şifreyi çözebildiği şifreleme modeli.

CP-ABE Şifreli metin politikalı ABE; erişim politikası şifreli metne, kullanıcı öznitelikleri özel anahtara bağlıdır.

KP-ABE Anahtar politikalı ABE; öznitelikler şifreli metne, erişim politikası özel anahtara bağlıdır.

Kör imza (Blind Signature) İmzacının mesaj içeriğini görmeden imzalamasına olanak tanıyan kriptografik yapı.

Grup imzası (Group Signature) Grup üyesinin kimliğini gizleyerek grup adına imza atmasına, grup yöneticisinin ise gerektiğinde anonimliği kaldırabilmesine olanak tanıyan yapı.

Ring imzası (Ring Signature) Dinamik halka içindeki bir üyenin kimliği gizlenerek imza oluşturmasına olanak tanıyan, merkezi açma otoritesi bulunmayan anonim imza yapısı.

Denetlenebilir anonimlik Anonimliğin yetkili bir tarafça kaldırılabildiği gizlilik modeli; grup imzasında karşımıza çıkar.

Olgunluk değerlendirmesi Bir kriptografik yapı veya aracın standartlaşma, denetim, performans, bakım ve üretim kullanımı açısından hazır olup olmadığını değerlendirme süreci.

Escrow riski Bir kripto sisteminde merkezi bir tarafın kullanıcı gizli bilgilerine erişebildiği yapısal güven sorunu; IBE’deki PKG buna örnektir.

Revocation (iptal) Şifreli sistemlerde bir kullanıcının yetkisinin geri alınması; ABE’de operasyonel olarak zor bir problemdir.

Benchmark (kripto bağlamında) Bir algoritma veya kütüphanenin belirli işlem tiplerindeki performansını ölçen test; donanım, parametre ve şema bağlamından bağımsız yorumlanamaz.

Kendini Değerlendir — İleri Kriptografi Modül 10

Bu Modülde Neler Öğrendik?

Bu modül, ileri kriptografi eğitiminin hem en geniş hem de en temkinli ele alınması gereken bölümlerinden biridir. Burada öğrenilenler yalnızca yeni kavramlar değildir; aynı zamanda bu kavramlar hakkında doğru değerlendirme çerçevesini kurma becerisidir.

Homomorfik şifrelemenin “şifreli veri üzerinde hesaplama” fikrinin ne anlama geldiği, CKKS, BFV ve BGV şemalarının farklı veri tiplerindeki uygunluğu ve FHE’nin bugün için performans sınırlarının neden birçok üretim senaryosunda ciddi fizibilite çalışması gerektirdiği netleşmiş oldu. CKKS’in yaklaşık hesaplama özelliğinin yalnızca performans değil, hata toleransı, doğruluk ve uygulama katmanı değerlendirmesi açısından da önemli olduğu görüldü.

Fonksiyonel şifrelemenin klasik all-or-nothing şifreleme modelinden nasıl ayrıldığı, IBE’nin neden merkezi güven sorunu taşıdığı ve CP-ABE/KP-ABE ayrımının erişim politikası tasarımında neden önemli olduğu açıklığa kavuştu. ABE’nin teorik zarafetine rağmen revocation, performans, anahtar yönetimi ve politika güncelleme sorunları nedeniyle neden büyük ölçüde araştırma ve sınırlı uygulama alanlarında kaldığı da değerlendirilmiş oldu.

Kör imza, grup imzası ve ring imzasının birbirinden ayrılan anonimlik ve hesap verebilirlik modelleri öğrenildi. Kör imzaların dijital nakit ve bazı e-oy/token sistemlerinde, grup imzalarının denetlenebilir anonimlik gerektiren kurumsal kimlik ve yetki senaryolarında, ring imzalarının ise Monero gibi gizlilik odaklı kripto para sistemlerinde karşımıza çıkabileceği görüldü.

Bu modülün en değerli kazanımı, olgunluk değerlendirmesi çerçevesidir. “Teknik olarak mümkün” ile “üretim için uygun” arasındaki fark; standartlaşma durumu, bağımsız denetim, performans kabul edilebilirliği, bakım sağlığı, güvenli parametre seçimi ve gerçek dağıtım deneyimi gibi somut ölçütlerle değerlendirilmelidir. Araştırma araçlarını prototipleme bağlamında okumak ve bu bulguları geliştirici veya yönetim ekibine gerçekçi bir çerçevede aktarabilmek, ileri kriptografi uzmanlığının temel parçalarından biridir.

Bu noktayla birlikte ileri kriptografi eğitimi; formal güvenlik modellerinden başlayıp ileri simetrik kriptografi, açık anahtar sistemleri, protokol güvenliği, ZKP, MPC, anahtar yönetimi, post-kuantum kriptografi ve araştırma ufkunu kapsayan bütünlüklü bir bakış açısıyla tamamlanmış olur.

bu da ileri kriptografi