Tarihsel Gelişim

Kriptografinin kökleri binlerce yıl öncesine dayanır. Antik Roma’da Julius Caesar’ın mesajlarını alfabede birkaç harf kaydırarak ilettiği yöntem bugün Sezar şifresi olarak bilinir. Orta Çağ’da ve sonrasında polialfabetik şifreler, tekdüze harf kaydırmanın yarattığı zayıflığı gidermek amacıyla geliştirildi. Vigenère şifresi bu dönemin önemli örneklerinden biridir.

20. yüzyılın başlarında mekanik ve elektromekanik şifreleme makineleri ortaya çıktı. İkinci Dünya Savaşı’nda Almanya’nın kullandığı Enigma makinesi, dönemin en bilinen ve kriptografi tarihinde en etkili elektromekanik rotor tabanlı şifreleme sistemlerinden biriydi. Enigma’nın çözülmesine giden süreçte Polonyalı kriptanalistlerin erken çalışmaları ve daha sonra Bletchley Park’ta Alan Turing dâhil birçok araştırmacının katkıları, hem kriptanalizin hem de erken bilgisayar biliminin tarihini etkiledi.

Enigma’nın “kırılamaz” olduğu yönündeki anlatımlar zaman zaman abartılıdır. Enigma güçlü bir sistemdi; ancak güvenlik açıkları yalnızca matematiksel zayıflıklardan değil, kullanım hatalarından, tekrarlayan mesaj formatlarından, operasyonel ihmalden ve insan faktöründen de kaynaklanıyordu. Bu ders günümüzde de geçerlidir: iyi bir algoritmayı yanlış kullanmak, algoritmayı kötü seçmek kadar ciddi sonuçlar doğurabilir.

Klasik kriptografide güvenlik çoğu zaman yöntemin, anahtarın ya da kullanılan dönüşüm kurallarının gizli kalmasına dayanıyordu. Modern kriptografiye geçişte bu anlayış köklü biçimde değişti. 1970’lerden itibaren, özellikle Diffie ve Hellman’ın açık anahtarlı kriptografi ve anahtar değişimi fikrini kamuya açık biçimde ortaya koymasıyla birlikte kriptografi daha güçlü bir matematiksel zemine oturdu. Artık algoritma açıkça bilinebilir; güvenlik, algoritmanın gizliliğinden değil, matematiksel zorluktan ve anahtarın gizliliğinden gelir.

Bu anlayış Kerckhoffs İlkesi ile özetlenir: bir sistem, algoritması düşman tarafından bilinse bile anahtarı gizli kaldığı sürece güvenli olmalıdır. Bu ilke, modern güvenli sistem tasarımının temel kabullerinden biridir.

Bu geçiş, kriptografiyi el yordamıyla geliştirilen gizli yöntemler dünyasından standartlaştırılmış, matematiksel olarak analiz edilebilir ve kamuya açık algoritmalara dayanan bir mühendislik disiplinine dönüştürdü. Bugün kullanılan AES gibi simetrik şifreleme algoritmaları, RSA ve eliptik eğri tabanlı açık anahtarlı yöntemler, SHA-2/SHA-3 gibi hash fonksiyonları ve yeni nesil post-quantum standartlar açık biçimde yayımlanır, incelenir ve kriptanaliz sürecinden geçirilir. NIST’in 2024’te yayımladığı ML-KEM, ML-DSA ve SLH-DSA standartları, modern kriptografinin kuantum sonrası döneme de hazırlanmaya başladığını gösterir.

Temel Güvenlik Hedefleri

Kriptografinin çözdüğü problemler tek bir başlık altında toplanamaz. Farklı güvenlik ihtiyaçları, farklı kriptografik mekanizmalar gerektirir. Bu nedenle gizlilik, bütünlük, kimlik doğrulama ve inkâr edememe hedeflerini birbirinden net biçimde ayırt etmek, tüm kriptografi eğitiminin kavramsal omurgasını oluşturur.

Gizlilik, verinin yalnızca yetkili taraflarca okunabilmesi güvencesidir. HTTPS üzerinden bir sağlık uygulamasına bağlandığınızda, taşınan verinin ağ üzerindeki üçüncü kişiler tarafından okunamaması gizlilik hedefine karşılık gelir. Gizlilik genellikle şifreleme ile sağlanır; ancak güvenli bir gizlilik tasarımı yalnızca algoritma seçimine değil, anahtar yönetimine, doğru çalışma moduna, protokol tasarımına ve kimlik doğrulamasına da bağlıdır. Şifreleme tek başına diğer güvenlik hedeflerini otomatik olarak karşılamaz.

Bütünlük, verinin iletim ya da depolama sırasında değiştirilmediğinin doğrulanabilmesidir. Bir yazılım güncellemesini indirdiğinizde, indirilen dosyanın orijinal dosyayla aynı olup olmadığını kontrol etmek için hash değeri karşılaştırılabilir. Ancak hash değerinin güvenilir bir kaynaktan alınması gerekir. Saldırgan hem dosyayı hem de hash değerini değiştirebiliyorsa yalnızca hash karşılaştırması yeterli olmayabilir. Bu durumda dijital imza ya da MAC gibi mekanizmalar devreye girer. Bütünlük kontrolü, şifrelemenin olmadığı durumlarda da gerekli olabilir; çünkü bir verinin okunabilir olması, onun değiştirilip değiştirilmediğinin önemsiz olduğu anlamına gelmez.

Kimlik doğrulama, iletişim kurulan tarafın gerçekten iddia ettiği kişi ya da sistem olduğunun doğrulanmasıdır. Bir web sitesine bağlandığınızda tarayıcı, sunucunun sunduğu sertifikanın bağlanılan alan adı için geçerli olup olmadığını ve güvenilir bir sertifika zincirine bağlanıp bağlanmadığını kontrol eder. TLS 1.3 el sıkışması, tarafların anahtar materyali üretmesini ve en azından sunucu taraflı kimlik doğrulama yapılabilmesini sağlayan bir authenticated key exchange yapısıdır.

Kimlik doğrulama olmadan şifreleme yanıltıcı olabilir. Çünkü yanlış kişiyle ya da sahte bir sistemle güvenli kanal kurmuş olabilirsiniz. Bu durumda kanal teknik olarak şifreli görünse bile güvenli iletişim hedefi gerçekleşmemiş olur.

Kimlik doğrulama ile yetkilendirme sıkça karıştırılır. Kimlik doğrulama “bu kişi ya da sistem kim?” sorusunu yanıtlar. Yetkilendirme ise “bu kişi ya da sistem neye erişebilir?” sorusuyla ilgilenir. Kriptografi kimlik doğrulamaya katkı sağlar; ancak yetkilendirme politikalarının kendisi doğrudan kriptografik bir mekanizma değildir.

İnkâr edememe, bir tarafın daha önce gerçekleştirdiği bir eylemi ya da gönderdiği bir mesajı sonradan inkâr etmesini zorlaştıran güvenlik hedefidir. Dijital imzalar bu hedefe katkı sağlar. Bir sözleşme dijital olarak imzalandığında, imzanın ilgili özel anahtarla üretildiği doğrulanabilir. Ancak inkâr edememe gücü yalnızca matematiksel imzaya değil; özel anahtarın korunmasına, sertifika altyapısına, zaman damgasına, iptal durumuna ve ilgili hukuki/operasyonel sürece de bağlıdır.

Bu dört hedef birbirini tamamlar ve çoğu gerçek sistemde birden fazlasına aynı anda ihtiyaç duyulur. Yalnızca gizlilik sağlamak, verinin değiştirilmediğini garanti etmez. Yalnızca bütünlük sağlamak, içeriği gizli tutmaz. Yalnızca kimlik doğrulama yapmak, verinin her koşulda güvenli saklandığı anlamına gelmez. Gerçek güvenlik, ihtiyaca göre bu hedeflerin birlikte tasarlandığı sistemlerde ortaya çıkar.

Temel Terminoloji

Kriptografi alanında belirli terimler çok sık tekrarlanır ve bunların farklı anlamlarda kullanılması ciddi kavram karmaşasına yol açar. Bu terimleri başından doğru tanımlamak, ilerleyen modüllerde gereksiz kafa karışıklığını önler.

Düz metin, şifrelenmemiş, orijinal haliyle okunan veridir. Bir e-posta mesajı, bir belge ya da bir paket içindeki veri düz metin olarak tanımlanabilir. Bir iletinin şifrelenmeden önceki ya da şifresi çözüldükten sonraki hali de düz metindir.

Şifreli metin, bir şifreleme algoritması uygulanmış ve artık orijinal anlamı doğrudan okunamayan veridir. Şifreli metnin içeriğini anlamlandırmak için doğru algoritma, doğru anahtar ve doğru kullanım bağlamı gerekir.

Anahtar, kriptografik işlemleri kontrol eden parametredir. Simetrik kriptografide aynı gizli anahtar şifreleme ve çözme işlemlerinde kullanılır. Açık anahtarlı kriptografide ise herkese açık olabilen bir public key ve gizli tutulması gereken bir private key bulunur. Modern kriptografide güvenlik, algoritmanın gizliliğine değil, anahtarların doğru üretilmesine, saklanmasına ve kullanılmasına dayanır.

Algoritma, şifreleme, hash hesaplama, imza üretme ya da benzeri kriptografik işlemleri gerçekleştirmek için tanımlanmış matematiksel prosedürdür. AES, RSA ve SHA-256 birer algoritma ya da algoritma ailesi örneği olarak düşünülebilir; ancak bunlar aynı tür işlemi yapmaz. AES simetrik şifreleme için, RSA açık anahtarlı kriptografi işlemleri için, SHA-256 ise hash üretmek için kullanılır.

Protokol, birden fazla tarafın belirli bir güvenlik amacına ulaşmak için izlediği mesajlaşma adımlarının ve kuralların bütünüdür. TLS bir protokoldür; içinde birden fazla algoritma ve kriptografik mekanizma bir arada çalışır. Algoritma tek bir işlemi tanımlarken, protokol bu işlemleri koordineli biçimde bir araya getirir.

Kriptografik yapı taşı, daha karmaşık kriptografik sistemlerin kurulduğu temel işlemler ya da mekanizmalardır. Hash fonksiyonu, simetrik şifreleme algoritması, mesaj doğrulama kodu ve dijital imza mekanizması bunlara örnek verilebilir. Güvenli sistemler, bu yapı taşlarının doğru biçimde birleştirilmesiyle oluşturulur.

Algoritma, protokol ve sistem arasındaki fark özellikle önemlidir. Algoritma bir dönüşüm kuralıdır. Protokol, bu kuralların belirli bir amaç için düzenlenmiş halidir. Sistem ise protokol ve algoritmaların gerçek bir ortamda, gerçek bileşenlerle çalışan uygulamasıdır. Üçünün de kendi güvenlik gereksinimleri ve hata noktaları vardır. Güvenli bir algoritma seçmek, sistemin tamamının güvenli olduğu anlamına gelmez. Algoritmanın doğru uygulanması, anahtarın güvenli yönetilmesi, protokolün eksiksiz kurulması ve sistemin doğru yapılandırılması da aynı derecede kritiktir.

Kriptografi Araçlarına Genel Bakış

Kriptografi öğrenirken algoritmalar ve kavramlar kadar, bu kavramların gerçek araçlar üzerinde nasıl göründüğünü anlamak da değerlidir. Ancak araç kullanmak, komut ezberlemek anlamına gelmez. Eğitimin bu aşamasında araçların ne işe yaradığını, hangi kategoriye girdiğini ve çıktılarının nasıl yorumlanması gerektiğini anlamak hedeflenmektedir.

Kriptografik araçlar birkaç ana kategoriye ayrılabilir.

Komut satırı araçları terminal üzerinden çalışır ve doğrudan şifreleme, hash hesaplama, sertifika inceleme ya da TLS bağlantısı test etme gibi işlemler yapar. OpenSSL bunların en yaygın örneklerinden biridir. Hash hesaplamaktan sertifika oluşturmaya, TLS bağlantısı test etmekten simetrik şifreleme yapmaya kadar geniş bir işlev aralığına sahiptir. GnuPG ise açık/özel anahtar çiftleri oluşturmak, dosyaları şifrelemek ve dijital imza üretip doğrulamak için kullanılan bir araçtır.

Grafik arayüzlü ya da tarayıcı tabanlı araçlar, komut satırı bilgisi gerektirmeden kriptografik kavramları görselleştirir. CyberChef, encoding/decoding, hash hesaplama ve format dönüşümlerini görsel olarak incelemek için kullanılan eğitim dostu bir araçtır. Bu tür araçlar kavram öğrenmek için faydalıdır; ancak gerçek parolalar, gizli anahtarlar, tokenlar ya da kişisel veriler bu araçlara girilmemelidir.

Trafik analiz araçları ağ trafiğini yakalayıp incelemenizi sağlar. Wireshark, şifreli ve şifresiz trafiği gözlemlemenize, TLS el sıkışmasının üst düzey akışını görmenize ve protokollerin gerçek ortamdaki görünümünü kavramanıza yardımcı olur. Wireshark şifreli trafiğin tamamını kendiliğinden okunabilir hâle getirmez; fakat şifreli iletişimin ne zaman başladığını, hangi protokollerin kullanıldığını ve trafiğin genel yapısını anlamak için güçlü bir analiz aracıdır.

Kütüphaneler, yazılım geliştirme sürecinde kriptografik işlemleri uygulamak için kullanılır. Python’daki cryptography kütüphanesi ve libsodium gibi kütüphaneler yaygın kullanılan örneklerdir. Ancak düşük seviye kriptografik API’ler yanlış kullanıma açık olabilir. Bu nedenle mümkün olduğunda güvenli varsayımlar sunan yüksek seviye API’ler tercih edilmeli, “kendi kriptografini yazma” hatasından kaçınılmalıdır.

Çevrimiçi ya da tarayıcı tabanlı araçlara gerçek parolalar, anahtarlar, tokenlar ya da gizli veriler girilmemelidir. CyberChef gibi araçlar eğitim ve kavram gösterimi için değerlidir; ancak bu araçlara gerçek üretim verisi girmek ciddi bir güvenlik ihlaline yol açabilir. Bu eğitimde araçlar yalnızca kavramı anlamak, çıktıyı okumak ve yanlış yorumlama riskini fark etmek amacıyla kullanılacaktır.

Araçların komut sözdizimini ezberlemek bu eğitimin amacı değildir. Önemli olan bir araç çıktısına bakıldığında “bu bir hash mi, şifreli metin mi, Base64 mü, sertifika mı, anahtar mı?” sorusunu doğru yanıtlayabilmektir. Bu okuryazarlık, ilerleyen modüllerde sürekli kullanılacaktır.

Komut & Araç Okuryazarlığı

Bu modülde araç çıktısını ayrıntılı biçimde analiz etmeye henüz girilmese de, kriptografik araçların nasıl konumlandırılması gerektiğini göstermek için iki kavramsal örnek incelenecektir.

OpenSSL Üzerinden Algoritma İsimlerini Tanımak

Bir terminalde OpenSSL ile çalışıldığında, kullanılan komuta ve OpenSSL sürümüne bağlı olarak desteklenen algoritmalar, modlar, takma adlar veya cipher suite isimleri listelenebilir. Bu liste içinde AES gibi modern algoritmalar görülebilir. DES, RC4 ve benzeri eski algoritmalar ise özellikle OpenSSL 3.x ile birlikte legacy provider altında yer alabilir ve varsayılan yapılandırmada her zaman etkin olmayabilir. OpenSSL dokümantasyonu, legacy provider içinde yer alan algoritmaların yaygın olarak kullanım dışı kalmış, güvensiz kabul edilmiş ya da benzer nedenlerle eski kabul edilen algoritmalar olduğunu belirtir.

Bu örnekte amaç, OpenSSL’in hangi algoritmaları desteklediğini ezberlemek değil; algoritma adlarını okumayı, güvenli ve eski algoritmaları ayırt etmeye başlamayı ve araç çıktısının “önerilen güvenli algoritmalar listesi” anlamına gelmediğini kavramaktır. Bir algoritmanın araçta görünmesi, onun modern sistemlerde kullanılması gerektiği anlamına gelmez.

Örneğin aes-256-gcm ifadesinde aes algoritmayı, 256 anahtar uzunluğunu, gcm ise çalışma modunu belirtir. Buna karşılık des-cbc, des-ecb ya da rc4 gibi ifadeler modern güvenlik beklentileri açısından riskli veya kullanım dışı kabul edilen yapılara işaret eder. Araçlar geriye dönük uyumluluk nedeniyle eski algoritmaları gösterebilir; güvenli yapılandırma ise aracı kullanan kişinin doğru seçim yapmasını gerektirir.

OpenSSL çıktısında hem eski hem yeni algoritmaların görülebilmesi normaldir. Burada yapılması gereken, “araç destekliyor, o hâlde güvenlidir” sonucuna varmak değil; algoritmanın güncel güvenlik bağlamında önerilip önerilmediğini ayrıca değerlendirmektir. Bu fark, kriptografik araç okuryazarlığının en temel derslerinden biridir.

CyberChef Üzerinden Encoding ile Şifrelemeyi Ayırmak

CyberChef’te bir metin Base64 formatına dönüştürüldüğünde çıktı, orijinal metnin doğrudan okunmadığı bir görünüme kavuşur. Örneğin merhaba metni Base64’e dönüştürüldüğünde bWVyaGFiYQ== biçiminde görünebilir. Bu çıktı ilk bakışta anlaşılmaz gibi dursa da şifreli değildir.

Base64 bir encoding işlemidir. Encoding, veriyi belirli bir gösterim formatına dönüştürür; anahtar gerektirmez ve güvenlik sağlamaz. Aynı işlem ters yönde uygulandığında orijinal metin kolayca elde edilir. Bu nedenle “garip görünüyor, o hâlde şifrelenmiştir” düşüncesi yanlıştır.

Base64 çıktısının sonunda görülebilen = ya da == karakterleri, Base64 doldurma işaretleridir. Şifreli metinler de bazen Base64 formatında taşınabilir; ancak bu durum Base64’ün kendisini şifreleme yapmaz. Buradaki kritik ayrım şudur: Şifreleme gizlilik sağlamayı hedefler ve anahtar gerektirir; encoding ise verinin biçimini değiştirir ve güvenlik sağlamaz.

Bu örnek, kriptografi öğreniminin ilk kritik sezgilerinden birini kazandırır: okunmaz görünen her veri korunmuş veri değildir. Modül 2’de veri gösterimi, encoding, hashing ve şifreleme ayrımı daha ayrıntılı ele alınacaktır.

Temel Seviye Güvenli Kullanım / Kontrol Listesi

Bu aşamada henüz bir araç ya da sistem çalıştırılmıyor olsa da kriptografiyle ilk temas kurulan bu modülde bazı temel alışkanlıkları baştan yerleştirmek önemlidir.

Bir araç ya da hizmetle ilk kez karşılaşıldığında doğrudan kullanmadan önce “Bu araç ne yapar, ne yapmaz?” sorusu sorulmalıdır. Kriptografik araçlar genellikle birçok farklı işlevi bir arada sunar. Bu durum güçlü olduğu kadar risklidir; çünkü aynı araçla hem güvenli hem de yanlış bir işlem yapılabilir.

Bir çıktı görüldüğünde, bunun hash mi, şifreli metin mi, encoding mi, sertifika mı yoksa anahtar mı olduğuna dikkat edilmelidir. Format farkını ayırt etmeden yorum yapmak erken aşamada en sık yapılan hatalardan biridir.

Algoritma ismi ya da araç adı tanıdık gelse bile o algoritmanın güncel ve güvenli olup olmadığı ayrıca doğrulanmalıdır. MD5, DES veya RC4 gibi isimlerin hâlâ bazı araçlarda görülebilmesi onları modern sistemlerde güvenli yapmaz. Araç desteği ile güvenlik önerisi aynı şey değildir.

Bir çıktının her çalıştırmada değişip değişmediği de önemli bir gözlemdir. Hash fonksiyonları aynı girdi için aynı çıktıyı üretir. Modern şifreleme kullanımlarında ise aynı düz metnin aynı anahtarla tekrar şifrelenmesi durumunda, IV/nonce gibi değerlerin doğru kullanılması sayesinde çıktının tekrar etmemesi beklenir. Özellikle AES-GCM gibi AEAD modlarında nonce/IV tekrarları ciddi güvenlik riski doğurabilir. NIST SP 800-38D, GCM’yi authenticated encryption with associated data sağlayan bir mod olarak tanımlar; bu güvenlik, authentication tag doğrulaması ve doğru IV/nonce kullanımına bağlıdır.

Bu modülde akılda tutulması gereken üç temel yanılgı vardır. Birincisi, garip görünen verinin mutlaka şifrelenmiş olduğu varsayımıdır. İkincisi, araç listesinde görünen her algoritmanın güvenli olduğu düşüncesidir. Üçüncüsü ise şifrelemenin tek başına tüm güvenlik hedeflerini karşıladığı yanılgısıdır. Bu üç hata, kriptografi eğitiminin en başından itibaren fark edilmesi gereken temel kör noktalardır.

Bir sistemde hangi kriptografik mekanizmanın kullanıldığını anlatırken yalnızca “şifreli” demek yerine daha hassas ifadeler tercih edilmelidir. Örneğin “AES-GCM ile şifrelenmiş”, “SHA-256 ile özetlenmiş”, “HMAC ile bütünlük doğrulaması yapılmış” ya da “Base64 ile kodlanmış” gibi ifadeler daha doğrudur. Bu dil farkı, teknik yanlış anlaşılmaları önemli ölçüde azaltır.

Analitik Senaryo

Bir geliştirici, kurum içi bir uygulamada kullanıcıların oturum tokenlarını Base64 formatında bir cookie içinde sakladıklarını ve bu yöntemi “tokenları şifrelemek” olarak belgelediğini açıklamaktadır. Güvenlik farkındalığı eğitimine katılan bir çalışan bu durumu değerlendirmenizi istemektedir.

İlk değerlendirme şu olmalıdır: Dokümanda “şifrelenmiş” denmesine rağmen Base64 bir şifreleme yöntemi değildir. Dönüştürülen veri anahtar gerektirmeden kolaylıkla orijinal haline getirilebilir. Yani token içeriği yalnızca görsel olarak anlaşılmaz hâle getirilmiş, gerçek anlamda korunmamıştır.

Bu durumda cookie içindeki Base64 dizisinin herhangi bir araçla çözülüp orijinal token değerinin elde edilip edilemediği test edilmelidir. Token içinde kullanıcı kimliği, yetki bilgisi, oturum süresi ya da başka hassas veriler taşınıp taşınmadığı ayrıca incelenmelidir.

Tarayıcı geliştirici araçlarında cookie değeri görüntülendiğinde Base64 karakteristik görünümüyle eyJ... ya da bWV... gibi bir dizi olarak yer alabilir. Bu çıktı herhangi bir Base64 decoder ile okunabilir. Özellikle eyJ ile başlayan değerler çoğu zaman JSON yapısının Base64URL ile kodlanmış hâline işaret edebilir; bu da JWT benzeri yapılarda sık görülür.

Token içeriğinin gerçekten gizli kalması gerekiyorsa, uygun bir AEAD algoritmasıyla şifreleme yapılmalıdır. AES-GCM buna örnek verilebilir; ancak güvenlik yalnızca algoritma seçimine bağlı değildir. Nonce/IV tekrarının önlenmesi, authentication tag doğrulamasının doğru yapılması, anahtarın güvenli biçimde üretilip saklanması ve algoritmanın doğru bağlamda kullanılması gerekir. GCM, doğru kullanıldığında hem gizlilik hem de bütünlük doğrulamasına katkı sağlayan bir authenticated encryption modudur.

Token JWT ise ayrıca dikkatli olmak gerekir. İmzalı JWT bütünlük ve kaynağın doğrulanmasına yardımcı olur; ancak payload içeriğini gizlemez. İçeriğin gizli kalması gerekiyorsa JWE gibi şifreli token yapıları veya sunucu tarafında saklanan opaque session token yaklaşımı değerlendirilmelidir. RFC 8725, JWT’lerin imzalanabilen ve/veya şifrelenebilen URL-safe JSON tabanlı güvenlik tokenları olduğunu belirtir ve güvenli JWT kullanımında doğru algoritma seçimi, claim doğrulama ve anahtar yönetimi gibi konulara dikkat çeker.

Bu senaryodaki en yaygın yanlış düşünce, “okunmaz görünüyor, o hâlde güvenlidir” varsayımıdır. Geliştiricinin kasıtlı bir yanıltma yapmadığı, encoding ile şifrelemeyi karıştırdığı anlaşılmaktadır. Bu iyi niyetli ama riskli bir teknik bilgi eksikliğidir.

Riskin pratik karşılığı ciddidir. Eğer token içinde yetki bilgisi, kullanıcı kimliği ya da oturumla ilgili hassas bilgiler bulunuyorsa, bu değerleri elde eden bir saldırgan oturumun içeriğini anlayabilir ve bu bilgiyi kötüye kullanabilir. Base64 tek başına bütünlük doğrulaması da sağlamaz. Token üzerinde ayrıca imza, MAC veya doğrulanabilir bir bütünlük mekanizması yoksa saldırganın yaptığı değişiklikler güvenilir biçimde tespit edilemeyebilir.

Önerilen güvenli yaklaşım, tokenlarda taşınan bilginin minimize edilmesiyle başlar. Gereksiz hassas veri token içine konulmamalıdır. Token gerçekten gizlilik gerektiriyorsa uygun şekilde şifrelenmeli; bütünlük ve kaynak doğrulama gerekiyorsa imza veya MAC gibi mekanizmalar kullanılmalıdır. İletim HTTPS üzerinden yapılmalı, cookie kullanılıyorsa HttpOnly, Secure ve uygun SameSite ayarları tercih edilmeli, domain/path kapsamı gereksiz geniş tutulmamalıdır. OWASP, session cookie güvenliği bağlamında HttpOnly, Secure ve SameSite ayarlarının önemini özellikle vurgular.

Bu senaryo önce geliştiriciye “encoding ile şifrelemenin farkı” açıklanarak aktarılmalı, ardından somut düzeltme önerileri sunulmalıdır. Amaç kişiyi suçlamak değil, hatalı güvenlik varsayımını düzeltmek ve sistemi gerçekten korunur hâle getirmektir.

Kendini Değerlendir — Kriptografiye Giriş

Terimler Sözlüğü

Bu Modülde Neler Öğrendik?

Bu modül, kriptografi eğitiminin başlangıç noktası olarak birkaç kritik kavramsal temeli yerleştirdi.

Kriptografi, kriptanaliz ve kriptoloji kavramları birbirinden ayırt edildi. Bu ayrım, ilerideki modüllerde “neden bu yöntem yetersizdir?” ya da “bu saldırı nasıl işler?” sorularına cevap ararken kavramsal zemin sağlar.

Kriptografinin yalnızca şifreleme olmadığı anlaşıldı. Gizlilik, bütünlük, kimlik doğrulama ve inkâr edememe birbirinden farklı problemlere karşılık gelir ve her biri farklı mekanizmalar gerektirir. Bu ayrımı taşımayan biri, şifrelemenin bütünlük sağladığını ya da kimlik doğrulamayı otomatik olarak karşıladığını yanlış biçimde varsayabilir. Bu yanlışlık ilerleyen modüllerde somut güvenlik hataları olarak tekrar karşımıza çıkacaktır.

Tarihsel gelişim çizgisi, kriptografinin “gizli yöntemlere dayanan” eski anlayıştan, “matematiksel güce ve anahtar gizliliğine dayanan” modern anlayışa nasıl geçtiğini gösterdi. Kerckhoffs İlkesi bu geçişin simgesidir ve bugünkü güvenli sistem tasarımının temel varsayımlarından biridir.

Temel terminoloji olan düz metin, şifreli metin, anahtar, algoritma, protokol ve kriptografik yapı taşı doğru bağlamlarıyla tanındı. Özellikle algoritma, protokol ve sistem arasındaki fark kavrandı; birinin güvenli olmasının diğerlerini otomatik olarak güvenli yapmadığı vurgulandı.

Araç kategorileri ilk kez görüldü. OpenSSL, GnuPG, CyberChef ve Wireshark’ın hangi tür işlevlere hizmet ettiği anlaşıldı. Daha da önemlisi, araçlardaki algoritmalar listesinin “güvenli algoritmalar listesi” olmadığı; çevrimiçi araçlara gerçek veri girilmemesi gerektiği; ve araç kullanımının komut ezberinden değil, çıktıyı okuma ve yorumlama becerisinden oluştuğu kavrandı.

Encoding ile şifreleme farkı net biçimde yerleşti. Base64 güvenlik sağlamaz; sadece formatı değiştirir. Bu ayrımı bilmemek, pek çok gerçek güvenlik hatasının temelinde yatan kavramsal yanılgıdır.

Son olarak, kriptografinin hiçbir zaman tek başına bir güvenlik garantisi olmadığı anlaşıldı. Doğru algoritma seçimi, doğru kullanım, doğru anahtar yönetimi ve doğru sistem tasarımı bir arada olmadığında kriptografi boşa çalışır. Bu farkındalık, bu eğitimin tüm modülleri boyunca arka planda canlı tutulacaktır.

Bu modülde ayrıca “128 bit güvenlik” gibi ifadelerin ne anlama geldiği, brute force saldırısının neden bazı anahtar uzunluklarında pratik olmaktan çıktığı ve kriptografik sistemlerde rastgeleliğin neden kritik olduğu ele alınmaktadır. Modülün son bölümünde CyberChef gibi araçlar üzerinden encoding, hashing ve encryption çıktıları görsel olarak karşılaştırılacak; çıktı okuryazarlığı pekiştirilecektir.

Veri Gösterimi

Kriptografik sistemler, metinleri, resimleri ya da dosyaları insanın gördüğü biçimiyle işlemez; her şeyi bit ve byte dizisi olarak görür. Bu nedenle kriptografi öğrenirken verinin nasıl temsil edildiğini anlamak, algoritmaların ne yaptığını kavramadan önce gelir.

Bit ve byte, bu temsilin en temel parçalarıdır. En küçük veri birimi olan bit, yalnızca 0 ya da 1 değerini alır. Sekiz bitin bir araya gelmesiyle bir byte oluşur. Bir byte 256 farklı değer taşıyabilir; yani 0’dan 255’e kadar değer alabilir. Kriptografide anahtar uzunlukları, blok boyutları ve hash çıktıları genellikle bit cinsinden ifade edilir. “AES-256” derken kastedilen, 256 bit uzunluğunda bir anahtardır; bu da 32 byte anlamına gelir. AES’in blok boyutu ise anahtar uzunluğundan bağımsız olarak 128 bittir. NIST’in AES standardı, AES’in 128, 192 ve 256 bit anahtarlarla çalıştığını ve veriyi 128 bitlik bloklar halinde işlediğini belirtir.

Binary gösterim, her byte’ın sekiz 0 ve 1’den oluşan bir dize olarak ifade edilmesidir. Örneğin 65 sayısı binary’de 01000001 biçiminde görünür ve ASCII’de A harfine karşılık gelir. Kriptografik araçlar çoğu zaman bu ikili yapıyı doğrudan ekranda göstermez; bunun yerine daha okunabilir biçimler tercih eder.

Hexadecimal, yani hex gösterim, binary çıktıyı insanlar için daha kısa ve okunabilir hâle getirir. Hexadecimal her dört biti tek bir karakterle ifade eder ve 0–9 ile A–F arasındaki on altı sembolü kullanır. Bu nedenle bir byte, iki hex karakteriyle temsil edilir. Kriptografik araçların çıktılarında hash değerleri, anahtarlar, IV değerleri ve birçok ikili veri çoğu zaman hex biçiminde gösterilir. 3a7f gibi bir dizeyi gördüğünüzde bunun iki byte’lık veriyi temsil ettiğini bilmek, çıktı okuryazarlığının ilk adımlarından biridir.

Bu dönüşüm sabit bir kurala dayanır ve herhangi bir araçla doğrulanabilir. Hex çıktısında 41 gören biri, bunun ASCII A karakterinin karşılığı olduğunu bilirse çıktıyı daha bilinçli yorumlayabilir.

Blok, akış ve mesaj kavramları da veri gösterimiyle yakından ilişkilidir. Bazı şifreleme algoritmaları veriyi sabit boyutlu parçalar hâlinde, yani bloklar şeklinde işler. AES buna örnektir ve 128 bitlik bloklarla çalışır. Diğer bazı yapılar veriyi art arda bit ya da byte dizisi olarak işler; bunlara akış şifreleri denir. Mesaj ise şifrelenecek, imzalanacak ya da doğrulanacak orijinal veriyi tanımlamak için kullanılan genel bir terimdir.

XOR, yani exclusive OR işlemi, iki bit üzerinde uygulanan temel bir işlemdir. İki bit aynıysa sonuç 0, farklıysa sonuç 1 olur. XOR kriptografide çok yaygındır; çünkü hızlıdır, basittir ve birçok kriptografik yapının içinde temel işlem olarak kullanılır. One-time pad’in temel işlemi XOR’dur. Birçok modern algoritmanın iç yapısında da XOR tabanlı işlemler bulunur.

Mini örnek:

Düz metin biti   : 1
Anahtar biti     : 0
XOR sonucu       : 1

Düz metin biti   : 1
Anahtar biti     : 1
XOR sonucu       : 0

XOR’un önemli bir özelliği, aynı işlem tekrar uygulandığında orijinal değerin geri gelmesidir:

A XOR K = C
C XOR K = A

Bu terslenebilirlik özelliği, XOR’u şifreleme ve çözme işlemlerinde kullanışlı kılar. Ancak XOR kendi başına güvenli şifreleme değildir. Güvenlik, XOR işleminin kendisinden değil; onun tahmin edilemez, yeterince uzun ve doğru kullanılan bir anahtar akışıyla birleşmesinden gelir. Basit “XOR şifreleme” örnekleri çoğu zaman kolaylıkla kırılabilir.

Encoding ile encryption farkı, veri gösterimi konusunun en kritik ayrımlarından biridir. Encoding, veriyi farklı bir formatta temsil etmektir; gizlilik sağlamaz, anahtar gerektirmez ve geri çevrilebilir. Base64 ve hex birer encoding yöntemidir. RFC 4648, Base16, Base32 ve Base64 gibi temel encoding biçimlerini tanımlar.

Encryption ise bir anahtar ve algoritma kullanarak veriyi yetkisiz kişilerin anlayamayacağı biçime dönüştürür. Bu iki kavramın karıştırılması, gerçek güvenlik sistemlerinde ciddi hatalara yol açabilir.

Temel Matematiksel Kavramlar

Kriptografi, sezgisel olarak “ileri yönde kolay, ters yönde zor” kabul edilen matematiksel problemlere dayanır. Bu problemleri anlamak için doktora düzeyinde matematik gerekmez; ancak birkaç temel kavramı yerli yerine oturtmak, RSA ve Diffie-Hellman gibi konuların ilerleyen modüllerde neden çalıştığını anlamayı kolaylaştırır.

Modüler aritmetik, bir sayıyı başka bir sayıya böldüğümüzde kalan üzerinden işlem yapma sistemidir. 17 mod 12 = 5 ifadesi, 17’nin 12’ye bölümünden kalanın 5 olduğunu söyler. Bunu somutlaştırmak için saat örneği sık kullanılır: 12 saatlik bir sistemde saat 9’a 5 saat eklerseniz 14 değil 2 elde edersiniz; çünkü 14 mod 12 = 2 olur. Kriptografide modüler aritmetik sıkça karşımıza çıkar. RSA, Diffie-Hellman ve eliptik eğri tabanlı sistemlerin önemli bölümleri modüler işlemlerle ilişkilidir.

Asal sayılar, yalnızca 1 ve kendisiyle tam bölünebilen sayılardır. 2, 3, 5, 7, 11 ve 13 buna örnektir. RSA’da büyük asal sayılar anahtar üretiminin temelindedir. İki büyük asal sayının çarpımını hesaplamak kolayken, ortaya çıkan büyük sayıyı tekrar asal çarpanlarına ayırmak pratikte çok zordur. RSA’nın güvenlik sezgisi büyük ölçüde bu zorluğa dayanır.

Diffie-Hellman gibi yapılarda ise güvenliği yalnızca “asal sayı kullanılıyor” diye açıklamak eksik olur. Diffie-Hellman’ın güvenliği, uygun seçilmiş matematiksel gruplarda ayrık logaritma probleminin zorluğuyla ilişkilidir. Yani burada önemli olan sadece büyük sayılar değil, bu sayıların içinde kullanıldığı matematiksel yapının güvenli seçilmesidir.

EBOB, yani En Büyük Ortak Bölen, iki sayının ortak bölenlerinin en büyüğüdür. Kriptografide özellikle RSA anahtar üretiminde belirli değerlerin birbirine göreli asal olması gerekir. Göreli asal olmak, iki sayının EBOB’unun 1 olması anlamına gelir. Bu koşul, anahtar üretiminin matematiksel olarak düzgün çalışması için önemlidir.

Ters eleman, modüler aritmetikte bir sayıyla çarpıldığında sonuç 1 veren değerdir. Kriptografik işlemlerde hem şifreleme hem de çözme adımlarını mümkün kılan matematiksel yapı burada ortaya çıkar. Ters elemanın her sayı için var olmadığını bilmek bu aşama için yeterlidir; kriptografik parametreler bu koşulları sağlayacak şekilde seçilir.

Üs alma işlemleri ve kongrüans mantığı, açık anahtarlı kriptografide sık karşılaşılan kavramlardır. Modüler üs alma, yani a^e mod n biçimindeki işlemler, birçok kriptografik yapıda karşımıza çıkar. Bu işlem ileri yönde verimli biçimde hesaplanabilir; ancak tersine gitmek kullanılan sisteme göre çarpanlara ayırma, ayrık logaritma ya da benzeri zor matematiksel problemlere dönüşür. RSA’da güvenlik büyük sayıların çarpanlara ayrılmasının zorluğuyla; Diffie-Hellman’da ise uygun gruplarda ayrık logaritma probleminin zorluğuyla ilişkilidir.

Kongrüans ise iki sayının aynı modüle göre aynı kalanı verip vermediğini ifade eder. a ≡ b (mod n) gösterimi, a ve b sayılarının n modülüne göre aynı kalan sınıfında olduğunu anlatır.

Bu matematiksel kavramların hiçbirini formül ezberiyle öğrenmek gerekmez. Bu modül için önemli olan sezgidir: “Büyük sayıların çarpanlara ayrılması zordur, bu yüzden RSA belirli koşullarda güvenli kabul edilir” ya da “modüler üs alma ileri yönde kolaydır ama uygun gruplarda tersine gitmek zordur, bu yüzden Diffie-Hellman güvenli anahtar değişimi sağlayabilir.” Bu sezgiler, ilerleyen modüllerde algoritmaların neden çalıştığını anlamayı doğrudan kolaylaştırır.

Hesaplama ve Güvenlik Seviyesi

Kriptografik sistemler mutlak anlamda “kırılamaz” değildir. Daha doğru ifade şudur: güvenli kabul edilen bir kriptografik sistemi kırmak, mevcut ve öngörülebilir kaynaklarla pratik olmayacak kadar zor olmalıdır. Bu ayrım önemlidir. Güvenlik düzeyi genellikle bir saldırganın sistemi kırmak için kaç işlem yapması gerektiğiyle ifade edilir.

Brute force, anahtar bilinmeden şifrelenmiş bir veriyi çözmek isteyen saldırganın tüm olası anahtarları tek tek denemesidir. Anahtar ne kadar kısa olursa denenecek olasılık sayısı o kadar az olur ve saldırı o kadar pratik hâle gelir.

Anahtar uzayı, belirli uzunluktaki bir anahtarın alabileceği tüm olası değerlerin toplamıdır. 1 bitlik bir anahtarın yalnızca 2 olası değeri vardır: 0 ya da 1. 8 bitlik bir anahtarda 256 olasılık vardır. Her bit eklendiğinde olasılık sayısı iki katına çıkar. Bu büyüme doğrusal değil, üsteldir.

56 bitlik DES anahtarı, 1990’larda özel donanımla günler içinde kırılabilir hâle geldi. Bu nedenle DES modern sistemler için güvenli kabul edilmez. Güncel ve uzun ömürlü yeni tasarımlarda 128 bit güvenlik seviyesi güçlü ve yaygın bir hedef olarak kabul edilir. Bununla birlikte bazı standartlarda 112 bit güvenlik seviyesi belirli geçiş, uyumluluk veya sınırlı ömürlü kullanım bağlamlarında hâlâ yer alabilir. NIST SP 800-57, güvenlik gücü kavramını algoritma ve anahtar uzunluğuyla ilişkilendirir; örneğin RSA-2048’in yaklaşık 112 bit güvenlik gücü sağladığını, SHA-256’nın belirli kullanım bağlamlarında 128 bit güvenlik gücünü destekleyebildiğini belirtir.

Bit güvenliği, bir sistemi kırmak için gereken en iyi bilinen saldırının yaklaşık hesaplama maliyetini ifade eder. “128 bit güvenlik” denildiğinde, sistemi kırmak için yaklaşık 2¹²⁸ işlem gerektiği anlatılır. Bu sayı günümüz ve yakın gelecekte öngörülen klasik bilgisayar gücüyle pratikte gerçekleştirilemez kabul edilir.

Bir algoritmanın anahtar uzunluğu ile güvenlik düzeyi her zaman birebir örtüşmez. RSA-2048 yaklaşık 112 bit güvenlik sunarken AES-128, 128 bit güvenlik seviyesiyle ilişkilendirilir. Bu, “AES her koşulda RSA’dan daha güvenlidir” anlamına gelmez. Simetrik ve asimetrik algoritmalar farklı matematiksel problemlere dayanır; bu nedenle anahtar uzunlukları doğrudan karşılaştırılmamalıdır.

Polinomsal ve üstel büyüme sezgisi, brute force mantığını anlamak için önemlidir. Hesaplama süresi anahtar uzunluğuyla yalnızca doğru orantılı büyüseydi, daha uzun anahtar sadece biraz daha fazla deneme anlamına gelirdi. Ancak brute force maliyeti her ekstra bit için iki katına çıktığından, birkaç bit fark bile güvenlik açısından çok büyük bir mesafeye karşılık gelir. 40 bitten 128 bite geçmek, deneme sayısını yalnızca “biraz” değil, astronomik ölçekte artırır.

Rastgelelik Kavramına Giriş

Kriptografide rastgelelik, üretilecek değerin — anahtar, IV, nonce, salt ya da seed — saldırgan tarafından tahmin edilememesini sağlar. Bu, “karmaşık görünen” bir değer üretmekten çok daha zor bir problemdir.

Bir anahtar tahmin edilebilirse, o anahtarla yapılan şifrelemenin güvenliği fiilen ortadan kalkar. Aynı şekilde IV ya da nonce değerleri yanlış üretilirse veya aynı anahtar altında tekrar kullanılırsa, bazı şifreleme modlarında şifreli metinden bilgi sızabilir ya da bütünlük koruması zayıflayabilir. Burada önemli nokta şudur: IV ve nonce gereksinimi kullanılan moda göre değişir. Bazı modlarda IV’nin rastgele ve öngörülemez olması gerekirken, bazı modlarda asıl şart aynı anahtar altında tekrar kullanılmamasıdır. Özellikle CTR ve GCM gibi yapılarda nonce/IV tekrar kullanımı ciddi güvenlik riskleri doğurabilir. NIST SP 800-38D, GCM’yi authenticated encryption with associated data sağlayan bir mod olarak tanımlar; bu güvenlik doğru IV/nonce kullanımı ve doğrulama adımlarının doğru uygulanmasına bağlıdır.

Entropi, bilgi teorisindeki anlamıyla sistemdeki belirsizlik ya da öngörülemeyen bilgi miktarını ölçer. Kriptografik bir değer ne kadar çok entropiye sahipse, tahmin edilmesi o kadar zorlaşır. Bir işletim sistemi klavye zamanlamaları, donanım olayları, süreç durumları ve çeşitli çevresel kaynaklardan entropi toplayabilir; bu entropi rastgele sayı üretimi için kullanılır.

Rastgele sayı ile güvenli rastgele sayı aynı şey değildir. Pek çok programlama dilinde basit bir random() fonksiyonu bulunur. Bu fonksiyon oyun, simülasyon veya rastgele örnekleme gibi amaçlar için yeterli olabilir. Ancak bu değerler çoğu zaman deterministik bir algoritmaya dayanır ve başlangıç değeri, yani seed tahmin edilebilirse üretilen tüm seri öngörülebilir hâle gelebilir. Kriptografik amaçlar için bu tür rastgelelik yeterli değildir.

CSPRNG, yani Kriptografik Açıdan Güvenli Sözde Rastgele Sayı Üreteci, yeterli entropiyle başlatıldığında üretilen dizinin önceki çıktılardan hareketle tahmin edilmesini hesaplama açısından pratikte olanaksız hâle getirmeyi hedefler. NIST SP 800-90A, deterministik rastgele bit üreteçlerinin hash fonksiyonları veya blok şifreler gibi mekanizmalara dayanabileceğini belirtir.

İşletim sistemleri ve güvenilir kriptografi kütüphaneleri bu amaçla özel kaynaklar kullanır. Örneğin Linux sistemlerinde /dev/urandom veya modern sistem çağrıları, Windows’ta BCryptGenRandom, Python’da ise güvenlik tokenları ve benzeri sırlar için secrets modülü tercih edilir. Python belgeleri, secrets modülünün parola, hesap doğrulama ve güvenlik tokenları gibi değerler için kriptografik olarak güçlü rastgele sayılar üretmek amacıyla kullanılması gerektiğini; varsayılan random modülünün ise güvenlik veya kriptografi için tasarlanmadığını belirtir.

Rastgeleliğin anahtar, IV, nonce ve seed üretimindeki rolü kritiktir. Anahtar üretiminde zayıf rastgelelik kullanmak, anahtar uzunluğu ne kadar büyük olursa olsun sistemi tehlikeye atar. IV, kullanılan moda bağlı olarak rastgele, öngörülemez veya benzersiz olmalıdır. Nonce ise adından da anlaşılacağı üzere “bir kez kullanılan değer” anlamına gelir. Nonce rastgele üretilebilir ya da sayaç gibi deterministik bir yöntemle oluşturulabilir; kritik nokta aynı anahtar ve aynı kullanım bağlamı altında tekrar etmemesidir. Seed ise rastgele sayı üretecinin başlangıç durumunu belirler; seed tahmin edilebilirse üretilecek değerler de tahmin edilebilir hâle gelebilir.

Kriptografik değer üretirken dilin genel amaçlı random() fonksiyonlarını kullanmak yerine, platformun veya güvenilir kütüphanenin sunduğu CSPRNG tabanlı API’ler tercih edilmelidir. Bu seçim kod tabanında küçük bir fark gibi görünebilir; güvenlik açısından ise çok büyük bir fark yaratır.

Veri Gösterimi ve Dönüştürme Araçları

Modül 2’nin son bölümü, bu modülde öğrenilen kavramları araç çıktıları üzerinden pekiştirmeye yöneliktir. CyberChef gibi tarayıcı tabanlı araçlar; encoding, hashing ve encryption arasındaki farkı görsel olarak karşılaştırmak için pratik bir zemin sunar.

Bir araçta metin girip farklı encoding formatlarına dönüştürdüğünüzde şunu gözlemlersiniz: çıktı her formatta değişir, ancak bu dönüşümler geri alınabilir ve anahtar gerektirmez. Bu, encoding’in güvenlik sağlamadığını gösterir.

Aynı girdi için encoding, hashing ve encryption çıktıları farklı özelliklere sahiptir. Encoding çıktısı geri çevrilebilir. Hash çıktısı deterministiktir; aynı girdi için her zaman aynı çıktıyı üretir ve sabit uzunluktadır. Güvenli hash fonksiyonlarında çıktıya bakarak girdiyi pratikte bulmak zor olmalıdır; ancak giriş değeri kısa, düşük entropili veya tahmin edilebilir ise saldırgan olası girdileri deneyerek aynı hash değerine ulaşabilir. Şifreleme çıktısı ise kullanılan moda ve IV/nonce yönetimine bağlı olarak aynı girdi için her çalıştırmada farklı görünebilir ve yalnızca doğru anahtar ile çözülebilir.

Bir araç çıktısına bakarak doğrudan “bu şifrelenmiş” ya da “bu güvenli” sonucuna varmak doğru değildir. Bir Base64 dizesi şifreli metin gibi görünebilir; bir hash çıktısı şifrelenmiş veri zannedilebilir. Her iki yanılgı da gerçek sistemlerde güvenlik açığına dönüşebilir.

CyberChef gibi araçlar eğitim için çok faydalıdır; ancak çevrimiçi ya da tarayıcı tabanlı araçlarda gerçek parola, anahtar, token, kimlik bilgisi veya müşteri verisi kullanılmamalıdır. Eğitim çalışmalarında yalnızca uydurma ve anlamsız veriler tercih edilmelidir.

Komut & Araç Okuryazarlığı

Bu modülün odağı veri gösterimi ve format farkları olduğundan, CyberChef üzerinden encoding, hashing ve encryption çıktılarını karşılaştırmak doğrudan eğitim değeri taşır. Buradaki amaç komut ezberlemek değil; çıktının neyi temsil ettiğini anlamaktır.

Base64 ve SHA-256 Çıktısını Karşılaştırma

Bir metni aynı araçta önce Base64’e dönüştürdüğünüzü, ardından SHA-256 hash işleminden geçirdiğinizi düşünelim.

Platform olarak CyberChef gibi tarayıcı tabanlı bir eğitim ve dönüştürme aracı kullanılabilir. Bu işlemde gerçek kişisel veri, şirket verisi, parola, token ya da anahtar kullanılmamalı; yalnızca anlamsız ve uydurma metinlerle çalışılmalıdır.

Örnek:

Base64 çıktısının uzunluğu giriş uzunluğuyla ilişkili olarak değişir ve çıktı geri çevrilebilir. SHA-256 çıktısı ise 64 hex karakterden oluşur; bu da 256 bitlik, yani 32 byte’lık bir çıktı anlamına gelir. Aynı giriş her zaman aynı SHA-256 çıktısını üretir.

Burada öğrencinin özellikle görmesi gereken fark şudur: Base64 bir encoding işlemidir ve orijinal veriye geri döndürülebilir. SHA-256 ise bir hash fonksiyonudur; çıktı sabit uzunluktadır ve doğrudan geri çevrilebilir bir format dönüşümü değildir. Ancak bu, hashlenen girdinin her koşulda gizli kaldığı anlamına gelmez. Girdi tahmin edilebilir ise saldırgan aynı girdileri deneyerek aynı hash değerini bulabilir.

Bu örnek, “karmaşık görünen çıktı güvenlidir” yanılgısını kırmak için kullanılır. Base64 çıktısı karmaşık görünebilir ama şifreleme değildir. Hash çıktısı da şifreli metin değildir; başka bir kriptografik işlem türüdür.

XOR İşleminin Terslenebilirliğini Görmek

XOR işlemini destekleyen bir araçta iki binary değeri XOR’ladığınızda ve ardından aynı işlemi tekrar uyguladığınızda orijinal değerin geri geldiğini gözlemleyebilirsiniz.

Örnek:

Son satırda orijinal A değerinin geri gelmesi, XOR’un terslenebilirliğini gösterir. Bu, “şifreleme ve çözme aynı işlemle yapılabilir” sezgisinin çok basit bir modelidir.

Ancak bu deneyden “XOR kullandım, güvenli şifreleme yaptım” sonucu çıkarılmamalıdır. XOR güvenliği tek başına sağlamaz. One-time pad’de güvenlik, XOR işleminden değil; anahtar akışının gerçekten rastgele, mesaj kadar uzun, tek kullanımlık ve gizli olmasından gelir. Bu koşullar sağlanmadığında XOR tabanlı basit şifreleme örnekleri kolaylıkla zayıflar.

Hex ve Binary Dönüşümlerini Karşılaştırma

Hex ve binary dönüşümleri, aynı byte değerinin farklı gösterim biçimlerini yan yana görmek için kullanılabilir.

Örnek:

Bu örnekte 41 gibi görünen hex çıktısının iki karakteriyle tek bir byte’ı temsil ettiğine dikkat edilmelidir. Kriptografik araç çıktılarında karşılaşılan uzun hex dizeleri de bu mantıkla okunur: her iki hex karakteri bir byte’a karşılık gelir.

Bir hash çıktısı a3f7b2... gibi göründüğünde, bu uzun dizenin her iki karakterinin bir byte olduğunu bilmek, çıktının boyutunu doğru yorumlamayı sağlar. SHA-256’nın 32 byte, yani 64 hex karakter ürettiği bu mantıkla doğrulanabilir.

Hex çıktısı da şifreleme değildir. Yalnızca verinin daha okunabilir bir gösterim biçimidir. Bu nedenle hex biçiminde görünen bir veri gizlenmiş ya da korunmuş kabul edilmemelidir.

Temel Seviye Güvenli Kullanım / Kontrol Listesi

Bir araç çıktısıyla karşılaşıldığında önce “Bu ne tür bir çıktı?” sorusu sorulmalıdır. Encoding mi, hash mi, yoksa şifreli metin mi olduğu anlaşılmadan yapılan yorumlar hatalı güvenlik kararlarına yol açabilir.

Çıktı değerlendirilirken şu sorular özellikle faydalıdır: Giriş değiştikçe çıktı nasıl değişiyor? Çıktının uzunluğu sabit mi, girişe göre mi değişiyor? Geri çevrilebilir mi? Anahtar gerektiriyor mu? Bu dört soru, büyük çoğunlukla encoding, hashing ve encryption ayrımını netleştirmeye yeter.

Bir değerin rastgele üretildiğini varsaymak yerine, üretim yöntemi sorgulanmalıdır. Kullanılan kütüphane kriptografik açıdan güvenli rastgele sayı üreteci kullanıyor mu? Aynı IV ya da nonce değeri aynı anahtar altında birden fazla işlemde tekrar mı kullanılıyor? Bu sorular, kriptografik sistem incelemelerinde erken aşamada sorulmalıdır.

Şifreleme çıktısı, IV veya nonce kullanan modern bir modda her çalıştırmada farklı görünebilir. Aynı düz metin aynı anahtarla tekrar şifrelendiğinde sürekli aynı çıktı üretiliyorsa, kullanılan mod ve parametreler dikkatle incelenmelidir. Bu durum ECB kullanımı, sabit IV/nonce kullanımı veya kasıtlı deterministik şifreleme gibi farklı nedenlerden kaynaklanabilir. Genel amaçlı gizlilik senaryolarında bu davranış çoğu zaman risk işaretidir.

Hash çıktısı ise deterministiktir; aynı girdi her zaman aynı çıktıyı verir. Bu özellik hash fonksiyonunun normal davranışıdır. Ancak hash’in deterministik olması, düşük entropili girdilerin tahmin edilmesi riskini de beraberinde getirir.

Kendini Değerlendir — Matematiksel Temeller

Bu modülde özellikle kaçınılması gereken yanlış yorumlar şunlardır:

• Base64 görünümlü çıktıyı şifrelenmiş veri sanmak.
• Bir algoritma araçta destekleniyor diye güvenli kabul etmek.
• Hash’i şifreleme gibi düşünmek.
• Genel amaçlı random() fonksiyonunu kriptografik rastgelelik için yeterli görmek.
• Hex çıktısını gizli veya korunmuş veri zannetmek.
• Nonce değerinin her zaman rastgele olması gerektiğini düşünmek; asıl şartın çoğu bağlamda tekrar etmeme olduğunu kaçırmak.
• IV gereksiniminin her şifreleme modunda aynı olduğunu varsaymak.

Bir sistemi değerlendirirken “rastgele değer üretiminde hangi yöntem kullanılıyor?” sorusu açıkça sorulmalıdır. Eğer cevap güvenlik açısından kritik değerler için dilin genel amaçlı random() fonksiyonuysa, bu ciddi bir zayıflık işaretidir. Böyle bir durumda “kriptografik açıdan güvenli rastgele sayı üreteci kullanılmalı” önerisi net biçimde aktarılmalıdır.

Encoding ile şifreleme arasındaki fark anlatılırken “Base64 güvenlik sağlamaz; veriyi yalnızca farklı formatta temsil eder” ifadesi doğrudur ve öğrencinin zihninde net kalmalıdır.

Analitik Senaryo

Bir geliştirici, oturum token üretimi için şu yöntemi kullandığını açıklıyor: mevcut sistem saatini, yani timestamp değerini, kullanıcı ID’siyle birleştiriyor; ardından bu dizenin SHA-256 hash’ini hesaplıyor ve bunu oturum tokenı olarak kullanıyor. Dokümantasyonda da “kriptografik hash kullandım, güvenlidir” ifadesi yer alıyor.

İlk değerlendirme şu olmalıdır: Burada birkaç ayrı problem iç içe geçmiş durumdadır. SHA-256 doğru ve güçlü bir hash algoritması olabilir; ancak hash’in ne üzerinde uygulandığı en az algoritmanın kendisi kadar önemlidir. Timestamp ve kullanıcı ID’si kolayca tahmin edilebilir ya da gözlemlenebilir değerlerdir. Token tahmin edilebilir bir değerin hash’i olduğunda, saldırgan aynı girdileri deneyerek token değerini türetebilir.

Bu durumda token üretiminde kaç bit entropi olduğu sorgulanmalıdır. Timestamp saniye hassasiyetiyle kullanılıyorsa ve kullanıcı ID’si sıralı bir sayıysa, olası token değerleri son derece sınırlı kalır. Aynı kullanıcı için aynı zaman diliminde oluşturulan tokenın hep aynı olup olmadığı da kontrol edilmelidir.

SHA-256 çıktısı görsel olarak karmaşık görünür. 64 hex karakterden oluşur ve rastgele gibi durabilir. Ancak çıktının karmaşık görünmesi, üretim sürecinin güvenli olduğu anlamına gelmez. Hash fonksiyonu deterministiktir; giriş tahmin edilebilirse çıktı da tahmin edilebilir.

Oturum tokenı üretimi için güvenli yaklaşım, güçlü bir CSPRNG ile yeterli entropiye sahip, tahmin edilemeyen bir değer üretmektir. OWASP session ID’ler için en az 64 bit entropiyi minimum olarak belirtir; modern yeni tasarımlarda 128 bit veya üzeri entropi tercih etmek daha güçlü ve yaygın bir yaklaşımdır. Session ID değerinin kullanıcıya veya hesabına dair anlamlı bilgi içermemesi de önemlidir.

Python gibi dillerde bunun için genel amaçlı random() yerine secrets gibi kriptografik olarak güçlü rastgelelik sağlayan modüller tercih edilmelidir. Python belgeleri, secrets modülünün güvenlik tokenları, parola sıfırlama bağlantıları ve hesap doğrulama gibi sırların üretimi için uygun olduğunu belirtir.

Bu senaryodaki yanlış düşünce şudur: “SHA-256 güvenli bir hash algoritmasıdır; dolayısıyla üretilen token da güvenlidir.” Bu mantık yanlıştır. SHA-256’nın güvenli olması, uygulandığı verinin tahmin edilemez olduğunu garanti etmez. Hash fonksiyonu, zayıf ve tahmin edilebilir girdiyi kendiliğinden güvenli tokena dönüştürmez.

Bu hatanın pratik karşılığı session hijacking riskidir. Saldırgan hedef kullanıcının ID değerini ve yaklaşık token üretim zamanını biliyorsa ya da tahmin edebiliyorsa, olası token değerlerini üretebilir ve sisteme deneyebilir. Sistem ayrıca token denemelerine karşı oran sınırlama, oturum bağlamı kontrolü ve uygun izleme mekanizmaları kullanmıyorsa risk daha da artar.

Önerilen güvenli yaklaşım, token üretiminde işletim sisteminin veya güvenilir kütüphanenin CSPRNG kaynağını kullanmaktır. Üretilen değer kullanıcı ID’sinden, zamandan ya da tahmin edilebilir herhangi bir girdiden türetilmemelidir. Bu geliştiriciye aktarılırken şu şekilde ifade edilebilir:

Oturum tokenı deterministik ve tahmin edilebilir veriden değil, kriptografik açıdan güvenli rastgele sayı üretecinden gelmelidir. Hash fonksiyonu güçlü olsa bile, tahmin edilebilir girdiyi güvenli token hâline getirmez.

Bu yaklaşım geliştiriciyi suçlamadan, hatalı varsayımı net biçimde düzeltir.

Terimler Sözlüğü

Bu Modülde Neler Öğrendik?

Bu modül, kriptografinin teknik temelini oluşturan veri gösterimi, matematiksel sezgi ve güvenlik ölçütü kavramlarını kapsamlı biçimde ele aldı.

Bit, byte ve hex gösterimi artık soyut kavramlar değil; araç çıktılarında, anahtar dosyalarında ve hash değerlerinde her gün karşılaşılacak gerçek biçimler olarak tanınıyor. 41 gibi iki hex karakterinin bir byte’ı temsil ettiğini bilmek, kriptografik çıktıları okurken doğrudan kullanılacak bir beceridir.

XOR’un terslenebilirliği ve kriptografide neyi ifade ettiği kavrandı. XOR’un kendi başına güvenlik sağlamadığı, yalnızca tahmin edilemez ve doğru kullanılan bir anahtar akışıyla birleştiğinde anlam kazandığı netleşti.

Encoding, hashing ve encryption arasındaki fark bu modülde araç çıktıları üzerinden somut biçimde görüldü. Base64 çıktısı artık “şifrelenmiş veri” değil, “encoding yapılmış veri” olarak tanımlanabiliyor. Hash çıktısının sabit uzunluğu ve deterministik yapısı, onu şifreli metinden ayırt etmek için önemli ipuçları sağlıyor.

Modüler aritmetik, asal sayılar, EBOB, ters eleman ve kongrüans gibi kavramların kriptografideki yeri sezgisel olarak yerleşti. “Büyük sayıları çarpanlara ayırmak zordur” fikri RSA’yı; “uygun gruplarda ayrık logaritma problemi zordur” fikri ise Diffie-Hellman gibi anahtar değişim yapılarını anlamayı kolaylaştıracak.

Anahtar uzayı ve bit güvenliği kavramları artık anlamlı hâle geldi. “128 bit güvenlik” ifadesi boş bir tekrar değil, deneme sayısının astronomik boyutuna işaret eden somut bir güvenlik ölçütü olarak anlaşılmalıdır. Aynı şekilde DES’in neden yetersiz kaldığı da bu çerçevede açıkça görülüyor.

Rastgelelik konusunda en kritik pratik ders öğrenildi: kriptografik rastgelelik, dilin standart rastgele fonksiyonundan farklıdır. CSPRNG kullanılmadan üretilen anahtarlar, tokenlar, IV’ler veya nonce değerleri algoritmadan bağımsız olarak sistemi zayıf bırakabilir. Ayrıca IV ve nonce gereksinimlerinin kullanılan moda göre değiştiği; nonce için temel şartın çoğu bağlamda “aynı anahtar altında tekrar kullanılmamak” olduğu kavrandı.

Son olarak, çevrimiçi araçlara gerçek veri girilmemesi gerektiği net biçimde yerleşti. Araç çıktılarına bakmak, kavramları bağlamında anlamlandırmayı öğretti. Bu modülde kazanılan beceri komut ezberi değil, çıktı okuryazarlığıdır.

Bu modül boyunca frekans analizi gibi yöntemlerin klasik şifreleri nasıl zayıflattığını ve bunun modern tasarıma nasıl yansıdığını göreceksiniz. One-time pad ise teorik güvenlik ile pratik uygulanabilirlik arasındaki gerilimi en saf biçimiyle ortaya koyar. Doğru koşullar altında mükemmel gizlilik sağlayabilen bu yapı, aynı zamanda anahtar üretimi, anahtar dağıtımı ve anahtar tekrarının neden kritik olduğunu anlamak için güçlü bir örnektir.

Modülün sonunda öğrenci, “klasik şifreler kötüydü, modern olanlar iyidir” ezberinin ötesine geçecek; bu farkın arkasındaki teknik ve kavramsal nedenleri kendi cümleleriyle açıklayabilecek hâle gelecektir.

Yerine Koyma Şifreleri

Yerine koyma şifrelerinin arkasındaki fikir son derece sezgiseldir: her harfi başka bir harfle değiştir. Bu yaklaşımın en bilinen örneği Sezar şifresidir. Sezar şifresinde alfabedeki her harf sabit bir kaydırma miktarıyla başka bir harfe çevrilir. Üç pozisyon kaydırılırsa A yerine D, B yerine E yazılır.

Julius Caesar’ın askeri yazışmalarında kullandığı bu yöntemi kırmak için temel olarak kaydırma miktarını bulmak gerekir. Modern 26 harfli İngiliz alfabesi varsayılırsa, sıfır kaydırma dışarıda bırakıldığında yalnızca 25 anlamlı kaydırma olasılığı vardır. Farklı alfabelerde bu sayı alfabe uzunluğuna göre değişir; örneğin Türkçe alfabe kullanıldığında olası kaydırma sayısı farklıdır. Ancak hangi alfabe kullanılırsa kullanılsın, anahtar uzayı çok küçük olduğu için brute force saldırısı klasik anlamda bile zahmetsizce uygulanabilir.

ROT13, Sezar şifresinin özel bir varyantıdır. Her harf 13 pozisyon kaydırılır. Alfabenin tam ortasında durduğu için şifreleme ve çözme işlemi aynı işlemdir: A harfi N olur, N harfi tekrar A olur. ROT13, özellikle internet forumlarında spoiler içeriklerini geçici olarak gizlemek için uzun süre kullanılmıştır. Buradaki amaç güvenlik değil, içeriği görmek istemeyen kişinin yanlışlıkla görmesini engellemektir. Bu yüzden ROT13, kriptografik güvenlik sağlayan bir yöntem olarak değil; basit bir obfuscation, yani yüzeysel gizleme yöntemi olarak değerlendirilmelidir. Teknik olarak Sezar şifresinin özel bir türüdür, fakat güvenlik amacıyla kullanılmaz.

Affine şifresi, Sezar şifresini biraz daha karmaşıklaştırmak amacıyla modüler aritmetikten yararlanır. Her harf ax + b mod m biçiminde bir çarpma ve toplama işlemiyle dönüştürülür. Burada m alfabe uzunluğunu temsil eder. Çözme işleminin mümkün olabilmesi için a değerinin m ile aralarında asal seçilmesi gerekir; aksi hâlde bazı harfler aynı çıktıya dönüşebilir ve işlem tersine çevrilemez. Affine şifresi Sezar’dan daha karmaşık görünse de hâlâ tek alfabeli bir yerine koyma şifresidir. Her harf sabit bir kurala göre dönüştürülür ve doğal dilin istatistiksel izleri tamamen ortadan kalkmaz.

Bu üç şifreden çıkarılacak ortak ders şudur: güvenlik, yöntemin gizli tutulmasına değil, yapının sağlamlığına dayanmalıdır. Sezar şifresini bilen biri, kaydırma miktarını bilmese bile şifreli metni ele geçirdiğinde tüm olası kaydırmaları deneyebilir. Algoritma bilindiğinde güvenlik neredeyse tamamen çöker. Modern kriptografi bu problemi tersine çevirir: algoritma herkes tarafından bilinse bile, yalnızca doğru anahtarı elinde bulunduran kişi metni çözebilmelidir.

Sezar şifresini gören bazı öğrenciler “kaydırma miktarını saklarım, sorun çözülür” diye düşünebilir. Bu yaklaşım kriptografide güvenilir bir temel oluşturmaz. Algoritmanın ya da yöntemin gizli kalmasına güvenmek, “belirsizlik yoluyla güvenlik” olarak adlandırılır. Modern kriptografi ise güvenliğin algoritmanın saklanmasına değil; anahtarın korunmasına, matematiksel sağlamlığa ve doğru uygulamaya dayanması gerektiğini kabul eder.

Yer Değiştirme Şifreleri

Yerine koyma şifreleri harfleri başka harflerle değiştirirken, yer değiştirme şifreleri harflerin kendisini değiştirmez; yalnızca sıralarını karıştırır. Mantık farklı görünür, ancak bu yaklaşım da doğal dilin izlerini tamamen yok edemediği için kırılgandır.

Rail fence, yani raylı çit şifresi, metni çapraz bir zigzag deseniyle satırlara yazar ve ardından satır satır okuyarak şifreli metni oluşturur. İki raylı basit bir örnekte MERHABA metni şu şekilde yerleştirilebilir:

Ray sayısı bilindiğinde veya tahmin edildiğinde, aynı zigzag yapısı tersine kurularak metin çözülebilir. Bu yöntem görsel olarak karışık görünse de güçlü bir kriptografik koruma sağlamaz.

Sütunlu transpozisyon biraz daha yapılandırılmış bir yaklaşımdır. Metin bir tabloya satır satır yazılır, ardından sütunlar önceden belirlenmiş bir anahtar sıralamasına göre okunur. Anahtar 3-1-2 ise önce üçüncü sütun, sonra birinci sütun, ardından ikinci sütun okunur. Bu yöntem harflerin yerini karıştırır; fakat harfleri başka sembollere dönüştürmez.

Yer değiştirme şifrelerinin kritik zayıflığı, harflerin kendisinin değişmemesidir. Bu nedenle tek harf dağılımı korunur. İngilizcede E harfi sık kullanılıyorsa, transpozisyon sonrasında da E harfi metinde aynı sayıda bulunur; yalnızca farklı konumlara taşınmış olur. Yeterince uzun metinlerde ikili ve üçlü harf örüntüleri, olası kolon uzunlukları ve sıralama düzenleri üzerinden de analiz yapılabilir. Dolayısıyla yalnızca harfleri yer değiştirmek, doğal dilin istatistiksel izlerini ortadan kaldırmaz.

Bu durum, modern şifrelemenin neden yalnızca “karıştırma” fikrine dayanamayacağını gösterir. Güvenli bir şifreleme yöntemi, düz metindeki dil örüntülerini saldırgan açısından anlamlı şekilde görünmez hâle getirmelidir.

Polialfabetik Şifreler

Tek alfabeli yerine koyma şifrelerinde her harf daima aynı harfle değiştirilir. Bu, frekans analizine açık bir kapı bırakır. Polialfabetik şifreler bu problemi çözmeye çalışır: anahtar uzunluğuna bağlı olarak farklı konumlardaki harfler farklı alfabelerle şifrelenir.

Vigenère şifresinde bir anahtar kelime belirlenir. Metin, anahtar kelimeyle karakter karakter eşleştirilir ve her harf, o anahtar harfin belirttiği kaydırma miktarıyla şifrelenir. Anahtar ANAHTAR ise A=0, N=13, A=0, H=7, T=19, A=0, R=17 gibi düşünülebilir. Anahtar bittiğinde baştan sarılır. Bu tekrarlayan yapı, şifreli metnin içindeki örüntüleri başlangıçta gizler. Aynı düz metin parçası, anahtarın farklı bölümleriyle eşleştiğinde farklı çıktılar üretebilir.

Beaufort şifresi, Vigenère ailesiyle ilişkili klasik bir varyanttır. Matematiksel işlem yönü farklıdır ve klasik Beaufort’ta şifreleme ile çözme aynı işlem yapısına sahiptir. Temel eğitim açısından Beaufort ve Vigenère arasındaki ayrıntılı farktan çok, ikisinin de anahtar yapısı ve tekrar problemi üzerinden anlaşılması önemlidir.

Polialfabetik şifrelerin temel zaafı, anahtarın bir süre sonra tekrar etmesidir. Anahtar tekrar ettiği sürece, şifreli metindeki belirli pozisyonlar aynı alfabeyle şifrelenmiş olur. Bu tekrarlı yapı saptandığında, her pozisyon grubu aslında bir Sezar şifresi gibi davranmaya başlar ve frekans analizi tekrar devreye girer.

Vigenère tarihsel olarak uzun süre “kırılamaz şifre” gibi anılmıştır. Ancak anahtar tekrarının sistematik biçimde analiz edilebildiği anlaşıldığında bu güvenlik iddiası çökmüştür. Charles Babbage ve Friedrich Kasiski’nin çalışmaları, polialfabetik şifrelerin zayıflığını ortaya koyan önemli dönüm noktalarıdır.

“Anahtarı uzun tutarsam Vigenère güvenli olur” düşüncesi belirli bir noktaya kadar doğrudur; ancak burada kritik ayrım unutulmamalıdır. Anahtar mesaj kadar uzun, gerçekten rastgele, gizli ve yalnızca bir kez kullanılacak şekilde seçilirse yapı artık klasik Vigenère’den çok one-time pad fikrine yaklaşır. Kısa ve tekrar eden anahtar kullanan Vigenère güvenli değildir.

Klasik Şifrelerin Zayıflıkları

Klasik şifreleri zayıflatan tek bir araç yoktur. Asıl problem, doğal dillerin istatistiksel yapı taşımasıdır. Harfler, heceler, kelime yapıları ve tekrar eden ifadeler rastgele dağılmaz. Klasik şifreler bu yapıyı çoğu zaman yeterince silemez.

Frekans analizi, şifreli metindeki harf ya da sembol dağılımını orijinal dilin bilinen harf dağılımıyla karşılaştırır. İngilizcede E harfi sık kullanılan harflerden biridir. Eğer tek alfabeli bir yerine koyma şifresi kullanıldığı biliniyorsa ve şifreli metinde Q harfi sürekli en yüksek sıklıkla görünüyorsa, Q harfinin düz metindeki E harfine karşılık geliyor olabileceği makul bir başlangıç tahminidir. Birkaç yüksek frekanslı harf doğru eşleştirildiğinde, kalan metin kısmen okunabilir hâle gelir ve analitik çıkarım geri kalanını tamamlamaya yardımcı olur.

Bu teknik basit tablolarla elle bile uygulanabilir; özel hesaplama gücü gerektirmez. Özellikle uzun metinlerde tek alfabeli yerine koyma şifrelerine karşı son derece etkilidir.

Vigenère gibi polialfabetik şifreler, frekans dağılımını doğrudan okumayı zorlaştırır. Çünkü aynı harf her zaman aynı çıktıya dönüşmez. Ancak anahtar tekrar ediyorsa, bu tekrar şifreli metinde iz bırakır. Kasiski testinin fikri burada devreye girer.

Kasiski testi, polialfabetik şifreli bir metinde tekrar eden şifreli blokları ve bu bloklar arasındaki mesafeleri inceler. Aynı düz metin parçası, aynı anahtar pozisyonuyla birden fazla kez şifrelenirse, şifreli metinde tekrar eden aynı örüntüler oluşabilir. Bu tekrar eden bloklar arasındaki mesafelerin ortak bölenleri, anahtar uzunluğu için güçlü adaylar üretir. Daha sonra bu adaylar frekans analizi, index of coincidence veya benzer istatistiksel yöntemlerle desteklenebilir.

Bu aşamada Kasiski testinin tüm hesaplama ayrıntılarını bilmek gerekli değildir. Önemli olan şu sezgidir: anahtar tekrarı şifreli metinde iz bırakır ve bu izler sistematik biçimde değerlendirilebilir. Bu nedenle “anahtarın uzun olması” tek başına yeterli değildir; tekrar etmemesi, rastgeleliği ve kullanım biçimi de önemlidir.

Klasik şifrelerden çıkarılan en kalıcı ders şudur: güvenlik, algoritmanın gizliliğine değil, analiz edilebilir sağlamlığa dayanmalıdır. Kerckhoffs ilkesi olarak da bilinen bu düşünce, modern kriptografinin temel taşlarından biridir. Güvenli bir sistem, algoritması bilinse bile anahtar gizli kaldığı sürece güvenli kalmalıdır.

AES gibi modern algoritmalar herkese açık biçimde tanımlanır ve kriptografik analizden geçirilir. AES standardı, AES-128, AES-192 ve AES-256 olmak üzere üç anahtar uzunluğunu ve 128 bit blok boyutunu tanımlar. Ancak gerçek sistem güvenliği yalnızca algoritmanın adına bağlı değildir; doğru çalışma modu, doğru anahtar yönetimi, güvenli uygulama, rastgelelik ve yan kanal risklerinin azaltılması da belirleyicidir. NIST’in blok şifre çalışma modları rehberi ECB, CBC, CFB, OFB ve CTR gibi modları ayrı ayrı tanımlar; bu da aynı blok şifrenin farklı modlarla farklı güvenlik özellikleri gösterebileceğini ortaya koyar.

Doğal dil istatistikleri bir ayna gibi düşünülebilir. Klasik şifreler bu aynayı yalnızca buğular; bazı izler hâlâ görünür kalır. Doğru kullanılan modern şifreleme ise çıktıyı saldırgan açısından rastgeleye yakın ve anlamlı örüntülerden arındırılmış hâle getirmeyi hedefler. Yine de yalnızca “rastgele görünüyor” demek, bir yöntemin güvenli olduğunu kanıtlamaz. Güvenlik; kullanılan algoritma, mod, anahtar yönetimi, uygulama kalitesi ve tehdit modeliyle birlikte değerlendirilmelidir.

One-Time Pad ve Mükemmel Güvenlik Fikri

One-time pad, kriptografi tarihinde özel bir yere sahiptir. Doğru koşullar altında bilgi kuramsal düzeyde mükemmel gizlilik sağlayan en temel ve en bilinen şifreleme sistemlerinden biridir. Bu güvenlik, kullanılan algoritmanın karmaşıklığından değil; anahtarın niteliğinden ve kullanım disiplininden gelir. Shannon’ın mükemmel gizlilik kavramı, şifreli metnin düz metin hakkında saldırgana istatistiksel bilgi vermemesi fikrine dayanır.

OTP’nin çalışma mantığı ikili düzeyde XOR işlemiyle anlatılabilir. Düz metin, aynı uzunlukta bir anahtar akışıyla XOR işlemine tabi tutulur. Harf tabanlı anlatımlarda bu işlem modüler toplama gibi düşünülebilir; ancak modern açıklamada XOR sezgisi daha doğrudur.

OTP’de anahtar şu koşulları aynı anda sağlamalıdır:

• Anahtar, şifrelenecek mesaj kadar uzun olmalıdır.
• Anahtar gerçek anlamda rastgele üretilmiş olmalıdır.
• Anahtar yalnızca bir kez kullanılmalıdır.
• Anahtar gizli tutulmalı ve yetkisiz kişilerce elde edilmemelidir.

Bu koşullar birlikte sağlandığında, şifreli metni ele geçiren saldırgan düz metin hakkında anlamlı istatistiksel bilgi elde edemez. Aynı uzunlukta başka bir düz metin de uygun bir anahtarla aynı şifreli metni açıklayabilir. Saldırganın bunlar arasında seçim yapmasını sağlayacak güvenilir bir istatistiksel ayrım yoktur. OTP’nin “mükemmel gizlilik” gücü buradan gelir.

Peki modern kriptografide neden OTP yaygın biçimde kullanılmaz? Çünkü pratikte bu koşulların sürdürülmesi çok zordur.

İlk sorun anahtar dağıtımıdır. Mesaj kadar uzun, gerçekten rastgele ve gizli bir anahtarı karşı tarafa güvenle ulaştırmak başlı başına büyük bir operasyonel problemdir. OTP bazı özel senaryolarda önceden paylaştırılmış anahtarlarla kullanılabilir; ancak geniş ölçekli ve sürekli haberleşme sistemlerinde her mesaj için yeni ve mesaj kadar uzun anahtar dağıtmak pratik değildir.

İkinci sorun anahtar tekrarının yıkıcı etkisidir. Aynı anahtar iki farklı mesajda kullanılırsa, saldırgan iki şifreli metni birbirine XOR’layarak anahtarın etkisini ortadan kaldırır:

C1 = P1 XOR K
C2 = P2 XOR K

C1 XOR C2 = P1 XOR P2

Burada doğrudan okunabilir bir metin çıkması şart değildir. Asıl kritik nokta, anahtarın iptal olması ve geriye iki düz metnin XOR ilişkisinin kalmasıdır. Bu ilişki, tahmin edilen kelimeler, boşluk karakterleri ve dil istatistikleri yardımıyla bilgi sızmasına yol açabilir.

Venona örneği bu dersin tarihsel karşılığıdır. NSA’nın yayımladığı Venona anlatımlarında, Sovyet kriptografik materyalinde bazı one-time pad sayfalarının tekrar kullanılmasının kriptanalistler için önemli bir açıklık oluşturduğu belirtilir. Bu olay, OTP’nin teorik güvenliğinin pratikte anahtar üretimi ve anahtar kullanım disiplinine tamamen bağlı olduğunu gösterir.

Üçüncü sorun ölçeklenebilirliktir. Büyük bir haberleşme sistemi için her mesaj kadar uzun, yeni, rastgele ve gizli bir anahtar üretmek, saklamak, dağıtmak ve tekrar kullanılmadığından emin olmak son derece zor bir lojistik gerektirir.

OTP’yi anlamak, modern kriptografinin neden var olduğunu kavramak için değerlidir. Amaç çoğu gerçek sistemde “mükemmel gizlilik” değil, “pratik olarak güvenli” olmaktır. AES, OTP gibi bilgi kuramsal mükemmel gizlilik sağlamaz; güvenliği hesaplama açısından pratikte uygulanabilir olmayan saldırı maliyetlerine dayanır. Doğru mod, doğru anahtar yönetimi ve güvenli uygulama ile kullanıldığında modern sistemlerde güçlü bir simetrik şifreleme yapı taşıdır. AES’in kendisi bir blok şifredir; gerçek kullanımda güvenlik, hangi modla ve hangi protokol içinde kullanıldığına da bağlıdır.

Anahtar tekrarı OTP için ölümcüldür. Bu ders, modern simetrik kriptografide IV ve nonce yönetimini anlamak için de güçlü bir sezgi sağlar. Etki kullanılan moda göre değişse de, özellikle CTR ve GCM gibi yapılarda aynı anahtar altında nonce ya da IV tekrarları ciddi güvenlik riskleri doğurabilir. GCM, NIST tarafından authenticated encryption with associated data sağlayan bir mod olarak tanımlanır; bu güvenlik doğru IV/nonce kullanımı ve doğrulama adımlarına bağlıdır.

Klasik Şifreleri Görselleştiren Araçlar

Klasik şifreleme kavramlarını anlamlandırmak için çeşitli eğitim araçları ve basit çevrimiçi uygulamalar kullanılabilir. Bu araçlar gerçek güvenlik amacıyla değil, kavramları görselleştirmek için değerlendirilmelidir.

CyberChef, GCHQ tarafından geliştirilen açık kaynaklı ve tarayıcı tabanlı bir veri analiz/dönüştürme aracıdır. GCHQ, CyberChef’i teknik ve teknik olmayan kullanıcıların veri formatlarını, encoding işlemlerini, encryption işlemlerini, sıkıştırmayı ve benzeri dönüşümleri görsel biçimde inceleyebilmesi için geliştirilmiş sezgisel bir web uygulaması olarak tanıtır.

CyberChef’in “Recipe” mantığı, bir verinin birden fazla dönüşümden nasıl geçtiğini gözlemlemeyi kolaylaştırır. Örneğin bir metni önce Sezar şifresiyle dönüştürüp ardından frekans analizi çıktısını görüntülemek, klasik kriptoanalizin sezgisel olarak anlaşılmasına yardım eder.

Bir CyberChef oturumunda şu gözlem yapılabilir: düz bir İngilizce metin üzerinde basit bir yerine koyma şifresi uygulandığında, harf dağılımı karakteristik biçimde kayar; fakat dağılımın tepe noktaları tamamen ortadan kalkmaz. Yani en sık kullanılan harf değişebilir, ancak “en sık kullanılan harf” kavramı hâlâ görünür kalır. Bu, frekans analizinin neden işe yaradığını görsel olarak açıklar.

Frekans analizi çıktısı genellikle bir histogram olarak sunulur. Öğrenci bu histogramda doğal dil metni ile klasik şifrelenmiş metin arasındaki benzerliği fark etmelidir. Doğal dilde bazı harfler belirgin biçimde öne çıkar, bazıları çok daha az görünür. Tek alfabeli klasik şifrelerde bu profil tamamen yok olmaz; yalnızca başka sembollere taşınır.

Doğru kullanılan modern şifreleme çıktısı ise saldırgan açısından anlamlı dil örüntülerinden arındırılmış ve rastgeleye benzer görünmelidir. Ancak tek başına histogramın düzleşmesi, bir çıktının güvenli şifreleme ile üretildiğini kanıtlamaz. Metin uzunluğu, kullanılan encoding, çalışma modu, anahtar yönetimi ve bağlam birlikte değerlendirilmelidir.

Çevrimiçi kriptografi araçlarına gerçek parolalar, anahtarlar, kimlik bilgileri, oturum tokenları veya hassas metinler girilmemelidir. CyberChef eğitim ortamında sentetik veriyle çalışmak için uygundur; üretim sistemlerine ait herhangi bir veri bu tür araçlarla işlenmemelidir. Aynı ilke benzer her çevrimiçi şifreleme, hash veya dönüştürme aracı için geçerlidir.

Eğitim amaçlı kriptografik örnekler ile gerçek güvenlik sağlayan kriptografik sistemler arasındaki fark yalnızca algoritmanın gücüyle ilgili değildir. Araçların tasarım amacı da belirleyicidir. Klasik şifreleri görselleştiren bir araç, Sezar veya Vigenère şifrelerini doğru uygulasa bile size herhangi bir güvenlik garantisi sunmaz. Gerçek güvenlik; standartlara uygun, bakımı süren, güvenlik topluluğu tarafından incelenmiş, doğru yapılandırılmış kütüphaneler ve protokollerle sağlanır.

Komut & Araç Okuryazarlığı

Bu modülün araç okuryazarlığı bölümü, klasik şifrelerin nasıl kırılgan izler bıraktığını görsel olarak anlamaya odaklanır. Burada amaç gerçek veri işlemek değil; sentetik örneklerle kavramları gözlemlemektir.

Frekans Analizi Çıktısını CyberChef ile Gözlemlemek

Bu örnekte CyberChef üzerinde basit bir Sezar şifresi ve frekans analizi akışı düşünülebilir. Kullanılan metin tamamen uydurma veya genel bir eğitim metni olmalıdır. Gerçek kullanıcı verisi, parola, anahtar, token veya kurum içi metin bu araçla işlenmemelidir.

Amaç, şifreli metnin hâlâ bir dil örüntüsü taşıdığını gözlemlemek ve frekans analizinin neden çalıştığını görselleştirmektir. Sezar şifresi uygulanmış bir metinde belirli harflerin, düz metindeki yüksek frekanslı harflerin yerini alan semboller olarak öne çıktığı görülür. Histogram, orijinal metnin istatistiksel profilini tamamen yok etmez; yalnızca bu profili başka harflere taşır.

Öğrenci histogramda özellikle en yüksek çubukları taşıyan harflere bakmalıdır. İngilizce bir metin kullanılıyorsa yüksek frekanslı semboller E, T, A gibi harflerin kaydırılmış karşılıkları olabilir. Türkçe bir metinde ise A, E, İ, R gibi harflerin dağılımı farklı bir profil oluşturabilir. Burada asıl amaç belirli bir harfi ezberlemek değil; doğal dilin rastgele dağılmadığını görmektir.

Dağılım birkaç tepe noktasıyla karakteristik şekilde dalgalı kalıyorsa, yöntem istatistiksel örüntüyü tam olarak silememiş demektir. Bu, klasik bir şifrenin beklenen davranışıdır. Buna karşılık dağılımın daha düz görünmesi, çıktının doğal dil örüntülerini taşımadığını düşündürebilir; ancak bu tek başına güvenli şifreleme kanıtı değildir. Histogram yalnızca bir ipucu verir. Güvenlik değerlendirmesi için kullanılan algoritma, mod, anahtar yönetimi ve uygulama bağlamı bilinmelidir.

Bu deneyden çıkarılacak temel sonuç şudur: “CyberChef’te şifreledim, o hâlde güvende” düşüncesi yanlıştır. CyberChef’in klasik şifre işlemleri kavram görselleştirme içindir. Klasik şifreler, gerçek güvenlik sağlamaz.

OTP Mantığını XOR ile Gözlemlemek

Bu örnekte CyberChef veya benzer bir araç üzerinde XOR işlemiyle OTP mantığı görselleştirilebilir. Kullanılan veriler kısa, uydurma ve anlamsız olmalıdır. Bu deney gerçek bir güvenlik uygulaması değildir; yalnızca anahtar tekrarının neden tehlikeli olduğunu göstermek için yapılır.

İki farklı düz metnin aynı anahtar akışıyla XOR’landığını düşünelim:

C1 = P1 XOR K
C2 = P2 XOR K

Bu iki şifreli metin birbiriyle XOR’landığında anahtar iptal olur:

C1 XOR C2 = P1 XOR P2

Burada öğrencinin görmesi gereken şey, iki şifreli metnin XOR’undan doğrudan okunabilir bir metin çıkması değildir. Çoğu zaman doğrudan okunabilir bir çıktı görülmeyebilir. Asıl kritik nokta, anahtarın artık denklemden çıkmış olmasıdır. Geriye iki düz metnin birbiriyle ilişkisi kalır. Bu ilişki; tahmin edilen kelimeler, boşluk karakterleri ve dil istatistikleri yardımıyla bilgi sızmasına neden olabilir.

Bu deney, OTP’nin güvenliğinin XOR işleminden değil, anahtarın kalitesinden ve tek kullanımlık olmasından geldiğini gösterir. Anahtar tekrarlandığında, teorik olarak mükemmel gizlilik sağlayabilen yapı bile pratikte zayıflar.

Temel Seviye Güvenli Kullanım / Kontrol Listesi

Bu modülde öğrencinin zihninde kalıcı hâle getirmesi gereken ayrımlar, araç kullanım sınırları ve yanlış yorumlama riskleri vardır.

Bir şifreli metin veya araç çıktısıyla karşılaşıldığında ilk soru şu olmalıdır: Bu çıktı hangi yöntemle üretildi ve bu yöntemin güvenlik varsayımı nedir? Yöntem bilinmiyorsa, güvenlik iddiasına temkinli yaklaşılmalıdır.

Karşılaşılan bir şifreli metinde harf ya da sembol dağılımı belirgin bir örüntü taşıyorsa, tek alfabeli yerine koyma ihtimali düşünülebilir. Tekrar eden örüntüler mevcutsa, çok alfabeli şifre ve kısa anahtar ihtimali akla gelebilir. Ancak hiçbir görsel ipucu tek başına kesin karar vermek için yeterli değildir; bağlam, algoritma ve kullanım biçimi mutlaka sorgulanmalıdır.

Klasik şifre araçlarıyla üretilen hiçbir çıktı gerçek güvenlik amacıyla kullanılmamalıdır. CyberChef’te Sezar veya Vigenère işlemi uygulamak, kavramı görselleştirmek için faydalıdır; fakat üretim ortamında veri koruma yöntemi olarak kabul edilemez.

Frekans analizi histogramının belirgin tepe noktaları göstermesi, klasik şifrelemenin istatistiksel izleri koruduğunu düşündürebilir. Modern kriptografik çıktılar doğru kullanıldığında doğal dil profiline benzememelidir; fakat yalnızca histogram düz görünüyor diye bir yöntemin güvenli olduğu sonucuna varılmamalıdır.

“Araç şifreledi” ile “güvenli şifreleme yapıldı” aynı şey değildir. Bir araç dönüşüm yapabilir, ama bu dönüşüm gerçek tehdit modellerine karşı güvenlik sağlamayabilir. Frekans analizi çıktısı düz metni doğrudan vermeyebilir; fakat güçlü ipuçları sunabilir. Bu nedenle çıktı yorumlama, kesin hüküm vermekten çok risk işaretlerini doğru okumayı gerektirir.

Bir sistemde veri koruma amacıyla klasik şifre, basit XOR tabanlı yöntem veya geliştiricinin kendi tasarladığı gizli algoritma kullanıldığı görülürse, bu durum “kriptografik güvenlik” olarak değil, “belirsizlik yoluyla gizleme” olarak değerlendirilmelidir. Geliştirici ekibe şu şekilde aktarılabilir:

Bu yöntem algoritmayı gizleyerek koruma sağlamaya çalışıyor; ancak modern kriptografik standartların beklediği güvenlik modelini karşılamıyor. Gerçek tehdit modelleri karşısında güvenilir koruma için standartlara uygun, incelenmiş ve doğru yapılandırılmış kriptografik kütüphaneler kullanılmalıdır.

Kendini Değerlendir — Klasik Şifreler

Analitik Senaryo

Güvenlik farkındalığı eğitimi kapsamında bir test uygulaması inceleniyor. Uygulamada kullanıcıların gönderdiği mesajlar bir log dosyasına yazılıyor; ancak bu mesajların “şifreli” olduğu belirtiliyor. Log dosyası incelendiğinde, her satırda okunması zor karakter dizileri görülüyor. Metin doğrudan anlaşılmıyor; fakat uzun satırlarda bazı harflerin ve sembollerin sürekli öne çıktığı dikkat çekiyor. Mesajların hangi yöntemle dönüştürüldüğü belgelenmemiş.

İlk değerlendirme şu olmalıdır: Metnin gözle okunamaması, güvenli biçimde şifrelendiği anlamına gelmez. Okunamamak ile kriptografik güvenlik farklı kavramlardır. Bir metin Base64 ile kodlandığında da gözle okunmayabilir; fakat bu onu şifreli yapmaz. Aynı şekilde klasik bir yerine koyma ya da yer değiştirme yöntemi de metni ilk bakışta anlaşılmaz hâle getirebilir, fakat gerçek güvenlik sağlamayabilir.

Bu durumda farklı satırlardaki sembol dağılımı incelenebilir. Belirli karakterlerin sürekli öne çıkması, doğal dil istatistiklerinin tamamen silinmediğini düşündürebilir. Aynı uzunluktaki bloklarda tekrar eden sembol örüntüleri varsa, kısa anahtar kullanımı, sabit kaydırma, tekrar eden dönüşüm veya klasik bir şifreleme yaklaşımı ihtimali gündeme gelir.

Çıktının uzunluğu da gözlemlenebilir; ancak uzunluğun girişle aynı ya da orantılı olması tek başına yöntemin kriptografik olmadığı anlamına gelmez. Modern şifreleme çıktıları da çoğu zaman giriş uzunluğuyla ilişkilidir. Örneğin bazı modlarda ciphertext uzunluğu plaintext uzunluğuna yakın olabilir; AEAD gibi yapılarda authentication tag nedeniyle ek uzunluk oluşabilir. Bu nedenle uzunluk bilgisi yalnızca diğer bulgularla birlikte değerlendirilmelidir.

CyberChef’te veya benzer bir analiz aracında frekans dağılımı çıkarıldığında, dağılım yüksek tepe noktaları ve belirgin örüntüler gösteriyorsa bu durum dönüşümün doğal dil izlerini koruduğunu düşündürür. Bu kesin bir kırma işlemi değildir; fakat “kriptografik kaliteli şifreleme” iddiasını sorgulamak için güçlü bir işarettir.

Güvenli doğrulama için kullanılan algoritmanın belgelenmesi gerekir. Eğer dokümantasyon yoksa, “kendi geliştirdiğimiz yöntem” deniyorsa veya yalnızca “metni karıştırıyoruz” gibi belirsiz açıklamalar yapılıyorsa, bu yaklaşımın modern kriptografik güvenlik beklentilerini karşılamadığı varsayılmalıdır. Asıl değerlendirme noktası şudur: yöntem algoritmanın gizliliğine mi dayanıyor, yoksa açıkça tanımlanmış ve incelenmiş bir kriptografik yapıya mı?

Bu hatanın pratik karşılığı ciddidir. Eğer uygulama gerçek kullanıcı mesajlarını klasik şifre veya basit dönüşümle logluyorsa, yeterli veri ve analiz imkânı bulunduğunda mesajların kısmen veya tamamen kurtarılması mümkün olabilir. “Şifrelenmiş” etiketi kullanılmış olsa bile, veri gerçekten korunmuyor olabilir.

Güvenli yaklaşım yalnızca “logları şifreleyelim” demek değildir. Öncelikle loglarda hassas veri tutulmamalı veya mümkün olduğunca azaltılmalıdır. Gerekli durumlarda maskeleme, veri minimizasyonu, erişim kontrolü, güvenli anahtar yönetimi ve standart kütüphanelerle uygulanan modern şifreleme birlikte değerlendirilmelidir. Gizlilik gerekiyorsa modern ve doğrulanmış bir şifreleme yöntemi kullanılmalı; bütünlük de gerekiyorsa MAC, dijital imza veya AEAD gibi mekanizmalar düşünülmelidir.

Geliştirici ekibe aktarılacak mesaj şu şekilde olabilir:

Mevcut dönüşüm, istatistiksel analiz karşısında bilgi sızdırıyor olabilir. Bu yöntem algoritmanın gizliliğine dayanıyor; kriptografik güce değil. Hassas log verileri için standart, incelenmiş ve doğru yapılandırılmış kriptografik kütüphaneler kullanılmalı; mümkünse hassas veri loglara hiç yazılmamalıdır.

Terimler Sözlüğü

Bu Modülde Neler Öğrendik?

Bu modül, kriptografi öğreniminde kritik bir dönüm noktasını oluşturur: klasik şifreler neden yetersizdir ve modern kriptografi bu eksikliği nasıl ele alır?

Öğrenci artık Sezar, ROT13, Affine ve Vigenère gibi klasik şifrelerin aynı temel zayıflığı farklı biçimlerde taşıdığını biliyor. Tek alfabeli yerine koyma şifrelerinde frekans analizi bu zayıflığı sömürür. Polialfabetik şifrelerde ise anahtar tekrarı ortaya çıktığında, Kasiski testi ve benzer istatistiksel yöntemler devreye girer.

Yer değiştirme şifreleri farklı bir strateji dener: harfleri değiştirmeden yerlerini karıştırır. Ancak bu yöntem de harf dağılımını ve doğal dilin bazı istatistiksel izlerini koruduğu için gerçek güvenlik sağlamaz.

One-time pad, teorik güvenlik açısından ideal bir noktayı gösterir. Doğru koşullarda mükemmel gizlilik sağlayabilir; fakat bu koşullar pratikte çok ağırdır. Anahtar mesaj kadar uzun, gerçekten rastgele, gizli ve tek kullanımlık olmalıdır. Anahtar tekrarlandığında OTP’nin güvenliği çöker. Bu ders, modern kriptografide IV ve nonce yönetiminin neden bu kadar önemli olduğunu anlamak için güçlü bir sezgiye dönüşür.

Kerckhoffs ilkesi bu modülde yerini buldu: güvenli bir sistem, algoritması bilinse bile güvenli kalmalıdır. Modern kriptografi, algoritmayı saklamaya değil; açıkça incelenmiş tasarımlara, güçlü anahtarlara, doğru kullanım biçimlerine ve güvenli uygulamalara dayanır.

Araç okuryazarlığı açısından öğrenci artık CyberChef gibi bir araçta frekans analizi çıktısını okuyabilir ve dağılım profilinin ne anlama geldiğini yorumlayabilir. Ancak histogramın tek başına güvenlik kanıtı olmadığını da bilir. Bir çıktının rastgele görünmesi, kullanılan yöntemin güvenli olduğunu otomatik olarak kanıtlamaz.

Son olarak, “araç şifreledi” ile “güvenli şifreleme” arasındaki fark netleşti. Klasik şifre araçları kavram görselleştirme içindir; gerçek güvenlik için kullanılamaz. Çevrimiçi araçlara gerçek veri girilmemesi gerektiği, bu modülde kazanılan pratik bir güvenlik alışkanlığı olarak yerini aldı.

AES, günümüzde en yaygın kullanılan simetrik blok şifre standardıdır. HTTPS bağlantılarından disk şifrelemeye, mesajlaşma uygulamalarından bulut depolama sistemlerine kadar birçok farklı alanda karşımıza çıkar. Bununla birlikte modern simetrik kriptografi yalnızca “AES kullanmak” anlamına gelmez. Hangi çalışma modunun kullanıldığı, IV veya nonce değerlerinin nasıl üretildiği, authentication tag doğrulamasının yapılıp yapılmadığı ve anahtarların nasıl yönetildiği en az algoritma seçimi kadar önemlidir.

Bu modülde simetrik şifrelemenin temel mantığını, blok şifre kavramını, çalışma modlarını ve bu modların neden kritik olduğunu öğreneceksiniz. IV ve nonce gibi kavramlar burada gerçek anlamını kazanır; bu değerleri yanlış kullanmak pratikte ciddi güvenlik açıklarına yol açabilir. Modülün son kısmında akış şifrelerine ve kimlik doğrulamalı şifreleme fikrine kavramsal düzeyde bakılacaktır.

Öğrenci bu modülü tamamladığında “AES kullandım, güvendeyim” yanılgısını aşmış olacak; hangi modun neden seçildiğini, IV ve nonce yönetiminin neden kritik olduğunu ve AEAD yaklaşımının modern kriptografide neden vazgeçilmez hâle geldiğini kavrayacaktır.

Blok şifre ile akış şifresi arasındaki temel farkı ayırt edebilir.

AES’in neden tercih edilen standart olduğunu ve DES/3DES’in neden terk edildiğini gerekçesiyle ifade edebilir.

ECB modunun neden güvensiz olduğunu somut bir mantıkla anlatabilir ve ECB çıktısını diğer modların çıktısından kavramsal olarak ayırt edebilir.

CBC ve CTR modlarında IV, nonce ve sayaç yönetiminin neden güvenliğin merkezinde olduğunu açıklayabilir.

AEAD kavramını ve “sadece şifreleme yetmez” ilkesini kendi cümleleriyle ifade edebilir.

RC4’ün neden terk edildiğini ve ChaCha20’nin neden modern bir alternatif olduğunu söyleyebilir.

OpenSSL çıktısında ciphertext, salt ve şifreleme meta verisi gibi alanları kavramsal olarak tanıyabilir ve yorumlayabilir.

OpenSSL enc komutunun GCM/CCM gibi AEAD modları için uygun olmadığını; AEAD kullanımının doğru API veya kütüphane seviyesinde ele alınması gerektiğini kavrayabilir.

Araçlarda var olan güvensiz modların, o modların kullanılmasının güvenli olduğu anlamına gelmediğini açıklayabilir.

Yanlış mod seçimi, IV tekrarı, nonce tekrarı veya kimlik doğrulamasız şifreleme gibi hataların pratikte hangi riskleri doğurduğunu değerlendirebilir.

Simetrik Şifreleme Mantığı

Simetrik şifreleme, şifreleme ve çözme işlemlerinde aynı anahtarın kullanıldığı kriptografik modeldir. Gönderen taraf veriyi bir anahtarla şifreler, alıcı taraf da aynı anahtarla çözer. Bu model son derece verimlidir. Modern işlemciler AES gibi simetrik algoritmaları donanım hızlandırmasıyla çok hızlı çalıştırabilir ve bu hız çoğu kullanımda asimetrik kriptografiden çok daha yüksektir. Bu yüzden büyük veri hacimlerinin korunmasında neredeyse her zaman simetrik kriptografi kullanılır.

Simetrik modelin en önemli sınırı anahtar paylaşımıdır. İki tarafın aynı gizli anahtar üzerinde anlaşması gerekir. Eğer taraflar arasında önceden güvenli bir kanal yoksa, bu anahtarın güvenli biçimde nasıl paylaşılacağı başlı başına bir problemdir. Gerçek sistemler bu problemi genellikle hibrit yaklaşımla çözer. Önce asimetrik kriptografi veya anahtar değişim mekanizmalarıyla güvenli bir oturum anahtarı üzerinde anlaşılır, ardından veri akışı simetrik şifreleme ile korunur. TLS gibi protokollerde de temel fikir budur; ancak bu modülde TLS’in ayrıntılarına girilmeyecektir.

“Aynı anahtar kullanılıyor” ifadesi bazı yanlış anlamalara yol açabilir. Güvenli bir simetrik sistemde anahtarın yalnızca yetkili taraflarda bulunması, yeterli rastgelelikle üretilmiş olması, güvenli saklanması, kullanım ömrünün yönetilmesi ve gerektiğinde değiştirilmesi gerekir. Anahtar ele geçirilirse, o anahtarla korunan veriler de tehlikeye girer. Bu yüzden anahtar yönetimi simetrik kriptografinin ayrılmaz bir parçasıdır.

Pratikte “aynı anahtarı her yerde kullanmak” ciddi risk taşır. Farklı amaçlar için farklı anahtarlar kullanmak, anahtarları güvenli ortamlarda saklamak, anahtar rotasyonu yapmak ve anahtar erişimlerini sınırlamak gerekir. Gerçek güvenlik yalnızca doğru algoritmayı seçmekle değil, bu algoritmanın anahtarlarının nasıl yönetildiğiyle de ilgilidir.

Blok Şifreleme

Blok şifre, sabit boyutlu bir veri bloğunu bir anahtar yardımıyla başka bir bloğa dönüştüren kriptografik yapı taşıdır. AES gibi blok şifreler tek seferde belirli boyutta blok işler. Birden fazla bloğun nasıl ilişkilendirileceğini, hangi sırayla işleneceğini ve tekrar eden blokların nasıl ele alınacağını ise çalışma modu belirler.

AES’in blok boyutu her zaman 128 bittir; yani AES her seferinde 16 baytlık bir veri bloğu üzerinde işlem yapar. AES üç farklı anahtar uzunluğunu destekler: 128, 192 ve 256 bit. Bu özellikler NIST’in AES standardında açık biçimde tanımlanmıştır.

AES-128 güncel uygulamalarda güçlü kabul edilir. AES-256 daha geniş bir anahtar uzayı sunar ve bazı uzun vadeli koruma senaryolarında tercih edilebilir. Ancak gerçek sistem güvenliği yalnızca anahtar uzunluğuna bağlı değildir. Çalışma modu, IV/nonce yönetimi, anahtar saklama, doğru kütüphane kullanımı, rastgelelik, yan kanal riskleri ve uygulama hataları güvenliği doğrudan etkiler.

DES, 1977’de standart olarak benimsendi; ancak 56 bitlik anahtar uzunluğu modern hesaplama gücü ve özel donanım karşısında yetersiz kaldı. Bu nedenle DES, brute force saldırılarına karşı pratik olarak kırılabilir kabul edilir.

3DES/TDEA, DES’in ömrünü uzatmak için DES işlemini birden fazla kez uygulayan bir yapıydı ve bir süre yaygın olarak kullanıldı. Ancak 64 bit blok boyutu, modern güvenlik beklentileri ve Sweet32 gibi blok boyutu kaynaklı riskler nedeniyle artık yeni sistemlerde kullanılmamalıdır. NIST, TDEA standardı olan SP 800-67 Rev. 2’yi 1 Ocak 2024 itibarıyla geri çekmiştir; bu nedenle 3DES güncel tasarımlarda değil, yalnızca eski sistemleri anlamak için tarihsel/legacy bağlamda ele alınmalıdır.

AES’in iç yapısı, yani SubBytes, ShiftRows, MixColumns ve anahtar çizelgesi gibi mekanizmalar bu eğitimde ayrıntılı olarak ele alınmayacaktır. Temel seviyede önemli olan iki nokta vardır. Birincisi, AES’in tasarımı kamuya açıktır. İkincisi, bu açıklığa rağmen yıllardır kriptanaliz sürecinden geçerek modern sistemlerde güvenli bir yapı taşı olarak kullanılmaya devam etmektedir. Bu durum Kerckhoffs ilkesinin modern kriptografideki somut karşılıklarından biridir.

Burada özellikle şu yanılgıdan kaçınmak gerekir: “AES-256 kullandım, şifreleme artık mükemmel.” Anahtar uzunluğu güvenliğin yalnızca bir boyutudur. Yanlış çalışma modu, tekrar eden IV/nonce, eksik authentication tag doğrulaması veya kötü anahtar yönetimi, güçlü bir algoritmayı bile güvensiz hâle getirebilir.

Blok Şifreleme Modları

Blok şifreler tek başına sabit boyutlu bir bloğu dönüştürür. Gerçek veriler ise çoğu zaman birden fazla bloktan oluşur ve bazen blok boyutuna tam olarak denk gelmez. Birden fazla bloğun nasıl işleneceğini çalışma modu belirler. Mod seçimi güvenlik açısından kritiktir; algoritma doğru olsa bile yanlış mod tercih etmek ciddi zafiyetlere yol açabilir. NIST SP 800-38A, ECB, CBC, CFB, OFB ve CTR gibi temel blok şifre çalışma modlarını ayrı ayrı tanımlar.

ECB — Electronic Codebook

ECB, her bloğu birbirinden bağımsız biçimde şifreler. Aynı düz metin bloğu, aynı anahtarla her zaman aynı şifreli metin bloğunu üretir. Bu özellik ilk bakışta zararsız görünebilir; fakat pratikte ciddi bir sorundur. Tekrar eden düz metin blokları, şifreli metinde de tekrar eden bloklar olarak görünür.

Bu durum özellikle görüntü verilerinde dramatik biçimde ortaya çıkar. ECB ile şifrelenmiş bir bitmap görüntüde orijinal görüntünün şekil ve örüntüleri hâlâ seçilebilir olabilir. Bunun sebebi, ECB’nin verideki blok düzeyindeki tekrarları gizlememesidir.

Mini örnek olarak aynı 16 baytlık bloğun iki kez şifrelenmesi gerektiğini düşünelim. ECB, bu iki aynı bloğa karşılık iki aynı ciphertext bloğu üretir. Saldırgan metni çözemese bile, belirli blokların tekrar ettiğini görür. Bu bilgi tek başına bile veri yapısı hakkında anlamlı çıkarım sağlayabilir.

ECB, genel amaçlı veri şifreleme için güvenli kabul edilmez ve üretim sistemlerinde veri gizliliği sağlamak amacıyla kullanılmamalıdır.

CBC — Cipher Block Chaining

CBC, her bloğu şifrelemeden önce bir önceki şifreli metin bloğuyla XOR işlemine tabi tutar. Bu zincirleme yapı, aynı düz metin bloğunun farklı bağlamlarda farklı şifreli metin blokları üretmesine yardımcı olur. İlk blok için önceki şifreli metin bloğu olmadığından, bu görevi IV, yani Initialization Vector üstlenir.

CBC’de IV gizli olmak zorunda değildir; ciphertext ile birlikte açık biçimde taşınabilir. Ancak CBC için IV’nin tahmin edilemez olması ve aynı anahtarla tekrar kullanılmaması gerekir. NIST SP 800-38A, CBC modunda IV’nin gizli olmak zorunda olmadığını, fakat tahmin edilemez olması gerektiğini belirtir.

CBC, ECB’nin tekrar eden blok problemine çözüm getirir; ancak tek başına bütünlük sağlamaz. Yani saldırgan şifreli metni okuyamasa bile, belirli manipülasyonlarla çözülen verinin bozulmasına veya beklenmeyen davranışlara neden olabilir. Bu yüzden modern tasarımlarda CBC tek başına tercih edilmez. Ya doğru kurulmuş bir MAC yapısıyla birlikte kullanılır ya da daha yaygın ve güvenli yaklaşım olarak AEAD modları tercih edilir.

CTR — Counter Mode

CTR modu, blok şifreyi bir akış şifresi gibi kullanır. Blok şifre doğrudan düz metni şifrelemek yerine, nonce ve sayaç değerlerinden oluşan blokları şifreleyerek bir anahtar akışı üretir. Bu anahtar akışı daha sonra düz metinle XOR’lanır.

CTR modu paralel işlemeye çok uygundur ve aynı işlem mantığıyla hem şifreleme hem çözme yapılabilir. Ancak güvenliği nonce/sayaç yönetimine çok bağlıdır. Buradaki kritik şart, aynı anahtar altında aynı nonce/sayaç bloğunun tekrar kullanılmamasıdır.

Aynı anahtar akışı iki farklı mesaj için tekrar kullanılırsa, two-time pad problemi ortaya çıkar. İki ciphertext birbiriyle XOR’landığında anahtar akışı iptal olur ve geriye iki düz metnin XOR ilişkisi kalır. Bu ilişki doğrudan metni vermeyebilir; ancak dil yapısı, bilinen alanlar veya tahmin edilen içerikler üzerinden ciddi bilgi sızmasına yol açabilir.

ECB, CBC ve CTR arasındaki fark yalnızca teknik bir ayrıntı değildir; güvenlik modelinin farklılaştığını gösterir. ECB örüntüleri saklamaz. CBC doğru IV yönetimi ve ayrıca bütünlük koruması gerektirir. CTR ise nonce/sayaç disiplini olmadan güvensizleşir. Algoritma doğru seçilmiş olsa bile, mod ve IV/nonce yönetimi güvenliği belirler.

Kimlik Doğrulamalı Şifreleme

Şifreleme tek başına bütünlük garantisi vermez. Bir saldırgan şifreli metni okuyamasa bile, şifreli verinin belirli bitlerini değiştirebilir. Bu değişiklik alıcı tarafında çözüldüğünde anlamsız, bozuk veya kötü niyetli sonuçlar ortaya çıkabilir. “İçeriği okunamaz kılmak” ile “içeriğin değiştirilmediğini doğrulamak” farklı güvenlik hedefleridir.

AEAD, yani Authenticated Encryption with Associated Data, bu iki ihtiyacı tek bir kriptografik yapı altında birleştirir. AEAD hem gizliliği sağlar hem de şifrelenen verinin değiştirilmediğini doğrulayan bir authentication tag üretir. Eğer ciphertext veya associated data aktarım sırasında değiştirilirse, authentication tag doğrulaması başarısız olur ve veri güvenilir kabul edilmez.

AEAD kullanılan sistemlerde authentication tag doğrulanmadan plaintext güvenilir kabul edilmemelidir. Tag doğrulaması başarısızsa veri kullanılmamalı ve işlem hata olarak ele alınmalıdır. Bu disiplin, birçok manipülasyon saldırısını engelleyen temel güvenlik davranışıdır.

GCM, yani Galois/Counter Mode, en yaygın AEAD modlarından biridir. Şifreleme tarafında counter mantığını kullanır; bütünlük doğrulaması için ise Galois alanı tabanlı GHASH mekanizmasıyla authentication tag üretir. NIST SP 800-38D, GCM’yi authenticated encryption with associated data sağlayan bir blok şifre modu olarak tanımlar.

GCM doğru kullanıldığında hem gizlilik hem de doğrulanabilir bütünlük sağlar. Ancak bu güvenlik otomatik değildir. Nonce/IV tekrarının önlenmesi, authentication tag’in mutlaka doğrulanması, doğru tag uzunluğu, güvenli anahtar yönetimi ve doğru kütüphane/API kullanımı gerekir. Özellikle aynı anahtar altında nonce/IV tekrar kullanımı GCM için çok ciddi bir güvenlik riskidir.

Associated data, yani ek doğrulanmış veri, şifrelenmeyen fakat bütünlüğü korunması gereken veriyi ifade eder. Ağ paketlerindeki bazı başlık alanları buna örnek verilebilir. Başlık gizli olmak zorunda değildir; ama değiştirilemez olmalıdır. AEAD yapısı bu veriyi authentication tag hesaplamasına dahil eder. Böylece associated data değiştirilirse tag doğrulaması başarısız olur.

Modern bir şifreleme uygulaması tasarlanırken veya güvenlik incelemesi yapılırken sorulması gereken temel sorulardan biri şudur: “Bu sistem kimlik doğrulamalı şifreleme kullanıyor mu?” Yalnızca AES-CBC veya AES-CTR kullanılan ama authentication tag içermeyen bir sistemde bütünlük garantisi eksiktir.

Akış Şifreleri

Blok şifreler veriyi sabit boyutlu bloklar üzerinden işlerken, akış şifreleri bitleri veya baytları bir anahtar akışıyla XOR’lama mantığına dayanır. Teorik olarak sözde rastgele bir anahtar akışı üretilir ve bu akış düz metinle birleştirilir. Akış şifreleri özellikle düşük gecikmeli ve kaynak kısıtlı ortamlarda avantaj sağlayabilir.

RC4, uzun yıllar SSL/TLS protokollerinde ve WEP kablosuz güvenliğinde yaygın biçimde kullanıldı. Ancak RC4’ün ürettiği anahtar akışında istatistiksel önyargılar ve pratik saldırı imkânları ortaya çıktı. IETF RFC 7465, TLS istemci ve sunucularının RC4 cipher suite’leriyle bağlantı kurmamasını zorunlu kılar. TLS 1.3 de RC4 gibi eski yapıları içermez ve modern AEAD tabanlı cipher suite’lerle çalışır.

RC4 kullanan herhangi bir sistem bugün güvensiz kabul edilmelidir. Bu tür algoritmalar yalnızca tarihsel bağlamı anlamak için incelenmelidir.

ChaCha20, Daniel Bernstein tarafından tasarlanan ve günümüzde aktif biçimde kullanılan modern bir akış şifresidir. Özellikle AES donanım hızlandırmasının zayıf veya bulunmadığı ortamlarda performans avantajı sağlayabilir. ChaCha20-Poly1305 ise ChaCha20 akış şifresini Poly1305 doğrulayıcısıyla birleştirerek AEAD sağlar. RFC 8439, ChaCha20 şifresini, Poly1305 authenticator yapısını ve ikisinin AEAD birleşimini tanımlar.

ChaCha20-Poly1305, tıpkı AES-GCM gibi hem gizlilik hem de doğrulanabilir bütünlük sağlar. Modern protokollerde yaygın biçimde kullanılır. Burada da kritik nokta nonce yönetimidir. Aynı anahtar ve nonce kombinasyonu iki farklı mesajı şifrelemek için kullanılırsa, akış şifresi aynı anahtar akışını yeniden üretir ve two-time pad problemi ortaya çıkar. Bu yüzden ChaCha20 gibi akış şifrelerinde nonce tekrarından kesinlikle kaçınılmalıdır.

Simetrik Şifreleme Araç Okuryazarlığı

Simetrik kriptografi çoğu sistemde görünmez bir altyapı olarak çalışır. Ancak doğru araçlarla bu çıktıları yüzeye çekip incelemek mümkündür. Buradaki amaç komut ezberlemek değil, araç çıktısındaki kavramları tanımaktır.

OpenSSL, simetrik şifreleme işlemleri için yaygın kullanılan bir komut satırı aracıdır. openssl enc -list gibi bir komut çalıştırıldığında, desteklenen birçok simetrik şifreleme seçeneği görülebilir. Bu listede aes-128-ecb, aes-256-cbc, aes-256-ctr, des-ede3-cbc gibi seçenekler yer alabilir. Ancak listede bir algoritmanın veya modun görünmesi, onun güvenli şekilde kullanılabileceği anlamına gelmez. Araçlar geriye dönük uyumluluk nedeniyle eski veya önerilmeyen seçenekleri de gösterebilir.

Burada özellikle önemli bir ayrım vardır: OpenSSL’in enc komutu GCM ve CCM gibi AEAD modlarını desteklemez ve resmi dokümantasyon, bu komutun authenticated encryption modlarını desteklemediğini açıkça belirtir. Bunun sebebi, authentication tag doğrulanmadan streaming çıktı üretmenin güvenli bir komut satırı davranışı oluşturmamasıdır. AES-GCM gibi AEAD yapılar OpenSSL’in EVP API’si veya bu iş için tasarlanmış güvenli kriptografi kütüphaneleriyle kullanılmalıdır.

OpenSSL ile parola tabanlı bir şifreleme yapıldığında, çıktı formatında çoğu zaman Salted__ öneki görülebilir. Bu format genel olarak şu yapıyı gösterir:

Burada Salted__ başlığı dosyanın salt içerdiğini gösterir. Hemen ardından gelen 8 bayt salt değeridir. Salt gizli değildir; asıl işlevi, aynı parolanın her kullanımında aynı anahtar türetme sonucunu üretmesini engellemeye yardımcı olmaktır.

OpenSSL enc ile parola tabanlı şifreleme yapıldığında salt, paroladan anahtar ve IV türetme sürecinde kullanılan açık meta verilerden biridir. Salt gizli tutulması gereken bir değer değildir; asıl görevi, aynı parolanın her kullanımda aynı anahtar/IV sonucunu üretmesini engellemeye yardımcı olmaktır. Modern ve güvenli kullanımda PBKDF2 gibi bir KDF tercih edilmeli; OpenSSL tarafında bunun için -pbkdf2 ve uygun bir -iter değeri açıkça kullanılmalıdır. PBKDF2 kullanılmadığında, kullanılan OpenSSL sürümüne ve parametrelere bağlı olarak eski veya uyumluluk amaçlı anahtar türetme davranışları görülebilir. Anahtar ve IV genellikle dosyaya açık alanlar olarak yazılmaz; parola, salt ve seçilen türetme yöntemi üzerinden elde edilir. Ancak -K ve -iv gibi seçeneklerle anahtar veya IV doğrudan verildiğinde bu akış değişir. Bu ayrım önemlidir: çıktıdaki her şey ciphertext değildir; bazı alanlar şifreleme işlemini tekrar çözebilmek için gerekli açık meta verilerdir.

Doğru yapılandırılmış parola tabanlı şifrelemede aynı veri ve aynı parola ile yapılan iki ayrı çalıştırmanın farklı ciphertext üretmesi beklenir. Bunun nedeni salt ve buna bağlı türetilen anahtar/IV değerlerinin farklılaşmasıdır. Ancak -nosalt, sabit salt, sabit IV veya doğrudan sabit anahtar kullanımı gibi seçenekler bu davranışı bozabilir. Aynı giriş ve aynı parola ile iki ayrı çalıştırmada birebir aynı çıktı üretiliyorsa salt, IV veya anahtar türetme süreci dikkatle incelenmelidir.

Kendini Değerlendir — Simetrik Şifreleme

OpenSSL ile AES-256-CBC Şifreli Dosya Çıktısını İnceleme

Eğitim ortamında OpenSSL ile anlamsız bir dosya üzerinde AES-256-CBC şifreleme deneyi yapılabilir. Bu çalışma yalnızca kavram görmek içindir; gerçek parola, gerçek anahtar veya hassas veri kullanılmamalıdır.

Hex dump ile çıktı incelendiğinde ilk 8 baytın Salted__ ASCII değerleri olduğu, sonraki 8 baytın salt olduğu ve geri kalan kısmın ciphertext olarak devam ettiği görülebilir. Bu gözlem, öğrencinin “şifreli veri” ile “şifreleme meta verisi” arasındaki farkı anlamasını sağlar.

Aynı giriş ve aynı parola ile tekrar şifreleme yapıldığında çıktıların farklı olması doğru davranış işaretidir. Eğer çıktı birebir aynıysa, yapılandırmada sabit salt, sabit IV, devre dışı salt veya deterministik bir kullanım olup olmadığı araştırılmalıdır.

Salt’ın ciphertext içinde açık görünmesi güvenlik açığı değildir. Salt gizli tutulmak için değil, anahtar türetme sürecini güçlendirmek ve aynı parolanın tekrar kullanımında aynı sonucu üretmesini engellemeye yardımcı olmak için kullanılır.

OpenSSL Algoritma Listesinde Modları Okumak

openssl enc -list çıktısında ECB, CBC, CFB, OFB veya CTR gibi mod adları görülebilir. Öğrenci burada özellikle mod adına bakmalıdır. -ecb son ekini taşıyan seçenekler genel amaçlı veri şifreleme için güvenli kabul edilmez. -cbc veya -ctr gibi modlar ise doğru IV/nonce yönetimi ve ayrıca bütünlük koruması olmadan tek başına modern güvenlik beklentisini karşılamaz.

GCM/CCM gibi AEAD modları openssl enc komutu üzerinden kullanılmamalıdır; zaten resmi dokümantasyon bu komutun authenticated encryption modlarını desteklemediğini belirtir. AEAD kullanılacaksa uygun kütüphane, API veya protokol seviyesi tercih edilmelidir.

Bu gözlem, araçta bir seçeneğin bulunmasının o seçeneğin güvenli olduğu anlamına gelmediğini gösterir. Güvenli kriptografi, araçta görünen her seçeneği kullanmak değil; bağlama uygun, güncel ve doğru yapılandırılmış seçeneği tercih etmektir.

Temel Seviye Güvenli Kullanım / Kontrol Listesi

Simetrik kriptografi içeren bir sistem, kod parçası veya yapılandırma incelenirken ilk bakılması gereken şey yalnızca “AES var mı?” sorusu değildir. Algoritmanın yanında çalışma modu, IV/nonce üretimi, authentication tag doğrulaması ve anahtar yönetimi de değerlendirilmelidir.

Bir sistemin hangi algoritmayı ve hangi modu kullandığı belgelerde, yapılandırma dosyalarında veya kaynak kodda araştırılmalıdır. Mod adı bilinmeden “AES kullanıyor” bilgisi güvenlik değerlendirmesi için yetersizdir.

ECB modu tespit edilirse bu genel amaçlı veri şifreleme açısından doğrudan tasarım sorunu olarak ele alınmalıdır. ECB, aynı düz metin bloklarından aynı ciphertext bloklarını üretir ve veri örüntülerini gizleyemez.

CBC kullanılıyorsa IV’nin nasıl üretildiği ve aynı anahtar altında tekrar edip etmediği incelenmelidir. CBC tek başına bütünlük sağlamadığı için ayrıca doğru bir MAC yapısı veya modern bir AEAD yaklaşımı bulunup bulunmadığı kontrol edilmelidir.

CTR, GCM veya ChaCha20 gibi nonce kullanan yapılarda kritik şart, aynı anahtar altında nonce değerinin tekrar etmemesidir. Nonce rastgele üretilebilir veya güvenli biçimde sayaç temelli yönetilebilir; asıl nokta tekrar etmemesidir.

Authentication tag ayrı bir alan olarak, ciphertext’in sonunda veya protokol formatının başka bir bölümünde yer alabilir. Tag’in hiç bulunmaması ya da doğrulanmaması, bütünlük korumasının eksik olabileceğini düşündürür.

Eski algoritmaların hâlâ etkin olup olmadığı kontrol edilmelidir. DES, 3DES/TDEA ve RC4 gibi algoritmalar modern sistemlerde yeni veri koruma amacıyla kullanılmamalıdır. RC4’ün TLS’te kullanılmaması gerektiği RFC 7465 ile açık biçimde belirtilmiştir.

Araç çıktısında veya yapılandırma dosyasında görülen algoritma, güncel standartlarla ve güvenlik rehberleriyle karşılaştırılmalıdır. NIST’in AES, blok şifre modları ve GCM belgeleri bu konuda temel başvuru kaynaklarıdır.

Şifreli metnin okunamıyor olması tek başına güvenlik anlamına gelmez. Gizlilik ayrı, bütünlük ayrı bir güvenlik hedefidir. Ayrıca bir aracın GCM gibi bir yapıyı desteklemesi, sistemin gerçekten GCM kullandığı anlamına gelmez. Desteklemek ile aktif ve doğru kullanmak farklıdır.

Bir bulguda “AES-ECB kullanılıyor” tespiti yapılırsa geliştirici veya güvenlik ekibine şu şekilde aktarılabilir:

Mevcut şifreleme yapılandırması ECB modunu kullanıyor. Bu mod, aynı düz metin bloklarının ciphertext içinde de aynı bloklar olarak görünmesine yol açar ve veri örüntülerini korur. Genel amaçlı veri şifreleme için ECB kullanılmamalıdır. AES-GCM veya ChaCha20-Poly1305 gibi AEAD sağlayan modern yaklaşımlara geçilmesi; nonce/IV değerlerinin aynı anahtar altında tekrar etmemesi ve authentication tag doğrulamasının zorunlu hâle getirilmesi önerilir.

Analitik Senaryo

Yerel test ortamında çalışan bir uygulama, kullanıcı oturumu verilerini şifreli biçimde bir veritabanına kaydettiğini belirtiyor. Uygulamanın kaynak kodunda AES ve ECB ifadeleri geçiyor. Farklı kullanıcıların “aynı tercihler” içeren oturum kayıtları incelendiğinde, ciphertext değerlerinin belirli bayt aralıklarında birebir örtüştüğü görülüyor.

İlk değerlendirme şu olmalıdır: Ciphertext içinde tekrar eden aynı blokların gözlemlenmesi, ECB modunun kullanıldığı iddiasıyla uyumludur. ECB, aynı düz metin bloğunu aynı anahtarla her zaman aynı ciphertext bloğuna dönüştürür. Bu nedenle aynı içeriği taşıyan kullanıcı kayıtları, şifreli hâlde bile blok düzeyinde birbirine benzeyebilir.

Bu durumda kaç kullanıcı kaydının aynı blok yapısını paylaştığı, örtüşmenin hangi pozisyonlarda gerçekleştiği ve bu pozisyonların oturum verisinin hangi alanlarına karşılık gelebileceği incelenmelidir. Aynı zamanda herhangi bir bütünlük doğrulama mekanizmasının bulunup bulunmadığı da kontrol edilmelidir.

Veritabanındaki ciphertext değerleri hex olarak gösterildiğinde, farklı kullanıcılara ait kayıtların belirli aralıklarında birebir aynı 16 baytlık bloklar görülebilir. AES’in blok boyutu 128 bit, yani 16 bayt olduğu için bu tür blok tekrarları ECB kullanımına dair güçlü bir işarettir. Ancak nihai doğrulama kaynak kod, yapılandırma veya kullanılan kütüphane çağrıları üzerinden yapılmalıdır.

Buradaki yanlış yorumlama şudur: “Veri şifrelenmiş görünüyor, o hâlde yeterince güvenli.” ECB modunda şifrelenen veri doğrudan okunamayabilir; fakat veri yapısındaki tekrarlar ve örüntüler korunabilir. Bir saldırgan veriyi çözmeden, yalnızca ciphertext bloklarını karşılaştırarak hangi kullanıcıların benzer oturum yapısına sahip olduğunu veya hangi alanların aynı değerleri taşıdığını çıkarabilir.

Riskin pratik karşılığı önemlidir. Bu sistemde saldırgan, birden fazla kullanıcının şifreli oturum kayıtlarını karşılaştırarak “hangi kullanıcılar aynı tercihlere sahip”, “hangi oturumlar benzer içerik taşıyor” veya “hangi veri alanları sabit” gibi çıkarımlar yapabilir. Şifreleme yalnızca ham verinin okunmasını değil, verinin yapısal örüntülerinin de korunmasını hedeflemelidir. ECB bunu sağlayamaz.

Geliştirici ekibe öneri şu şekilde aktarılabilir:

Oturum verilerinin ECB modunda şifrelendiği tespit edildi. Bu mod, aynı düz metin bloklarından aynı ciphertext bloklarını üretir ve veri örüntülerini korur. AES-GCM veya ChaCha20-Poly1305 gibi AEAD sağlayan modern bir yaklaşıma geçilmesi önerilir. Her şifreleme işlemi için aynı anahtar altında benzersiz nonce/IV kullanılmalı ve authentication tag mutlaka doğrulanmalıdır. Nonce rastgele üretilebilir veya güvenli sayaç mantığıyla yönetilebilir; kritik nokta tekrar etmemesidir.

Terimler Sözlüğü

Bu Modülde Neler Öğrendik?

Bu modül, simetrik kriptografinin teorik öğrenimden gerçek sistemlere nasıl taşındığını kavramsal düzeyde ortaya koydu.

Öğrenci artık simetrik şifrelemenin tek anahtar modelini biliyor ve bu modelin en önemli pratik kısıtının anahtar paylaşım problemi olduğunu anlıyor. Hız avantajı nedeniyle büyük veri şifrelemenin neredeyse her zaman simetrik kriptografiyle yapıldığı, asimetrik kriptografinin ise genellikle anahtar anlaşması veya kimlik doğrulama aşamasında devrede olduğu fikri netleşti.

Blok şifre ile akış şifresi arasındaki fark yerli yerine oturdu. AES’in neden tercih edilen standart olduğu, DES ve 3DES/TDEA’nın neden artık üretim sistemlerinde yeni veri koruma amacıyla kullanılmaması gerektiği gerekçesiyle anlaşıldı.

Çalışma modları konusu bu modülün en kritik parçalarından biriydi. ECB’nin neden güvensiz olduğu, örüntüleri neden koruduğu ve bu sorunun CBC veya CTR gibi modlarla nasıl farklı biçimlerde ele alındığı kavramsal düzeyde yerleşti. Ancak CBC ve CTR’nin de kendi başına “otomatik güvenli” olmadığı; IV, nonce, sayaç ve bütünlük doğrulaması gerektirdiği görüldü.

“Sadece şifreleme yetmez” ilkesi AEAD ve GCM bölümünde somutlaştı. Gizlilik ile bütünlük garantisinin ayrı ihtiyaçlar olduğu ve modern sistemlerin her ikisini de birlikte karşılaması gerektiği artık açık. Authentication tag doğrulanmadan plaintext’in güvenilir kabul edilmemesi gerektiği öğrenildi.

Akış şifreleri bölümünde RC4’ün neden terk edildiği ve ChaCha20-Poly1305’in neden modern bir AEAD alternatifi olduğu görüldü. Aynı anahtar ve nonce kombinasyonunun tekrar kullanılmasının two-time pad problemine yol açabileceği, OTP modülündeki anahtar tekrarı sezgisiyle ilişkilendirildi.

Araç okuryazarlığı açısından öğrenci, OpenSSL çıktısında salt ve ciphertext gibi alanları ayırt edebilir; Salted__ önekinin ne anlama geldiğini yorumlayabilir; algoritma listesinde güvenli ve güvensiz seçenekleri ayırırken “araçta var” ile “güvenli kullanılır” arasındaki farkı görebilir. Ayrıca OpenSSL enc komutunun GCM/CCM gibi AEAD modları için uygun olmadığını ve AEAD kullanımının doğru kütüphane/API seviyesinde yapılması gerektiğini kavramış olur.

Son olarak, ECB modu tespitini bir güvenlik bulgusu olarak nasıl doğru aktaracağını bilen öğrenci, simetrik kriptografiyi kullanan bir sistemi değerlendirirken hangi soruları soracağını ve hangi noktaların uzman inceleme gerektirdiğini kavramış oldu.

Önceki modüllerde simetrik şifrelemenin gizliliği nasıl sağladığını gördük. Bu modülde ise gizlilik dışındaki kriptografik hedeflere — bütünlük, kaynak doğrulama, anahtar türetme ve kimlik bilgisi koruması — hangi araçlarla ulaşıldığını ele alacağız. Modülün sonunda öğrenci, SHA-2 ile MD5 arasındaki farkı, HMAC ile plain hash arasındaki ayrımı, HKDF ile PBKDF2’nin neden farklı amaçlara hizmet ettiğini ve güvenli parola saklama için gerçekte ne gerektiğini açık biçimde ifade edebilir hâle gelecektir.

Hash’in parola saklama, dosya bütünlüğü ve dijital imza gibi farklı kullanım alanlarını birbirinden ayırt edebilir; her bağlamda doğru aracı önerebilir.

MAC ve HMAC’in plain hash’ten farkını açıklayabilir; anahtar olmadan kaynak doğrulamanın neden garanti edilemediğini somut bir örnekle ifade edebilir.

KDF kavramını, HKDF ve PBKDF2’nin ne işe yaradığını ve salt kullanımının neden önemli olduğunu temel düzeyde anlatabilir.

Parolaların neden düz hash ile saklanmaması gerektiğini; bcrypt, scrypt ve Argon2’nin bu sorunu nasıl ele aldığını ve memory-hard kavramının pratik anlamını açıklayabilir.

OpenSSL ile üretilen hash çıktısını tanıyabilir, dosya bütünlüğü doğrulaması için bir hash değerini nasıl yorumlayacağını bilir.

Hash kırma araçlarının varlığını, çalışma mantığını ve bunun parola saklama kararları üzerindeki etkisini etik çerçevede değerlendirebilir.

Bir geliştirici veya güvenlik ekibine “bu sistemde parola saklama yanlış yapılmış” diyebilecek temel farkındalığa sahip olur ve doğru yaklaşımı kısaca önerebilir.

Hash, MAC, KDF ve parola hashleme araçlarının çıktılarını birbirinden ayırt edebilir; hangi alanın ne anlama geldiğini yorumlayabilir.

Kriptografik Hash Fonksiyonları

Hash fonksiyonu, herhangi bir uzunluktaki veriyi alıp sabit uzunlukta bir çıktıya — hash değeri ya da özet — dönüştüren matematiksel bir fonksiyondur. Bu tanım basit görünse de kriptografik güvenliği sağlayan birkaç kritik özellik, bu fonksiyonu sıradan bir veri dönüştürme veya sıkıştırma işleminden ayırır. NIST’in Secure Hash Standard dokümanı, hash algoritmalarının mesajlardan özet üretmek ve mesajların değişip değişmediğini tespit etmek için kullanıldığını belirtir.

Sabit uzunluklu çıktı, hash fonksiyonlarının temel özelliklerinden biridir. SHA-256 her zaman 256 bit, yani 32 byte uzunluğunda çıktı üretir. Girdi tek bir karakter de olsa, gigabaytlık bir dosya da olsa çıktı uzunluğu değişmez. Bu özellik hash değerlerinin karşılaştırılmasını ve saklanmasını öngörülebilir kılar.

Deterministik yapı, aynı girdinin her zaman aynı çıktıyı üretmesi anlamına gelir. Bu doğrulama için zorunludur. Bir dosyanın hash değerini hesaplayıp daha önce kayıt edilen değerle karşılaştırmak, bütünlük denetiminin temelidir.

Ön görüntü direnci, hash değerinden bu değeri üreten girdiyi bulmanın pratik hesaplama kaynaklarıyla uygulanamaz derecede zor olmasıdır. Ancak burada önemli bir ayrım vardır: Girdi kısa, düşük entropili veya tahmin edilebilir ise saldırgan olası girdileri deneyerek aynı hash değerine ulaşabilir. Örneğin kısa bir parola, kullanıcı adı, timestamp veya tahmin edilebilir token hashlenmiş olsa bile saldırgan bu değerleri deneyebilir. Hash fonksiyonu, zayıf girdiyi kendiliğinden güçlü hâle getirmez.

İkinci ön görüntü direnci, belirli bir girdiyi ve onun hash değerini bilen saldırganın, aynı hash değerini üreten farklı bir girdi bulmasının pratikte çok zor olmasıdır. Bu özellik özellikle belge doğrulama ve dijital imza gibi bağlamlarda önemlidir.

Çakışma direnci, iki farklı girdinin aynı hash değerini üreten bir çift olarak pratik hesaplama kaynaklarıyla bulunamaması anlamına gelir. Matematiksel olarak çakışmalar kaçınılmazdır; çünkü sonsuz sayıda olası girdi, sonlu uzunlukta hash çıktısına eşlenir. Güvenlik, bu çakışmaların saldırgan tarafından pratikte bulunamamasına dayanır.

Hash fonksiyonu şifreleme değildir. Şifrelemede anahtar kullanılır, çıktı doğru anahtarla tersine çevrilebilir ve verinin gizliliği korunur. Hash’te anahtar yoktur, işlem tek yönlüdür ve amaç verinin gizlenmesi değil, verinin kriptografik parmak izinin çıkarılmasıdır. Bu iki kavramı karıştırmak gerçek sistemlerde kritik tasarım hatalarına yol açar.

Hash fonksiyonlarının dijital sistemlerdeki yeri son derece geniştir. İndirdiğiniz bir yazılım paketinin web sitesinde yayınlanan SHA-256 değeriyle eşleşip eşleşmediğini kontrol etmek dosya bütünlüğü denetimidir. Dijital imza oluşturulurken çoğu zaman mesajın tamamı doğrudan imzalanmaz; önce mesajın hash değeri hesaplanır, ardından imza işlemi bu özet ve imza algoritmasının kuralları üzerinden gerçekleştirilir. Burada dijital imza yalnızca “hash’i özel anahtarla şifrelemek” olarak düşünülmemelidir; güvenli imza yapıları uygun padding, encoding, algoritma ve doğrulama adımlarıyla birlikte tanımlanır.

Yaygın Hash Aileleri

Kriptografik hash dünyasında öğrencinin mutlaka ayırt edebilmesi gereken birkaç ana aile vardır.

MD5, 1991’de yayınlanmış, 128 bit çıktı üreten ve bugün kriptografik güvenlik için terk edilmiş bir algoritmadır. MD5’in çakışma direnci pratik olarak kırılmıştır. Aynı MD5 değerine sahip farklı girdiler üretmek mümkündür; bu nedenle dijital imza, sertifika, güvenlik kararı veya çakışma direnci gerektiren bağlamlarda kullanılmamalıdır. RFC 6151, MD5’in çakışma direnci gereken durumlarda kullanılmasının artık uygun olmadığını açıkça belirtir.

MD5’e eski sistemlerde veya yalnızca hata yakalama/checksum gibi güvenlik dışı bağlamlarda rastlanabilir. Ancak güvenlik kararlarına dayanan hiçbir modern tasarımda MD5 kullanılmamalıdır.

SHA-1, 160 bit çıktı üretir. SHA-1’in çakışma direnci pratik olarak kırılmıştır ve dijital imza, sertifika, zaman damgası veya çakışma direnci gerektiren güvenlik bağlamlarında kullanılmamalıdır. NIST, SHA-1’in kriptografik koruma amacıyla kullanımdan çıkarılıp SHA-2 veya SHA-3 ailesine geçilmesi gerektiğini duyurmuştur.

Eski sistemlerde SHA-1 doğrulama veya uyumluluk amacıyla karşımıza çıkabilir. Ancak yeni tasarımlarda SHA-1 tercih edilmemeli; SHA-2 veya SHA-3 ailesi kullanılmalıdır.

SHA-2 ailesi, günümüzde en yaygın kullanılan güvenli hash ailelerinden biridir. SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 ve SHA-512/256 gibi üyelerden oluşur. Pratikte SHA-256 en yaygın tercihlerden biridir. TLS sertifikaları, dosya bütünlüğü doğrulamaları, dijital imza yapıları ve birçok modern protokolde karşımıza çıkar. FIPS 180-4, SHA-2 ailesinin bu üyelerini tanımlar.

SHA-512 daha uzun çıktı üretir ve bazı platformlarda performans açısından da avantajlı olabilir. Ancak “daha uzun çıktı her bağlamda otomatik olarak daha iyi güvenlik sağlar” gibi düşünülmemelidir. Tercih, protokolün ihtiyacına, güvenlik seviyesine ve uygulama bağlamına göre yapılmalıdır.

SHA-3 ve Keccak, SHA-2’den bağımsız tasarıma sahip bir hash ailesidir. SHA-3, Keccak algoritmasına dayanır ve NIST tarafından FIPS 202 ile standartlaştırılmıştır. SHA-2’ye alternatif sunar; ayrıca farklı tasarım yapısıyla kriptografik çeşitlilik sağlar.

MD5 veya SHA-1’in hâlâ bazı araçlarda görünmesi, bu algoritmaların güvenli olduğu anlamına gelmez. Araç desteği ile güvenlik önerisi aynı şey değildir.

MD5 şifreleme değildir ve güvenlik açısından kırılmış kabul edilir. Dosya transferi sonrası basit hata yakalama gibi güvenlik dışı bağlamlarda karşımıza çıkması, onu güvenli yapmaz.

Hash Kullanım Alanları

Hash fonksiyonlarının pratikte doğru bağlamda kullanılması, güvenli sistem tasarımının temel gerekliliklerinden biridir.

Dosya bütünlüğü, hash fonksiyonlarının en doğrudan kullanım alanlarından biridir. Bir dosyanın hash değeri hesaplanır, bu değer güvenilir bir kanaldan yayınlanır; alıcı dosyayı indirdikten sonra hash değerini yeniden hesaplar ve karşılaştırır. Değerler eşleşiyorsa dosya, güvenilir referans hash değerine göre değişmemiş demektir. Ancak referans hash değeri güvenilir bir kanaldan alınmamışsa, saldırgan dosyayı ve hash değerini birlikte değiştirebilir. Bu durumda yalnızca hash karşılaştırması güvenilir bütünlük garantisi sağlamaz.

Veri doğrulama, veri tabanı kayıtlarının, yapılandırma dosyalarının veya kritik sistem dosyalarının bütünlüğünü izlemek için kullanılabilir. Bir dosya değiştirildiğinde hash değeri de değişir. Bu basit ama etkili bir iz bırakma mekanizmasıdır. Ancak saldırganın hem veriyi hem de referans hash değerini değiştirebildiği durumlarda, anahtarsız hash tek başına yeterli değildir.

Dijital imza öncesi özetleme, hash fonksiyonlarının önemli kullanım alanlarından biridir. Büyük dosyaların doğrudan imzalanması yerine önce hash değerinin hesaplanması, ardından bu özetin imza algoritması tarafından kullanılması performans ve güvenlik açısından anlamlıdır. Mesaj değişirse hash değeri değişir; dolayısıyla imza doğrulaması başarısız olur. Bu, dijital imzanın bütünlük garantisinin temel parçalarından biridir.

Bir mesajın hash değeri güvenilir bir referans değerle eşleşiyorsa, mesajın o referansa göre değişmediği söylenebilir. Ancak bu, mesajın gerçekten beklenen kaynaktan geldiğini göstermez. Kaynak doğrulama için HMAC gibi anahtar kullanan bir yapı veya dijital imza gerekir.

Hash’in parola saklama ile karıştırılmaması gerekir. Bir kullanıcı parolasının SHA-256 gibi genel amaçlı bir hash fonksiyonuyla hashlenip veritabanında saklanması, yaygın ama tehlikeli bir yaklaşımdır. Genel amaçlı hash fonksiyonları hız için tasarlanmıştır; parola saklama ise saldırganın tahmin denemelerini yavaşlatmayı gerektirir. Bu ayrım modülün parola saklama bölümünde ayrıntılı ele alınacaktır.

Mesaj Doğrulama Kodları

Hash fonksiyonları, verinin güvenilir bir referansa göre değişip değişmediğini gösterebilir; fakat mesajın kim tarafından gönderildiğini tek başına garanti etmez. Bir saldırgan mesajı değiştirebilir, hash değerini yeniden hesaplayabilir ve alıcıya teslim edebilir. Alıcı yalnızca hash karşılaştırması yapıyorsa sahte mesajı kabul edebilir.

Bu boşluğu kapatmak için mesaj doğrulama kodları, yani MAC yapıları kullanılır.

MAC, bir mesajın değiştirilmediğini ve paylaşılan gizli anahtarı bilen yetkili taraflardan biri tarafından üretildiğini doğrulamak için kullanılan kriptografik değerdir. Hash’ten temel farkı anahtarın varlığıdır. Anahtarı bilmeyen bir taraf geçerli bir MAC üretemez; dolayısıyla mesajı değiştirip geçerli bir MAC eklemesi beklenmez.

HMAC, hash tabanlı mesaj doğrulama kodudur. SHA-256 gibi bir hash fonksiyonunu ve gizli bir anahtarı tanımlı bir yapıyla birleştirerek MAC değeri üretir. RFC 2104, HMAC’i kriptografik hash fonksiyonlarıyla mesaj doğrulama sağlayan bir mekanizma olarak tanımlar.

HMAC, anahtarı ve mesajı basitçe yan yana koyup hashlemek değildir. Yani hash(secret || message) gibi basit bir yapı HMAC yerine geçmez. HMAC, güvenlik için tanımlanmış iç/dış hash yapısı kullanır. Bu ayrım özellikle length extension gibi saldırı sınıflarını anlamak için ilerleyen konularda önem kazanır.

CMAC, blok şifresi tabanlı MAC değeridir. AES gibi bir blok şifresi kullanır. Özellikle bazı gömülü sistemlerde, donanım güvenlik modüllerinde veya belirli protokol bağlamlarında tercih edilebilir.

MAC ile dijital imza farkı çok önemlidir. MAC, paylaşılan gizli bir anahtara dayanır; yani hem gönderen hem alıcı aynı anahtarı bilir. Bu nedenle MAC, inkâr edememe sağlamaz. Aynı anahtarı bilen herkes geçerli MAC üretebilir. Dijital imza ise açık/özel anahtar çiftine dayanır; imzayı yalnızca özel anahtara sahip taraf üretir, doğrulamayı ise açık anahtara sahip herkes yapabilir. Bu nedenle dijital imza, doğru sertifika ve anahtar yönetimiyle birlikte inkâr edememe hedefine katkı sağlar.

Bir API güvenlik tasarımında mesaj içeriği yalnızca plain hash değeriyle doğrulanmaya çalışılıyorsa bu bir tasarım hatasıdır. Kaynak doğrulama ve bütünlük garantisi birlikte gerekiyorsa HMAC gibi anahtar kullanan bir yapı tercih edilmelidir.

Anahtar Türetme Fonksiyonları

Kriptografik işlemlerde kullanılan anahtarların doğrudan kullanıcıdan alınan bir paroladan veya uygun biçimde işlenmemiş bir sırdan elde edilmesi güvenli değildir. Anahtar türetme fonksiyonları, yani KDF’ler, bu ihtiyaca göre tasarlanmıştır.

KDF, bir gizli değerden belirli uzunlukta ve belirli amaca uygun kriptografik anahtar materyali üretir. Ancak tüm KDF’ler aynı amaçla kullanılmaz. Parola tabanlı KDF’ler salt ve maliyet parametresiyle saldırganın parola tahmin denemelerini pahalılaştırır. HKDF gibi yapılar ise yüksek entropili bir sırdan farklı amaçlara uygun anahtar materyali üretmek için kullanılır ve kasıtlı yavaşlatma amacı taşımaz.

HKDF, “HMAC-based Key Derivation Function” olarak açılır. Temel amacı yüksek entropili bir gizli değeri — örneğin Diffie-Hellman anahtar anlaşmasından çıkan ortak sırrı — belirli amaçlar için kullanılabilir anahtarlara dönüştürmektir. HKDF, parolalardan anahtar türetmek için tasarlanmış yavaşlatılmış parola tabanlı KDF değildir. RFC 5869, HKDF’yi HMAC tabanlı extract-and-expand yaklaşımı kullanan bir KDF olarak tanımlar.

PBKDF2, “Password-Based Key Derivation Function 2” olarak açılır. Kullanıcı parolasını alır, salt değeriyle birleştirir ve belirli sayıda tekrarlanan işlemle anahtar üretir. Bu tekrarlama, yani iteration süreci, saldırganın milyonlarca parola tahminini hızlıca denemesini daha maliyetli hâle getirir.

PBKDF2 hâlâ bazı standart ve uyumluluk bağlamlarında kabul edilebilir bir parola tabanlı KDF’dir. Ancak bellek maliyeti getirmediği için GPU/ASIC tabanlı saldırılara karşı Argon2id veya scrypt gibi memory-hard seçeneklere göre daha zayıf kalabilir. Bu nedenle yeni sistemlerde parola saklama için çoğu durumda Argon2id gibi modern seçenekler tercih edilir. OWASP Password Storage Cheat Sheet, modern parola saklama algoritmaları ve salt kullanımının önemini açıkça vurgular.

Salt, KDF veya parola hashleme sürecine eklenen gizli olmayan benzersiz değerdir. Aynı parolaya sahip iki kullanıcının veritabanında farklı hash değerlerine sahip olmasını sağlar. Salt, genel amaçlı önceden hesaplanmış rainbow table saldırılarını pratik olmaktan çıkarır; çünkü her kullanıcı için farklı girdi oluşur. Ancak saldırgan salt değerini biliyorsa, her kullanıcı için ayrı parola tahmin denemeleri yapabilir. Bu yüzden salt, maliyetli parola hashleme fonksiyonlarıyla birlikte kullanılmalıdır.

Salt parolanın gizli entropisini artırmaz. Zayıf parola hâlâ zayıf paroladır. Salt’ın görevi kullanıcılar arasında benzersizlik sağlamak ve önceden hesaplanmış saldırıları etkisizleştirmektir; parola gücünü tek başına artırmak değildir.

Anahtar türetme ile parola saklama farklı ihtiyaçlara yanıt verir. PBKDF2 bazı bağlamlarda her iki amaçla da kullanılabilir; fakat modern parola saklama için bcrypt, scrypt veya Argon2id gibi bu iş için tasarlanmış ve saldırganın deneme maliyetini artıran fonksiyonlar tercih edilmelidir.

Bir kullanıcının parola123 gibi düşük entropili parolasından hiçbir uygun türetme işlemi yapmadan AES anahtarı üretmeye çalışmak, anahtarı pratikte tahmin edilebilir hâle getirir. KDF bu riski salt ile benzersizlik sağlayarak ve maliyet parametresiyle her tahmin denemesini pahalılaştırarak azaltır. Fakat zayıf parolayı tamamen güvenli hâle getirmez.

Parola Saklama Temelleri

Parolaların güvenli biçimde saklanması, kriptografinin en fazla yanlış uygulandığı alanlardan biridir. Onlarca büyük veri ihlalinde milyonlarca kullanıcı parolasının sızdığı düşünüldüğünde, bu konuyu doğru anlamak kritik bir pratik güvenlik becerisidir.

Bir sistemin kullanıcı parolalarını SHA-256 ile hashleyip veritabanına kaydettiğini düşünelim. Veri tabanı sızdığında saldırgan bu hash değerlerini ele geçirir. SHA-256 güvenli bir kriptografik hash fonksiyonu olabilir; ancak çok hızlıdır. Parola saklama bağlamında hız, saldırganın avantajıdır. Modern donanımlar çok yüksek sayıda hash denemesi yapabilir. Saldırgan yaygın parola listelerini, kurallı tahminleri veya brute force yöntemlerini kullanarak zayıf parolaları hızla bulabilir.

Düz hashleme neden yetersizdir? Çünkü genel amaçlı hash fonksiyonları parola saklamak için değil, hızlı ve deterministik özet üretmek için tasarlanmıştır. Parola saklama ise saldırganın her tahmin denemesini pahalılaştırmayı gerektirir. Bu nedenle MD5, SHA-1, SHA-256 veya SHA-512 gibi genel amaçlı hash fonksiyonları tek başına parola saklama için kullanılmamalıdır.

Salt kullanımı, her kullanıcı için benzersiz bir değer üretilmesini sağlar. Salt parola ile birlikte işlenir ve hashleme çıktısını kullanıcıya özgü hâle getirir. Salt veritabanında açık olarak saklanabilir; gizli olması gerekmez. Modern parola hashleme algoritmalarının çoğu salt değerini çıktı formatının içine yerleştirir. Salt’ın amacı, aynı parolaya sahip kullanıcıların aynı hash değerine sahip olmasını engellemek ve önceden hesaplanmış tablo saldırılarını pratik olmaktan çıkarmaktır.

Pepper, salt gibi parola hashleme sürecine eklenen; fakat salt’tan farklı olarak veritabanında saklanmayan gizli bir değerdir. Pepper uygulama tarafında, veritabanından ayrı bir sır yönetim mekanizmasında, tercihen secrets vault veya HSM gibi güvenli alanlarda tutulmalıdır. Pepper sızarsa değiştirilmesi gerekir; ancak pepper değişimi mevcut parola hash’lerinin doğrulanmasını etkileyebileceği için dikkatli bir geçiş planı gerektirir. OWASP, pepper’ın veritabanından ayrı tutulması ve sır olarak yönetilmesi gerektiğini vurgular.

bcrypt, 1999’da Niels Provos ve David Mazières tarafından tasarlanmış, parola hashleme için özel olarak geliştirilmiş bir fonksiyondur. İç bünyesinde salt barındırır ve cost factor adı verilen parametreyle hesaplama maliyeti ayarlanabilir. Bu maliyet arttıkça işlem süresi uzar; sistemlerin hızlanmasına paralel olarak parametreyi yükseltmek mümkündür. bcrypt hâlâ yaygın ve kabul edilebilir bir seçenektir; ancak kullanılan kütüphanenin parola uzunluğu sınırları ve cost factor ayarı dikkatle değerlendirilmelidir.

scrypt, bellek yoğun biçimde çalışan bir parola hashleme fonksiyonudur. Büyük miktarda bellek gerektirdiği için GPU ve ASIC tabanlı paralel saldırılara karşı genel amaçlı hızlı hash fonksiyonlarına göre daha dayanıklıdır. Bellek maliyeti, saldırganın paralel deneme kapasitesini sınırlamayı hedefler.

Argon2, 2015 Password Hashing Competition yarışmasının kazananıdır. Argon2 ailesi üç varyanta sahiptir: Argon2d, Argon2i ve Argon2id. Argon2id, Argon2i ve Argon2d yaklaşımlarını hibrit biçimde birleştirdiği için genel amaçlı yeni sistemlerde yaygın biçimde önerilir. RFC 9106, Argon2’yi memory-hard fonksiyon olarak tanımlar ve Argon2id’i desteklenmesi gereken temel varyantlardan biri olarak konumlandırır.

Genel uygulama geliştiricileri için pratik öneri çoğu durumda Argon2id kullanmaktır. Argon2d ve Argon2i ayrımı daha özel tehdit modellerinde değerlendirilmelidir. Argon2id; bellek maliyeti, zaman maliyeti ve paralellik parametreleriyle GPU/ASIC tabanlı saldırıları pahalılaştırmayı hedefler.

Yeni bir sistem tasarlanıyorsa parola saklama için Argon2id ilk tercih olarak değerlendirilmelidir. Mevcut bir sistemde bcrypt veya scrypt doğru parametrelerle kullanılıyorsa bu kabul edilebilir olabilir. Ancak MD5, SHA-1 veya doğrudan SHA-256/SHA-512 ile parola saklanıyorsa bu ciddi bir güvenlik açığıdır ve geçiş planlaması gerekir.

Hızlı hash fonksiyonlarının parola saklama için uygun olmamasının temel sebebi şudur: SHA-256 ve benzeri genel amaçlı hash fonksiyonları hız için optimize edilmiştir. Parola saklama bağlamında hız, saldırganın avantajıdır. bcrypt, scrypt ve Argon2 kasıtlı olarak daha maliyetli çalışacak biçimde tasarlanmıştır. Bu “yavaşlık” bir kusur değil, güvenlik özelliğidir.

Yine de güçlü parola hashleme tek başına her şeyi çözmez. Zayıf ve yaygın bir parola, Argon2id veya bcrypt ile saklansa bile sözlük saldırısıyla bulunabilir. Bu nedenle parola saklama; güçlü parola politikası, çok faktörlü kimlik doğrulama, oran sınırlama, ihlal tespiti ve güvenli parola hashleme ile birlikte düşünülmelidir.

Hash, MAC ve Parola Saklama Araçları

Bu başlık, modülün konu ettiği kriptografik yapıların araç çıktılarında nasıl göründüğünü ve bu çıktıların nasıl yorumlanacağını ele alır.

OpenSSL ile Hash Çıktısı Okuma

OpenSSL, hash hesaplamak ve HMAC üretmek için yaygın kullanılan komut satırı araçlarından biridir. Bir dosya ya da metin üzerinden SHA-256 hash değeri hesaplandığında çıktı, hex formatında 64 karakterlik bir dize olarak görünür. Dosyada küçük bir değişiklik yapılırsa hash çıktısı tamamen farklı görünür. Bu, hash fonksiyonlarının avalanche etkisinin, yani girdideki küçük değişikliğin çıktıda büyük ve öngörülemez değişime yol açmasının görsel karşılığıdır.

Platform olarak OpenSSL dgst komutu kullanılabilir. Amaç, bir dosyanın SHA-256 hash değerini hesaplayarak bütünlük doğrulaması için referans değer üretmektir. Eğitim ortamında yalnızca uydurma veya lab verisiyle çalışılmalıdır. Gerçek parolalar, tokenlar, özel anahtarlar veya gizli veriler deney amaçlı kullanılmamalıdır. Yerel hash hesaplama normalde dosya içeriğini dışarı göndermez; ancak eğitimde hassas veriyle işlem yapılmaması daha güvenli alışkanlıktır.

Örnek çıktı:

Öğrenci çıktıda parantez içindeki dosya adını ve sonrasındaki 64 karakterlik hex değerini birlikte okumalıdır. Bu iki parça birden anlam taşır; değer tek başına bağlam olmadan yorumlanamaz.

Dosya değişmemişse aynı komut her çalıştırıldığında aynı hash değeri üretilir. Daha önce kaydedilen güvenilir referans hash değeriyle karşılaştırıldığında çıktı farklıysa, dosya değiştirilmiş ya da bozulmuş olabilir. Ancak referans hash değerinin güvenilir bir kaynaktan alınmış olması gerekir. Hash değeri güvenilmez bir kanaldan geliyorsa, saldırgan hem dosyayı hem de hash değerini değiştirebilir.

Hash değeri şifreli metin değildir. Hash tersine çevrilebilir bir çıktı değildir; orijinal veriyi korumak için değil, verinin parmak izini çıkarmak için kullanılır.

HMAC Çıktısı ile Plain Hash Çıktısının Farkı

HMAC çıktısı görsel olarak SHA-256 gibi plain hash çıktısına benzeyebilir; ikisi de hex formatında sabit uzunlukta bir değer olarak görünebilir. Fark, çıktının görünümünde değil, nasıl üretildiğindedir.

Plain hash hesaplanırken yalnızca veri kullanılır. HMAC hesaplanırken veriyle birlikte gizli bir anahtar kullanılır. Bu anahtara sahip olmayan bir taraf aynı HMAC değerini üretemez. Bu nedenle HMAC, mesajın değiştirilmediğini ve HMAC anahtarını bilen yetkili taraflardan biri tarafından üretildiğini doğrular. Ancak aynı anahtarı birden fazla taraf bildiği için dijital imza gibi inkâr edememe sağlamaz.

İki sistem arasındaki API trafiğinde mesajın yalnızca hash değeriyle “imzalandığı”, fakat hiçbir gizli anahtar kullanılmadığı görülürse bu önemli bir tasarım açığıdır. Saldırgan mesajı değiştirip hash değerini yeniden hesaplayabilir. Bağlamda HMAC veya eşdeğer bir MAC yoksa kaynak doğrulama yok demektir.

Kendini Değerlendir — Hash ve MAC

Parola Hashleme Araçlarının Çıktısını Tanıma

bcrypt çıktısı, düz hash çıktılarından görsel olarak ayrılır. Tipik bir bcrypt çıktısı şu yapıda görünür:

$2b$12$abcdefghijklmnopqrstuuK7Qh3VQpSxP5q9a9y4uH7xX2j7mQ1f2

Bu örnek yalnızca formatı göstermek içindir. Baş kısmındaki $2b$ bcrypt versiyonunu, ardından gelen 12 cost factor değerini, kalan bölüm ise salt ve hash değerinin birlikte kodlanmış hâlini temsil eder. Salt ayrı bir alanda saklanmak zorunda değildir; bcrypt çıktısının içine gömülüdür.

Aynı parola iki kez hashlendiğinde iki farklı bcrypt çıktısı üretilmesi beklenir. Bu doğru davranıştır; çünkü her işlemde farklı salt üretilir. Aynı parolanın farklı çıktılar üretmesi, doğrulamanın yapılamayacağı anlamına gelmez. Doğrulama sırasında saklanan hash formatındaki salt ve parametreler kullanılarak girilen parola tekrar işlenir ve sonuç güvenli biçimde karşılaştırılır.

Veritabanında parola değerleri $2b$, $argon2id$ veya benzeri bcrypt/Argon2 yapısı göstermiyorsa ve bunun yerine 32 ya da 64 karakterlik düz hex değerleri görülüyorsa, parolaların MD5, SHA-1 veya SHA-256 gibi genel amaçlı hash fonksiyonlarıyla saklandığı şüphesi doğar. Bu ciddi bir güvenlik bulgusudur.

bcrypt çıktısının “şifreli parola” olduğu düşünülmemelidir. bcrypt çıktısı geri döndürülerek parolaya ulaşılmaz. Doğrulama, gelen parolanın aynı parametrelerle yeniden işlenmesi ve saklanan değerle güvenli biçimde karşılaştırılması yoluyla yapılır.

Hash Kırma Araçlarının Etik Bağlamdaki Yeri

hashcat ve John the Ripper gibi araçlar, hash değerlerinden orijinal parolayı kurtarmak amacıyla brute force, sözlük saldırısı ve kural tabanlı tahmin yöntemlerini uygular. Bu araçlar yalnızca izinli güvenlik testlerinde — sızma testi, parola denetimi, kırmızı takım çalışması veya kontrollü lab ortamı — kullanılabilir.

Bu araçların varlığı, zayıf parola hashleme yaklaşımlarının gerçek dünyada ne kadar kırılgan olduğunu somut biçimde gösterir. MD5 gibi hızlı hash fonksiyonlarında saldırgan çok yüksek sayıda parola tahmini deneyebilir. bcrypt, scrypt ve Argon2 gibi parola hashleme fonksiyonları ise her tahmin denemesinin maliyetini artırır. Ancak zayıf ve yaygın bir parola, güçlü parola hashleme kullanılsa bile sözlük saldırısıyla bulunabilir. Bu yüzden parola gücü, parola saklama algoritması ve hesap koruma önlemleri birlikte değerlendirilmelidir.

Gerçek kullanıcıların parolalarını ya da izin alınmamış sistemlerden elde edilen hash değerlerini bu araçlarla işlemek etik ve hukuki ihlaldir. Bu araçlar yalnızca yetkili, izinli ve kontrollü ortamlarda çalıştırılmalıdır.

Komut & Araç Okuryazarlığı

Bu modülde araç okuryazarlığı, hash, HMAC ve parola hashleme çıktılarının nasıl göründüğünü ayırt etmeye odaklanır. Amaç komut ezberi değil, çıktı okuma becerisidir.

CyberChef ile Hash ve Encoding Çıktısını Karşılaştırma

CyberChef, tarayıcı tabanlı ve görsel bir dönüştürme aracıdır; kriptografi kavramlarını görselleştirmek için faydalıdır. Bir metin üzerinde SHA-256 hash, Base64 encoding ve AES şifreleme sonuçlarını yan yana görmek, bu üç kavramı — hash, encoding ve encryption — sezgisel olarak birbirinden ayırt etmeye yardımcı olur.

Bu tür araçlara gerçek parola, anahtar, token veya gizli veri girilmemelidir. Yalnızca uydurma ve anlamsız test verileri kullanılmalıdır.

Aynı girdi için beklenen davranışlar şöyledir:

Base64 çıktısı şifreli metin sanılabilir. Aradaki fark açıktır: Base64 yalnızca format dönüşümüdür, anahtara gerek yoktur ve kolayca tersine çevrilir. Bu nedenle gizlilik sağlamaz.

Bu karşılaştırma egzersizi, öğrencinin hash/encoding/encryption üçgenini birbirinden ayırt etmesi için kritik bir sezgi kazandırır.

OpenSSL ile HMAC ve Plain Hash Ayrımını Gözlemlemek

Bir dosyanın SHA-256 hash’i ile HMAC-SHA256 çıktısı görsel olarak benzer uzunlukta ve benzer formatta görünebilir. İkisi arasındaki fark, birinde gizli anahtarın kullanılmasıdır.

Plain hash, yalnızca dosya içeriğine bağlıdır. HMAC ise dosya içeriğiyle birlikte gizli anahtara da bağlıdır. Aynı dosya farklı HMAC anahtarlarıyla farklı HMAC değerleri üretir. Bu nedenle HMAC, yalnızca bütünlük değil, paylaşılan anahtara dayalı kaynak doğrulama da sağlar.

Burada öğrencinin çıkarması gereken sonuç şudur: Çıktının görüntüsü yeterli değildir. Bir değerin HMAC mi yoksa plain hash mi olduğunu anlamak için kullanılan komuta, koda veya dokümantasyona bakmak gerekir.

Temel Seviye Güvenli Kullanım / Kontrol Listesi

Bir sistem ya da kod tabanındaki hash, MAC, KDF ve parola saklama kararları değerlendirilirken önce hangi ihtiyacın hangi kriptografik araçla karşılandığı netleştirilmelidir. Dosya bütünlüğü, kaynak doğrulama, anahtar türetme ve parola saklama birbirinden farklı ihtiyaçlardır.

Veritabanında saklanan parola hash değerleri incelendiğinde $2b$, $argon2id$ veya benzeri bcrypt/Argon2 yapısı görülmelidir. 32 ya da 64 karakterlik düz hex değerler görülüyorsa, bu MD5/SHA-1/SHA-256 gibi genel amaçlı hash kullanıldığına işaret edebilir ve araştırılmalıdır.

Dosya bütünlüğü doğrulaması SHA-256, SHA-384, SHA-512 veya SHA-3 gibi güncel hash algoritmalarıyla yapılmalıdır. MD5 veya SHA-1 kullanan bileşenler tespit edilirse bunlar legacy veya zayıf bileşen olarak değerlendirilmelidir.

API mesaj doğrulamasında yalnızca plain hash kullanılıyorsa bu yetersizdir. Mesajın gerçekten beklenen taraflardan biri tarafından üretildiğini doğrulamak için HMAC veya başka bir anahtar kullanan MAC mekanizması gereklidir.

Parola hashleme için Argon2id, bcrypt veya scrypt kullanılıp kullanılmadığı kontrol edilmelidir. Her kullanıcı için benzersiz salt üretilmelidir. Argon2 veya bcrypt parametrelerinin güncel donanıma göre yeterli olup olmadığı zaman içinde yeniden değerlendirilmelidir.

HMAC anahtarının güvenli biçimde saklanıp saklanmadığı kontrol edilmelidir. Anahtar kod içine gömülmüşse, repository içinde tutuluyorsa veya loglara yazılıyorsa bu ciddi bir risktir.

KDF kullanımında salt eksikse, iteration/cost parametresi çok düşükse veya HKDF ile PBKDF2 gibi farklı amaçlara sahip yapıların birbirinin yerine kullanıldığı görülüyorsa bu durum ayrıca incelenmelidir.

Hash değeri gören bir analist bunu “şifreli veri” olarak yorumlamamalıdır. Hash tersine çevrilen bir şifreleme çıktısı değildir. Base64 kodlanmış veri de şifreli veri değildir. HMAC ve plain hash çıktısı görsel olarak benzer göründüğünden, hangisinin kullanıldığı yalnızca koda, komuta veya dokümantasyona bakılarak netleştirilebilir.

Geliştirici veya güvenlik ekibine şu şekilde öneri verilebilir:

Mevcut sistemde kullanıcı parolaları SHA-256 ile saklanmaktadır. Bu algoritma genel amaçlı bir hash fonksiyonudur ve parola saklama için tasarlanmamıştır. Parola saklama için Argon2id veya bcrypt kullanılması, her kullanıcı için benzersiz salt değeri üretilmesi ve yeterli maliyet parametresiyle yapılandırılması önerilmektedir.

Analitik Senaryo

Bir kurumun dahili web uygulaması, kullanıcı parolalarını veritabanında saklamaktadır. Güvenlik ekibi yapılandırma denetimi sırasında parola alanlarını inceliyor.

Veritabanındaki bir kullanıcı kaydı şu biçimde görünüyor:

kullanici_id: ogrenci01

parola_hash: 5f4dcc3b5aa765d61d8327deb882cf99

İlk değerlendirme şu olmalıdır: 32 karakterlik hex değer, 128 bitlik bir hash çıktısına işaret eder ve MD5 şüphesini güçlendirir. Verilen değer bilinen olarak password kelimesinin MD5 hash’iyle eşleştiği için bu örnekte MD5 kullanıldığı güçlü biçimde anlaşılır.

Kontrol edilecek ilk nokta, hash değerinin önünde $2b$, $argon2id$ veya benzeri modern parola hashleme formatını gösteren bir yapının bulunmamasıdır. Salt değeri görünmemektedir. Hash uzunluğu 32 hex karakterdir; bu SHA-256 değil, 128 bitlik bir çıktıdır. Bu da MD5 ihtimalini güçlendirir.

Aynı değerin başka kullanıcı kayıtlarında da görülüp görülmediği kontrol edilebilir. Eğer birden fazla kullanıcı aynı hash değerine sahipse bu kullanıcıların aynı parolayı kullandığını gösterir. Salt yokluğunda aynı parola her kullanıcı için aynı hash değerini üretir; bu da saldırganın işini kolaylaştırır.

Test ortamında aynı değerin hangi parolaya karşılık geldiğini doğrulamak için yaygın parola listeleriyle kontrollü karşılaştırma yapılabilir. Bu işlem yalnızca izinli ve kontrollü lab ortamında gerçekleştirilmelidir; gerçek sistem üzerinde izinsiz deneme yapılmamalıdır.

Buradaki yaygın yanlış yorum şudur: Bir geliştirici bu değeri şifreli veri zannedebilir ve “parolalar şifreli saklanıyor” diyebilir. Oysa hash, şifreleme değildir. Ayrıca MD5 hızlı bir hash fonksiyonu olduğu ve örnekte salt kullanılmadığı için zayıf veya yaygın parolalar sözlük, rainbow table veya brute force yöntemleriyle çok hızlı bulunabilir. Güçlü parolalarda süre değişse de MD5 parola saklama için uygun değildir.

Riskin pratik karşılığı büyüktür. Veritabanı sızdığında saldırgan, yaygın parola sözlükleriyle ve önceden hesaplanmış tablolarla büyük bölümü hızlıca kırabilir. Salt yokluğu durumu daha da kötüleştirir; bir parolanın kırılması aynı hash değerine sahip tüm kullanıcıları etkiler.

Güvenli yaklaşım, parola saklama mekanizmasının Argon2id veya uygun parametrelerle bcrypt/scrypt kullanacak şekilde yeniden tasarlanmasıdır. Her kullanıcı için benzersiz salt üretilmeli, mevcut kullanıcıların bir sonraki girişinde parolaları yeni sistemle yeniden hashlenmeli ve geçiş süreci dikkatli planlanmalıdır.

Güvenlik ekibine bulgu şu dille aktarılabilir:

Kullanıcı parolaları şu an salt eklenmeden MD5 ile saklanmaktadır. Bu parola saklama için güvenli bir yöntem değildir. Argon2id veya uygun parametrelerle bcrypt/scrypt tabanlı parola hashleme yapısına geçilmesi, her kullanıcı için benzersiz salt kullanılması ve mevcut hash’lerin kademeli olarak yeni formata taşınması gerekmektedir.

Terimler Sözlüğü

Bu Modülde Neler Öğrendik?

Bu modül, kriptografinin en pratik ve en sık yanlış uygulanan bölümlerinden birini ele aldı. Öğrenci artık hash fonksiyonu, MAC, KDF ve parola hashleme kavramlarını birbirinden net biçimde ayırt edebilir.

Kriptografik hash fonksiyonu tek yönlüdür, anahtarsızdır ve şifrelemeyle karıştırılmamalıdır. Gizlilik değil; bütünlük kontrolü, parmak izi çıkarma ve dijital imza gibi yapılarda özetleme amacıyla kullanılır.

MD5 ve SHA-1 kriptografik olarak kırılmış veya zayıflamış algoritmalardır. Yeni sistemlerde güvenlik kararlarında kullanılmamalıdır. SHA-2 ve SHA-3 aileleri modern alternatiflerdir.

Hash çıktısı tek başına kaynak doğrulaması anlamına gelmez. Bir mesajın nereden geldiğini doğrulamak için anahtar kullanan bir yapı — HMAC veya başka bir MAC mekanizması — ya da dijital imza gerekir.

HMAC ve plain hash çıktısı görsel olarak benzer görünebilir. Ancak aralarındaki yapısal fark, yani anahtarın varlığı ya da yokluğu, güvenlik açısından belirleyicidir.

KDF kavramı, bağlama göre farklı amaçlara hizmet eder. HKDF yüksek entropili ortak sırlardan anahtar materyali üretmek için kullanılırken, PBKDF2 gibi parola tabanlı KDF’ler düşük entropili parolalardan anahtar türetirken tahmin denemelerini maliyetli hâle getirmeyi amaçlar.

Kullanıcı parolalarının SHA-256 gibi genel amaçlı bir hash fonksiyonuyla saklanması kritik bir güvenlik hatasıdır. Parola saklama için özel tasarlanmış, maliyet parametresi olan ve tercihen memory-hard fonksiyonlar — Argon2id, bcrypt, scrypt — kullanılmalıdır.

bcrypt ve Argon2 çıktıları ile plain hex hash çıktıları veritabanında görsel olarak ayırt edilebilir. Bu fark, güvenlik denetiminde anlamlı bir bulgu işareti taşır.

Hash kırma araçlarının çalışma mantığını anlamak, zayıf parola saklama kararlarının gerçek dünya riskini somutlaştırır. Ancak bu araçlar yalnızca izinli, kontrollü ve etik güvenlik çalışmalarında kullanılmalıdır.

Veritabanındaki parola alanları incelenirken hash formatı, uzunluğu, salt yapısı ve kullanılan algoritma birlikte değerlendirildiğinde parola saklama güvenliği hakkında hızlı bir ön değerlendirme yapılabilir.

Güvenli parola saklama kararlarını geliştirici ve güvenlik ekibine sade ve doğru biçimde aktarmak için gereken temel dil bu modülle kazanılmıştır.

Modülün sonunda, asimetrik ve simetrik kriptografinin hibrit biçimde nasıl birleştirildiği kavramsal düzeyde görülecektir. Anahtar dosyalarını tanımak, PEM ve DER formatlarını ayırt etmek ve özel anahtarın neden korunması gerektiğini anlamak da bu modülün somut çıktıları arasındadır.

RSA’nın modern kullanımında doğru şema ve padding seçiminin neden önemli olduğunu; ham RSA işleminin doğrudan kullanılmaması gerektiğini kavrayabilir.

Diffie-Hellman anahtar anlaşmasının temel sezgisini kavrayabilir; iki tarafın önceden sır paylaşmadan ortak bir anahtara nasıl ulaşabildiğini açıklayabilir.

DH’nin şifreleme değil anahtar anlaşması olduğunu ve kimlik doğrulama olmadan aktif saldırgana karşı yeterli olmadığını ifade edebilir.

ECC’nin neden tercih edildiğini, küçük anahtar boyutlarıyla güçlü güvenlik sağlamasının pratik anlamını ve Curve25519/X25519 ile P-256’nın varlığını bilir.

Asimetrik kriptografinin şifreleme, anahtar taşıma/anlaşma ve dijital imza olmak üzere farklı kullanım bağlamlarını birbirinden ayırt edebilir.

Hibrit şifreleme fikrinin neden gerekli olduğunu ve asimetrik kripto ile simetrik kriptonun bu modelde nasıl rol aldığını temel düzeyde anlatabilir.

OpenSSL çıktısında RSA ve ECC anahtar dosyalarını tanıyabilir; PEM ve DER format farklarını ayırt edebilir.

Özel anahtarın ele geçirilmesinin veya yanlış paylaşılmasının somut güvenlik riskini ifade edebilir ve anahtar dosyalarının güvenli biçimde saklanmasının neden önemli olduğunu bilir.

Araç çıktısında anahtar türünü, uzunluğunu ve format bilgisini yorumlayabilir; bu bilgileri bir güvenlik değerlendirmesine aktarabilir.

6.1 Açık Anahtar Mantığı

Simetrik kriptografide şifreleyen ve şifre çözen taraflar aynı anahtarı kullanır. Bu, anahtar paylaşım problemi doğurur: iki taraf o gizli anahtarı nasıl güvenli biçimde paylaşacaktır? Asimetrik kriptografi bu probleme farklı bir yaklaşım getirir. Tek bir ortak anahtar yerine, matematiksel olarak ilişkili iki farklı anahtar kullanılır: açık anahtar ve özel anahtar.

Açık anahtar serbestçe paylaşılabilir. Bir web sitesinde yayınlanabilir, bir sertifika içinde taşınabilir veya karşı tarafa gönderilebilir. Özel anahtar ise yalnızca sahibinde kalır ve yetkisiz kişilerle paylaşılmamalıdır. Bu iki anahtar matematiksel olarak ilişkilidir; ancak kullanım amacı algoritmaya göre değişir.

RSA’da açık anahtar şifreleme, özel anahtar ise çözme için kullanılabilir. Dijital imzada özel anahtar imza üretir, açık anahtar imzayı doğrular. DH ve ECDH’de ise açık/özel anahtarlar doğrudan veri şifrelemek için değil, ortak sır üretmek için kullanılır. Bu yüzden “biriyle şifrelenen diğeriyle çözülür” ifadesi yalnızca belirli RSA kullanımını açıklamak için kullanılabilir; tüm asimetrik kriptografiyi temsil etmez.

Bu yapının arkasında tek yönlü işlem fikri vardır. Bir işlemi yapmak kolaydır; tersini yapmak ise uygun parametrelerle hesaplama açısından çok zordur. RSA’da iki büyük asal sayıyı çarpmak kolaydır; ancak ortaya çıkan büyük sayıyı tekrar asal çarpanlarına ayırmak pratikte çok zordur. Diffie-Hellman’da güvenlik sezgisi sonlu alanlarda ayrık logaritma problemine, ECC’de ise eliptik eğri ayrık logaritma problemine dayanır.

Simetrik kriptografiden en belirgin ayrım şudur: simetrik kriptoda tek anahtar hem gizlidir hem de iletişim kuran taraflarca bilinmek zorundadır. Bu anahtarın güvenli biçimde paylaşılması başlı başına bir sorundur. Asimetrik kriptoda ise açık anahtarın öğrenilmesi normaldir; risk, açık anahtarın sahte bir anahtarla değiştirilmesi veya özel anahtarın ele geçirilmesidir.

Bunu bir kilitli posta kutusu benzetmesiyle düşünebilirsiniz. Kutunun mektup atma bölümü herkese açıktır; isteyen kutuya mesaj bırakabilir. Ancak kutuyu açacak anahtar yalnızca sahibindedir. Kutunun nerede olduğunu bilmek, onu açabilmek anlamına gelmez. Bu benzetme asimetrik şifreleme fikrini anlatmak için faydalıdır; fakat dijital imza ve DH gibi kullanımlarda mekanizma farklılaştığı için benzetmenin sınırları olduğu unutulmamalıdır.

Gerçek dijital sistemlerde bu ayrım kritik uygulamalara yansır. Modern TLS’te sunucu açık anahtarını sertifika içinde sunar; bu açık anahtar çoğunlukla sunucu kimliğini doğrulamak ve el sıkışmadaki imzaları kontrol etmek için kullanılır. Oturum anahtarı ise genellikle ephemeral DH/ECDHE anahtar anlaşmasıyla üretilir. Yani modern TLS’te uygulama verisinin kendisi RSA ile şifrelenmez; uygulama verisi simetrik şifreleme ve AEAD yapılarıyla korunur.

Açık anahtarla şifreleme veya açık anahtara dayalı doğrulama yapılırken, açık anahtarın gerçekten beklenen kişiye veya sisteme ait olduğu doğrulanmalıdır. Aksi hâlde saldırgan kendi açık anahtarını araya sokabilir ve tarafları yanıltabilir. PKI ve sertifika altyapısı bu doğrulama problemini çözmek için kullanılır; bu konu sonraki modülde ayrıntılı ele alınacaktır.

6.2 RSA’ya Giriş

RSA, 1977’de Ron Rivest, Adi Shamir ve Leonard Adleman tarafından yayınlanmış ve uzun yıllar asimetrik kriptografinin en bilinen algoritmalarından biri olmuştur. Adını mucitlerinin soyadlarının baş harflerinden alır.

RSA’nın temel fikri şudur: iki büyük asal sayıyı çarpmak kolaydır; fakat ortaya çıkan büyük sayının hangi iki asal sayıdan elde edildiğini bulmak, yani tam sayı çarpanlara ayırma problemi, yeterince büyük parametrelerle pratikte çok zordur. Bu matematiksel asimetri RSA’nın güvenlik zeminini oluşturur.

Anahtar üretimi aşamasında iki büyük asal sayı seçilir, çarpılır ve bu çarpım ile bazı ek matematiksel işlemler aracılığıyla açık anahtar ve özel anahtar çifti türetilir. Açık anahtar yayınlanabilir; özel anahtar yalnızca sahibinde kalmalıdır. Temel eğitimde bu işlemlerin tüm formül ayrıntılarına girmek gerekmez; ancak güvenliğin büyük ölçüde çarpanlara ayırma probleminin zorluğuna ve doğru şema kullanımına dayandığını bilmek gerekir.

RSA’nın güvenli kullanımı yalnızca büyük asal sayılara dayanmaz. Modern RSA kullanımında doğru padding ve şema seçimi zorunludur. RSA şifrelemede RSA-OAEP, imzada ise RSA-PSS gibi güvenli şemalar tercih edilir. Ham RSA matematiksel işlemini doğrudan uygulamak güvenli bir tasarım değildir.

RSA anahtar uzunlukları da doğru yorumlanmalıdır. RSA-1024 modern güvenlik için yetersiz kabul edilir. RSA-2048 birçok güncel sistemde asgari kabul edilebilir seviye olarak görülür ve yaklaşık 112 bit güvenlik gücü sağlar. 128 bit güvenlik hedeflenen yeni ve uzun ömürlü tasarımlarda RSA-3072 veya P-256 gibi ECC seçenekleri değerlendirilir.

RSA-4096 daha geniş güvenlik marjı sağlayabilir; ancak hesaplama maliyeti de artar. Bu nedenle “daha büyük anahtar her zaman daha iyi tercihtir” şeklinde düşünülmemelidir. Anahtar uzunluğu, performans, protokol uyumluluğu, kullanım ömrü ve güvenlik hedefi birlikte değerlendirilmelidir.

RSA doğrudan büyük veri şifrelemek için kullanılmaz. Bunun iki temel nedeni vardır. Birincisi, RSA şifreleme anahtar boyutu ve kullanılan padding şeması nedeniyle sınırlı büyüklükte veriyle çalışır. İkincisi, RSA simetrik algoritmalara göre çok daha yavaştır. Pratikte RSA, küçük ve kritik değerlerin korunmasında, eski bazı protokollerde simetrik oturum sırrının taşınmasında veya dijital imzada kullanılmıştır. Büyük veri ise AES veya ChaCha20-Poly1305 gibi simetrik yapılarla şifrelenir.

Burada önemli bir ayrım vardır: RSA, Diffie-Hellman gibi gerçek anlamda bir anahtar anlaşması protokolü değildir. Eski bazı protokollerde RSA, istemcinin ürettiği oturum sırrını sunucunun açık anahtarıyla şifreleyip taşıması için kullanılmıştır. Bu anahtar taşıma modelidir. Modern protokollerde anahtar anlaşması için DH/ECDH, kimlik doğrulama ve imza için ise RSA/ECDSA/EdDSA gibi mekanizmalar tercih edilir. TLS 1.3’te eski RSA key exchange modeli bulunmaz; ephemeral Diffie-Hellman ailesi kullanılır.

Bir geliştirici RSA ile doğrudan büyük dosyalar şifrelemeye çalışıyorsa, bu çoğu zaman tasarım hatasına işaret eder. RSA’nın rolü genellikle küçük ve kritik anahtar materyalinin korunması veya imza üretimi/doğrulaması tarafındadır; veri şifreleme yükü simetrik kriptografiye bırakılır.

RSA hâlâ pek çok mevcut sistemde, sertifikada ve protokolde karşımıza çıkar. Ancak yeni tasarımlarda ECC tabanlı çözümler, daha küçük anahtar boyutuyla benzer güvenlik seviyesi ve daha iyi performans sunduğu için önemli bir yer kazanmıştır.

6.3 Diffie-Hellman Anahtar Anlaşması

Diffie-Hellman, 1976’da Whitfield Diffie ve Martin Hellman tarafından ortaya konan ve kriptografi tarihinde dönüm noktası kabul edilen bir anahtar anlaşması fikridir. Temel sorusu şudur: İki taraf, aralarında önceden hiçbir ortak sır paylaşmadan ve güvensiz bir kanalda iletişim kurarak ortak bir gizli değere nasıl ulaşabilir?

DH’nin temel mantığı sezgisel bir renk karışımı örneğiyle anlatılabilir. İki kişi, herkesin bildiği ortak bir başlangıç rengiyle başlar. Her biri kendi gizli rengini bu başlangıç rengine karıştırır ve ortaya çıkan karışımı karşı tarafa gönderir. Daha sonra her iki taraf da aldığı karışıma kendi gizli rengini ekler. Sonunda ikisi de aynı son renge ulaşır. Araya giren biri yalnızca ara karışımları görür; gizli renkleri bilmeden son rengi elde edemez.

Klasik finite-field DH’de bu sezginin matematiksel karşılığı belirli bir asal sayı, grup ve temel eleman üzerinden kurulur. Tarafların gizli değerleri büyük rastgele sayılardır. Açık değerler kanalda paylaşılır; ancak bu açık değerlerden gizli değeri çıkarmak ayrık logaritma problemi nedeniyle pratikte çok zordur.

DH pasif saldırgana karşı güçlü bir sezgi sunar. Yalnızca trafiği dinleyen bir saldırgan, tarafların paylaştığı açık değerleri görebilir; fakat gizli değerleri bilmeden ortak sırrı hesaplayamaz. Ancak DH tek başına aktif saldırgana karşı yeterli değildir. Araya giren bir saldırgan her iki tarafla ayrı ayrı DH değiş tokuşu yapabilir ve kendisini ortadaki taraf olarak konumlandırabilir. Bu MITM saldırısıdır.

Bu nedenle DH gerçek sistemlerde kimlik doğrulama mekanizmalarıyla birlikte kullanılır. Sertifika, dijital imza veya önceden doğrulanmış anahtarlar olmadan DH yalnızca pasif dinleyene karşı koruma sağlar; tarafların gerçekten beklenen kişiler olduğunu garanti etmez. TLS gibi protokoller, ephemeral DH/ECDHE anahtar anlaşmasını sertifika ve imza doğrulamasıyla birlikte kullanır.

DH şifreleme değildir; anahtar anlaşması protokolüdür. İki taraf DH sayesinde ortak bir sır üretir. Bu sır daha sonra KDF süreçlerinden geçirilerek simetrik şifreleme anahtarları gibi kullanıma hazır anahtar materyaline dönüştürülür. Verinin kendisi DH ile şifrelenmez.

ECDH, yani Elliptic Curve Diffie-Hellman, aynı anahtar anlaşması fikrinin eliptik eğri grupları üzerinde uygulanmasıdır. Modern sistemlerde klasik finite-field DH yerine çoğu zaman ECDH veya X25519 gibi eliptik eğri tabanlı anahtar anlaşması yapıları kullanılır.

6.4 Eliptik Eğri Kriptografisine Giriş

Asimetrik kriptografide kullanılan matematiksel problemler aynı değildir. RSA’nın güvenlik sezgisi büyük sayıların çarpanlarına ayrılmasının zorluğuyla ilişkilidir. Klasik Diffie-Hellman sonlu alanlarda ayrık logaritma probleminin zorluğuna dayanır. ECC ise benzer ayrık logaritma fikrini eliptik eğri grupları üzerinde kullanır.

ECC’nin temel avantajı, daha küçük anahtar boyutlarıyla benzer güvenlik seviyeleri sunabilmesidir. Bu fark mobil cihazlar, gömülü sistemler, yüksek hacimli sunucular ve düşük gecikme gerektiren protokoller için önemlidir.

Bu tablo yaklaşık güvenlik seviyesi karşılaştırmasıdır; kesin eşdeğerlik olarak okunmamalıdır. Algoritma ailesi, uygulama kalitesi, eğri seçimi ve protokol bağlamı sonucu etkiler.

256 bit ECC anahtarı, yaklaşık olarak 3072 bit RSA anahtarıyla benzer güvenlik seviyesi sunabilir. Bu doğrudan “256 bit her zaman 3072 bitten güçlüdür” anlamına gelmez; algoritma aileleri farklı matematiksel problemlere dayanır. Bu nedenle RSA ve ECC anahtar boyutları doğrudan karşılaştırılmamalıdır.

ECDH, eliptik eğri üzerindeki Diffie-Hellman anahtar anlaşmasıdır. Klasik DH’deki “ortak sır üretme” mantığı burada da geçerlidir; fark kullanılan matematiksel yapının eliptik eğri grubu olmasıdır.

ECC’de eğri seçimi güvenliği ve uyumluluğu doğrudan etkiler. Standart, iyi incelenmiş ve yaygın desteklenen eğriler kullanılmalıdır. Rastgele bir eğri seçmek veya kendi eğrisini tasarlamak temel seviyede kesinlikle kaçınılması gereken bir yaklaşımdır.

Curve25519 / X25519, Daniel Bernstein tarafından tasarlanan modern eğri ailesi ve bu eğri üzerinde kullanılan anahtar anlaşması fonksiyonuyla ilişkilidir. Curve25519 eğriyi, X25519 ise Diffie-Hellman için kullanılan fonksiyonu ifade eder. Hız, güvenli uygulama kolaylığı ve modern protokol desteği nedeniyle yaygın biçimde tercih edilir. Ancak yan kanal dayanıklılığı yalnızca eğri seçimine değil, kullanılan kütüphanenin constant-time ve güvenli uygulanmasına da bağlıdır.

P-256, diğer adıyla secp256r1 veya prime256v1, NIST tarafından standartlaştırılmış yaygın bir eliptik eğridir. TLS ekosisteminde hem ECDSA sertifika/imza bağlamında hem de ECDHE anahtar anlaşması tarafında sıkça karşımıza çıkar.

Temel seviyede bilinmesi gereken şudur: ECC’de hangi eğrinin kullanıldığı önemlidir. Curve25519/X25519, P-256 ve P-384 gibi tanınmış seçenekler standart kütüphaneler üzerinden kullanılmalıdır. Kendi ECC uygulamasını yazmak veya özel eğri seçmek ciddi risk taşır.

Güncel kriptografi dünyasında RSA, DH ve ECC gibi klasik açık anahtarlı sistemler uzun vadeli kuantum tehdidi nedeniyle post-quantum kriptografiyle birlikte değerlendirilmeye başlanmıştır. Bu modülün odağı klasik asimetrik kriptografidir; post-quantum geçişi ileri modüllerde ayrı ele alınmalıdır.

6.5 Asimetrik Kriptografinin Pratik Kullanımı

Asimetrik kriptografi gerçek sistemlerde birkaç farklı rolde karşımıza çıkar. Bu rolleri birbirinden ayırt etmek, kriptografi okuryazarlığının temel gereksinimlerinden biridir.

Şifreleme, alıcının açık anahtarıyla şifreli içerik üretme fikrine dayanır. Yalnızca alıcının özel anahtarı bu içeriği çözebilir. Uygulamada bu genellikle küçük veriler için geçerlidir. Büyük veri doğrudan asimetrik şifreleme ile işlenmez; hem performans hem de tasarım açısından bu uygun değildir.

Anahtar taşıma ve anahtar anlaşması birbirinden ayrılmalıdır. Eski RSA tabanlı yapılarda bir taraf bir oturum sırrı üretip karşı tarafın açık anahtarıyla şifreleyerek taşıyabilir. Bu anahtar taşıma modelidir. Diffie-Hellman ve ECDH ise iki tarafın güvensiz kanal üzerinde ortak bir sır üretmesini sağlayan anahtar anlaşması yöntemleridir.

Dijital imza, özel anahtarla imza üretme ve açık anahtarla doğrulama mantığına dayanır. Dijital imza hem verinin değiştirilmediğini hem de imzanın ilgili özel anahtarla üretildiğini doğrulamaya yardımcı olur. Dijital imzanın ayrıntıları sonraki modülde ele alınacaktır; burada yalnızca asimetrik kriptografinin önemli rollerinden biri olduğu bilinmelidir.

Performans ve güvenlik dengesi, hibrit yapının neden gerekli olduğunu açıklar. Asimetrik kriptografi, simetrik şifrelemeye göre daha yavaştır. Bu yüzden asimetrik kriptografi çoğunlukla anahtar kurma, anahtar taşıma veya imza işlemlerinde kullanılır; büyük veri akışı ise simetrik kriptografiyle korunur.

Hibrit şifreleme, asimetrik ve simetrik kriptografinin birlikte kullanıldığı pratik modeldir. Klasik bir hibrit şifreleme senaryosunda gönderen taraf rastgele bir simetrik anahtar üretir, veriyi bu anahtarla şifreler, ardından simetrik anahtarı alıcının açık anahtarıyla korur ve iki çıktıyı birlikte gönderir. Alıcı önce özel anahtarıyla simetrik anahtarı elde eder, ardından veriyi simetrik anahtarla çözer.

Modern TLS’te hibrit fikir benzer ama mekanizma birebir “AES anahtarını RSA ile şifrele” şeklinde değildir. TLS 1.3’te oturum sırları ECDHE tabanlı el sıkışmadan türetilir ve uygulama verisi simetrik AEAD algoritmalarıyla korunur. Bu nedenle “TLS’te her şey RSA ile şifrelenir” ifadesi yanlıştır. TLS’te asimetrik kriptografi kimlik doğrulama ve anahtar kurma sürecinde; simetrik kriptografi ise veri akışının korunmasında görev alır.

Açık anahtarın gerçekten beklenen kişiye ait olduğunu doğrulamak için sertifikalar kullanılır. Sertifika, bir açık anahtarı kimlik bilgisiyle birleştiren imzalı bir belgedir. Bu yapı PKI, yani Public Key Infrastructure konusuna girer ve sonraki modülde ayrıntılı ele alınacaktır.

6.6 Açık Anahtar Araçları ve Anahtar Çifti Yönetimi

Asimetrik kriptografinin araç çıktıları, dosya biçimleri açısından farklı görünebilir. Bir anahtar dosyasını tanımak, formatı okumak ve nelere dikkat edilmesi gerektiğini bilmek pratik güvenlik farkındalığının parçasıdır.

PEM ve DER formatları, anahtar dosyaları ve sertifikalarda sık karşımıza çıkar.

PEM, Base64 kodlanmış içeriğin -----BEGIN ...----- ve -----END ...----- satırları arasında saklandığı metin tabanlı formattır. İnsan tarafından okunabilir bir metin dosyası gibi görünür; terminalde veya metin editöründe açılabilir. Modern PEM özel anahtar dosyaları PKCS#8 formatında -----BEGIN PRIVATE KEY----- veya parola ile korunuyorsa -----BEGIN ENCRYPTED PRIVATE KEY----- biçiminde görünebilir. Geleneksel formatlarda -----BEGIN RSA PRIVATE KEY----- veya -----BEGIN EC PRIVATE KEY----- başlıkları da görülebilir.

Açık anahtar dosyalarında çoğunlukla -----BEGIN PUBLIC KEY----- başlığı görülür. Sertifikalarda ise -----BEGIN CERTIFICATE----- başlığı kullanılır. Bu başlıklar dosyanın ne tür içerik taşıdığını anlamak için ilk bakılacak yerdir.

DER ise ikili formattır. Bir metin editöründe anlamlı biçimde okunamaz. Bazı tarayıcılar, sertifika dosyaları, donanım bileşenleri veya protokol formatları DER kullanabilir. OpenSSL ile PEM ve DER arasında dönüşüm yapılabilir.

OpenSSL’de openssl rsa veya openssl ec gibi algoritmaya özel komutlar görülebilir. Ancak algoritmadan bağımsız anahtar inceleme ve dönüşüm için openssl pkey daha modern ve genel bir seçenektir.

OpenSSL ile Anahtar Dosyalarını İnceleme

Bu bölümde amaç komut ezberlemek değil, araç çıktısındaki kavramları tanımaktır. Eğitim ortamında yalnızca uydurma ve lab amaçlı anahtar dosyaları kullanılmalıdır. Gerçek sistemlerin özel anahtar dosyaları eğitim ortamında açık olarak kullanılmamalıdır.

Örnek bir RSA açık anahtarı PEM formatında şöyle görünebilir:

Bu çıktıda RSA Public-Key: (2048 bit) satırı anahtar türünü ve uzunluğunu gösterir. Exponent: 65537 RSA’da yaygın kullanılan standart kamu üssüdür. BEGIN/END satırları ise PEM formatındaki içeriğin türünü anlamaya yardımcı olur.

RSA-1024 gibi bir anahtar uzunluğu görülürse bu modern güvenlik için yetersiz kabul edilmelidir. RSA-2048 birçok mevcut sistemde asgari kabul edilebilir seviye olarak görülebilir; ancak uzun ömürlü ve yüksek güvenlik hedefli yeni tasarımlarda RSA-3072 veya ECC seçenekleri değerlendirilmelidir.

-----BEGIN RSA PRIVATE KEY-----, -----BEGIN EC PRIVATE KEY-----, -----BEGIN PRIVATE KEY----- veya -----BEGIN ENCRYPTED PRIVATE KEY----- gibi satırlar özel anahtar içerdiğini gösterir. Bu dosyalar paylaşılmamalı, sürüm kontrol sistemine eklenmemeli ve yetkisiz erişime açık bırakılmamalıdır.

PEM içeriği Base64 gibi göründüğü için bazen şifreli metin veya hash zannedilebilir. Bu doğru değildir. PEM içindeki Base64 veri, anahtarın veya sertifikanın kodlanmış hâlidir. Eğer dosya özel anahtarsa, bu içerik doğrudan kritik sır niteliği taşır.

ECC Anahtar Çıktısının Tanınması

ECC anahtarları incelendiğinde eğri adı ve anahtar boyutu özellikle önemlidir. Örnek bir çıktı şu şekilde görünebilir:

Bu çıktıda Private-Key: (256 bit) satırı ECC anahtar boyutunu gösterir. Ancak ECC anahtar boyutu RSA ile doğrudan karşılaştırılmamalıdır. 256 bit ECC anahtarı, yaklaşık olarak 3072 bit RSA ile benzer güvenlik seviyesi sunabilir. Bu fark algoritma ailelerinin farklı matematiksel problemlere dayanmasından kaynaklanır.

NIST CURVE: P-256 veya ASN1 OID: prime256v1 ifadeleri kullanılan eğriyi gösterir. P-256 yaygın ve standart bir eğridir. Tanınmayan, özel veya belgelenmemiş bir eğri adı görülürse bu dikkat gerektiren bir bulgudur. Standart kütüphanelerde bulunmayan eğriler güvenlik analizi gerektirir.

Curve25519/X25519 gibi modern eğriler de araç çıktılarında farklı biçimlerde görünebilir. Burada önemli olan, kullanılan eğrinin tanınmış, standart kütüphanelerde desteklenen ve iyi incelenmiş olmasıdır.

6.7 Özel Anahtarın Korunması

Özel anahtar, asimetrik kriptografi sisteminin en kritik parçasıdır. Bu anahtar ele geçirilirse saldırgan anahtarın kullanım bağlamına göre şifre çözebilir, imza üretebilir, sunucu kimliğine bürünebilir veya gelecekteki bağlantılara aktif saldırı düzenleyebilir.

Özel anahtar dosyaları parola ile korunabilir. Ancak üretim ortamlarında mümkünse secrets manager, KMS, HSM veya platformun güvenli anahtar deposu gibi çözümlerle yönetilmelidir. Gerçek özel anahtarlarla işlem yapılırken güvenli ortam ve erişim kontrolü sağlanmalıdır.

Özel anahtarlar kaynak koda, .env dosyalarına, yapılandırma dosyalarına veya veritabanına düz biçimde yerleştirilmemelidir. Bu dosyalar git gibi sürüm kontrol sistemlerine eklenirse, daha sonra dosya silinse bile geçmişte kalabilir. Depoyu klonlamış herkes geçmiş commit’lerdeki anahtara erişmiş olabilir.

Özel anahtarın güvenli yönetimi için şu ilkeler korunmalıdır:

• Özel anahtar dosyası yetkisiz kişilerle paylaşılmamalıdır.
• Sürüm kontrol sistemlerine eklenmemelidir.
• Dosya sistemi izinleri kısıtlanmalıdır.
• Üretim ortamında secrets manager, KMS veya HSM gibi güvenli saklama çözümleri değerlendirilmelidir.
• Anahtar rotasyonu ve iptal süreci planlanmalıdır.
• Secret scanning, pre-commit hook ve CI/CD kontrolleriyle yanlışlıkla sızıntı önlenmelidir.

Projelerde özel anahtarın .env dosyasına veya kaynak koda eklenmesi, bu kodun bir depoya yüklenmesi durumunda anahtarın yayılması anlamına gelir. Bu hata gerçek sistemlerde ciddi güvenlik ihlallerine yol açabilir.

Komut & Araç Okuryazarlığı

Bu modülde araç okuryazarlığı, anahtar dosyalarını ve kütüphane yaklaşımlarını doğru okumaya odaklanır. Amaç üretime hazır kod yazmak değil; doğru aracı, doğru formatı ve doğru güvenlik sınırını anlamaktır.

Python cryptography Kütüphanesi ile Anahtar Çifti Kavramını Tanımak

Python cryptography kütüphanesi, yaygın kullanılan ve aktif bakımı yapılan kriptografi kütüphanelerinden biridir. Temel eğitim bağlamında önemli olan “nasıl kodlanır?” sorusundan çok, “ne tür API kullanılmalı ve hangi sınırlar bilinmeli?” sorusudur.

Bu kütüphanede bazı bölümler yüksek seviyeli “recipes” katmanı olarak sunulur. Örneğin Fernet gibi yapılar, belirli güvenli varsayımları hazır biçimde sağlar ve yanlış yapılandırma ihtimalini azaltır. Buna karşılık “hazmat” katmanı, düşük seviyeli kriptografik primitives içerir. Bu katmanın adı bilerek “hazardous materials”, yani tehlikeli maddeler olarak seçilmiştir; çünkü yanlış parametre seçimi veya yanlış kullanım ciddi güvenlik hatalarına yol açabilir.

Güvenli bir kütüphane; anahtar üretimi, şifreleme, imza ve doğrulama işlemleri için belgelenmiş ve test edilmiş fonksiyonlar sunar. Ancak kütüphanenin güvenli olması, onu kullanan her kodun otomatik olarak güvenli olduğu anlamına gelmez. Yanlış parametre seçimi, deprecated fonksiyon kullanımı, hatalı anahtar yönetimi veya doğrulama adımlarının atlanması güvenliği bozar.

Kütüphane seçerken iki temel noktaya bakmak gerekir: aktif bakım ve belgeleme kalitesi. Son güvenlik güncellemesinin yıllar önce yapıldığı, deprecated fonksiyonların hâlâ örnek olarak kullanıldığı veya dokümantasyonu zayıf olan kütüphaneler üretim sistemleri için riskli olabilir.

Bu bölümün temel mesajı şudur: kriptografik işlemler için kendi algoritmanızı veya kendi düşük seviye protokolünüzü yazmaya çalışmak yerine, bakımı yapılan ve güvenli varsayımlar sunan kütüphaneler tercih edilmelidir. Ancak güvenli kütüphane seçimi, doğru kullanım sorumluluğunu ortadan kaldırmaz.

Temel Seviye Güvenli Kullanım / Kontrol Listesi

Asimetrik kriptografi bağlamında bir sistem, kod tabanı veya yapılandırma değerlendirilirken önce hangi algoritmanın hangi amaçla kullanıldığı netleştirilmelidir. RSA mı, ECDH mi, ECDSA mı, EdDSA mı kullanılıyor? Kullanım amacı şifreleme mi, anahtar anlaşması mı, dijital imza mı? Bu sorular cevaplanmadan sağlıklı değerlendirme yapılamaz.

RSA kullanılıyorsa anahtar uzunluğu kontrol edilmelidir. RSA-1024 modern güvenlik için yetersizdir. RSA-2048 birçok mevcut sistemde asgari kabul edilebilir seviye olarak görülebilir; uzun ömürlü ve daha yüksek güvenlik hedefli sistemlerde RSA-3072 veya ECC seçenekleri düşünülmelidir.

ECC kullanılıyorsa eğri adı tanınmış ve yaygın bir eğri olmalıdır. P-256, P-384, Curve25519/X25519 gibi seçenekler standart kütüphanelerde yaygın destek görür. Tanınmayan, özel üretilmiş veya belgelenmemiş eğriler güvenlik incelemesi gerektirir.

Özel anahtar dosyalarının dosya sistemi izinleri kısıtlı olmalıdır. Anahtar dosyalarının kaynak koda, yapılandırma depolarına, .env dosyalarına veya loglara yazılıp yazılmadığı kontrol edilmelidir.

PEM dosyasının BEGIN satırı anahtar türü hakkında hızlı bilgi verir. BEGIN PUBLIC KEY açık anahtarı, BEGIN PRIVATE KEY, BEGIN ENCRYPTED PRIVATE KEY, BEGIN RSA PRIVATE KEY veya BEGIN EC PRIVATE KEY özel anahtarı işaret eder. Özel anahtar başlığı görülen dosyalar kritik sır olarak değerlendirilmelidir.

Açık anahtarın öğrenilmesi normaldir; ancak açık anahtarın sahte bir anahtarla değiştirilmesi ciddi risktir. Özel anahtarın ele geçirilmesi ise ilgili kimlik veya sistem için kritik güvenlik ihlalidir.

Geliştirici veya güvenlik ekibine şu şekilde öneri verilebilir:

Sistemde RSA-1024 kullanılmaktadır. Bu anahtar uzunluğu günümüz güvenlik standartlarına göre yetersizdir. Minimum RSA-2048 veya daha uzun ömürlü güvenlik hedefleri için RSA-3072 ya da eşdeğer güvenlik seviyesinde ECC kullanılması önerilir. Ayrıca özel anahtar dosyasının sürüm kontrol sisteminde veya yapılandırma dosyalarında bulunup bulunmadığı kontrol edilmelidir.

Analitik Senaryo

Bir şirketin dahili geliştirme deposu incelenirken proje dizininde aşağıdaki dosyanın olduğu fark ediliyor:

/proje/config/server.key

Dosya içeriğinin başında şu satır yer alıyor:

-----BEGIN RSA PRIVATE KEY-----

MIIEowIBAAKCAQEA...

Yapılandırma dosyasının git geçmişinde de bu dosyanın birkaç commit’te yer aldığı görülüyor.

İlk değerlendirme şu olmalıdır: -----BEGIN RSA PRIVATE KEY----- satırı, bu dosyanın bir RSA özel anahtarı olduğunu açıkça gösterir. Özel anahtarın bir proje deposunda bulunması, özellikle git geçmişinde izleniyor olması, ciddi bir güvenlik sorunudur. Git geçmişinden dosya daha sonra silinmiş olsa bile, geçmiş commit’lerde bu anahtar hâlâ bulunabilir. Depoyu daha önce klonlamış veya geçmişe erişmiş herhangi biri bu dosyayı elde etmiş olabilir.

Bu durumda önce anahtarın ne için kullanıldığı belirlenmelidir. Bu anahtar bir TLS sertifikasıyla mı ilişkili, kod imzalama için mi kullanılıyor, yoksa başka bir sistem kimliğiyle mi bağlantılı? Kullanım bağlamı riskin kapsamını belirler.

OpenSSL ile anahtar uzunluğu incelenebilir; ancak bu işlem gerçek sızmış anahtar üzerinde değil, kontrollü ve yetkili ortamda yapılmalıdır. Çıktıda 2048 bit görülmesi, anahtar uzunluğunun mevcut bazı kullanım bağlamları için kabul edilebilir olduğunu gösterebilir; fakat anahtarın depoya girmiş olması riskini ortadan kaldırmaz. Ele geçirilmiş olma ihtimali olan bir özel anahtar güvenilir kabul edilmemelidir.

Yanlış yorumlardan biri şudur: “Depomuz zaten özeldi, kimse görmemiştir.” Özel depo olması, anahtarın güvende olduğunu garanti etmez. Depoyu klonlamış geliştirici makineleri, CI/CD sistemleri, yedekler veya geçmiş erişimler bu anahtarın yayılmış olabileceği alanlardır.

Bu anahtarı ele geçiren biri, anahtarın kullanım bağlamına göre sunucu kimliğine bürünebilir, sahte imza üretebilir veya gelecekteki bağlantılara aktif saldırı düzenleyebilir. Eski RSA key exchange kullanılan sistemlerde geçmiş trafik de risk altına girebilir. Ancak modern ECDHE/TLS 1.3 gibi forward secrecy sağlayan yapılarda uzun dönem özel anahtarın sonradan ele geçirilmesi, geçmiş trafiğin otomatik olarak çözüleceği anlamına gelmez. Yine de özel anahtar sızıntısı kritik olay olarak ele alınmalıdır.

Önerilen güvenli yaklaşım şudur: etkilenen hizmetler belirlenmeli, yeni bir anahtar çifti oluşturulmalı, eski anahtarla ilişkili sertifikalar iptal edilmeli veya yenilenmeli, bağlı servisler yeni anahtara geçirilmelidir. Git geçmişinden yalnızca dosyayı silmek yeterli değildir; geçmişi yeniden yazmak, depoyu temizlemek, erişmiş olabilecek tarafları değerlendirmek ve secret scanning kontrolleri eklemek gerekir.

Güvenlik ekibine bulgu şu şekilde aktarılabilir:

Proje deposunda RSA özel anahtarı tespit edilmiştir. Özel anahtarın git geçmişinde yer alması, anahtarın gizliliğinin artık garanti edilemeyeceği anlamına gelir. Anahtarın kullanıldığı servisler belirlenmeli, yeni anahtar çifti oluşturulmalı, ilgili sertifikalar yenilenmeli veya iptal edilmeli ve özel anahtarların kaynak kod depolarına eklenmesini engellemek için secret scanning ve pre-commit kontrolleri devreye alınmalıdır.

Kendini Değerlendir — Asimetrik

Terimler Sözlüğü

Bu Modülde Neler Öğrendik?

Bu modül, asimetrik kriptografinin temel kavramsal çerçevesini kurdu.

Açık anahtar ve özel anahtar arasındaki temel fark netleşti. Açık anahtar serbestçe paylaşılabilirken özel anahtar gizli kalmalıdır. Hangi anahtarın hangi işlemde kullanıldığı da bağlama göre değişir: şifrelemede alıcının açık anahtarı, çözmede özel anahtar; imzada özel anahtar, doğrulamada açık anahtar; DH/ECDH’de ise anahtarlar ortak sır üretimi için kullanılır.

RSA’nın büyük sayıların çarpanlara ayrılması problemiyle ilişkili olduğu ve büyük veri şifrelemek için uygun olmadığı öğrenildi. RSA’nın modern kullanımında OAEP ve PSS gibi güvenli şemaların önemi anlaşıldı. “RSA her şeyi şifreler” yanılgısı giderildi.

Diffie-Hellman’ın önceden sır paylaşmaya gerek kalmadan ortak bir değer üretme mantığı kavrandı. Bu protokolün şifreleme değil anahtar anlaşması olduğu ve kimlik doğrulama olmadan MITM saldırılarına açık kalabileceği anlaşıldı.

ECC’nin neden tercih edildiği — küçük anahtar boyutlarıyla yüksek güvenlik seviyesi — ve ECC ile RSA anahtar boyutlarının doğrudan karşılaştırılamayacağı görüldü. Tanınan eğrilerin, örneğin Curve25519/X25519 ve P-256’nın kullanılması gerektiği; özel eğri tasarımından kaçınılması gerektiği yerleşti.

Asimetrik kriptografinin pratik rolleri olan şifreleme, anahtar taşıma/anlaşma ve dijital imza birbirinden ayrıldı. Hibrit şifrelemenin, asimetrik kriptografi ile simetrik kriptografiyi nasıl birlikte kullandığı kavrandı. Modern TLS’te asimetrik kriptografinin çoğunlukla kimlik doğrulama ve anahtar kurma tarafında; simetrik kriptografinin ise veri akışını koruma tarafında görev aldığı anlaşıldı.

PEM ve DER formatları, -----BEGIN RSA PRIVATE KEY-----, -----BEGIN PRIVATE KEY-----, -----BEGIN ENCRYPTED PRIVATE KEY----- ve -----BEGIN PUBLIC KEY----- gibi başlık satırlarından dosya türünü okumak ve anahtar türü ile uzunluğunu araç çıktısında yorumlamak becerisi gelişti.

Özel anahtarın kaynak kod depolarına eklenmesi, e-postayla paylaşılması veya güvenli saklanmaması gibi hataların somut riskleri anlaşıldı. Bu bilgi, bir güvenlik denetiminde özel anahtara dair bulguyu güvenlik ekibine sade ve doğru biçimde aktarmak için yeterli zemin sağlar.

TLS ise bu yapıların gerçek internet trafiğinde nasıl birlikte çalıştığını gösteren en yaygın örneklerden biridir. Tarayıcı adres çubuğundaki kilit simgesi; sertifika doğrulama, dijital imza, anahtar anlaşması, simetrik AEAD şifreleme ve bütünlük doğrulaması gibi birçok kriptografik işlemin görünür yüzüdür. TLS 1.3, eski statik RSA anahtar değişimi gibi seçenekleri kaldırmış ve tüm public-key tabanlı anahtar değişim mekanizmalarının forward secrecy sağlamasını hedefleyen modern bir yapı kullanmıştır.

Bu modülü tamamlayan öğrenci, bir web sunucusunun sertifikasını açıp temel alanlarını okuyabilir, dijital imzanın şifrelemeden farkını açıklayabilir, PKI güven zincirini yorumlayabilir ve TLS el sıkışmasının üst düzey mantığını kavramsal olarak ifade edebilir hâle gelir.

Süresi dolmuş sertifika, zayıf imza algoritması, SAN uyuşmazlığı, güvenilmez sertifika zinciri veya eski TLS sürümü gibi bulgulara karşı güvenlik ekibine sade ve doğru bir öneri yazabilir.

7.1 Dijital İmza Mantığı

Dijital imza, bir verinin belirli bir özel anahtarla imzalandığını ve imzalanan verinin sonradan değiştirilmediğini doğrulamaya yarayan kriptografik mekanizmadır. Kâğıt üzerindeki el yazısı imzadan farklı olarak dijital imza, matematiksel doğrulama sürecine dayanır. Ancak bu doğrulamanın anlamlı olabilmesi için imzada kullanılan açık anahtarın gerçekten beklenen kişiye veya kuruma ait olduğunun da doğrulanması gerekir.

İmzalama sürecinde imzalamak isteyen taraf önce veriyi — belge, mesaj, yazılım paketi veya sertifika — imza şemasının tanımladığı biçimde işler. Çoğu imza şemasında büyük veri doğrudan işlenmez; veri önce hashlenir veya algoritmanın tanımladığı mesaj temsili üzerinden ele alınır. Ardından özel anahtar kullanılarak dijital imza değeri üretilir. İmza ve asıl veri birlikte alıcıya iletilebilir veya imza ayrı bir dosya olarak gönderilebilir.

Doğrulama sürecinde alıcı; imzayı, imzalayan tarafa ait açık anahtarı, mesajın hash değerini veya imza algoritmasının kullandığı mesaj temsilini ve ilgili doğrulama algoritmasını kullanarak imzanın geçerli olup olmadığını kontrol eder. Doğrulama başarılıysa veri, ilgili imza bağlamında değiştirilmemiş kabul edilir ve imzanın ilgili özel anahtarla üretildiği anlaşılır. Doğrulama başarısızsa veri değiştirilmiş, imza bozulmuş, yanlış açık anahtar kullanılmış veya imza sahte olabilir. FIPS 186-5; RSA, ECDSA ve EdDSA gibi dijital imza tekniklerini ayrı ayrı ele alır, bu yüzden doğrulama işlemi tüm algoritmalarda “imzayı açık anahtarla çözüp hash’i elde etmek” şeklinde düşünülmemelidir.

Burada en önemli ayrımlardan biri şudur: imzalama özel anahtarla yapılır, doğrulama açık anahtarla yapılır. Asimetrik şifrelemede ise klasik anlatımda şifreleme alıcının açık anahtarıyla, çözme alıcının özel anahtarıyla yapılır. Bu iki işlemin yönü ve amacı farklıdır. İmza gizlilik sağlamaz; imzalanmış bir belge herkes tarafından okunabilir. İmza, verinin değiştirilmediğini ve ilgili özel anahtarla ilişkilendirilebildiğini doğrulamaya yarar.

Hash ve imza ilişkisi bu noktada önemlidir. Büyük bir dosyanın doğrudan asimetrik kriptografiyle işlenmesi hem verimsiz hem de çoğu imza şeması açısından uygun değildir. Bu nedenle veri önce uygun bir temsil hâline getirilir; çoğu durumda bu temsil kriptografik hash fonksiyonuyla elde edilen özettir. Dosyada tek bir bit değişirse hash çıktısı değişir ve imza doğrulaması başarısız olur. Bu nedenle dijital imza bütünlük hedefine güçlü biçimde katkı sağlar.

Dijital imza aynı zamanda inkâr edememe hedefine de katkı sağlar; fakat bu özellik mutlak ve bağlamdan bağımsız değildir. Özel anahtar gerçekten yalnızca sahibinin kontrolündeyse, güvenli biçimde korunmuşsa, sertifika geçerliyse, imza zamanı doğru biçimde kayıt altına alınmışsa ve ilgili hukuki/operasyonel süreçler bunu destekliyorsa imzanın sahibi sonradan “ben imzalamadım” iddiasında bulunmakta zorlanır. Ancak özel anahtar çalınmış, paylaşılmış veya kötü yönetilmişse imzanın kime atfedileceği ayrıca incelenmelidir.

Bu nedenle dijital imza şu şekilde düşünülmelidir: doğru algoritma, doğru anahtar yönetimi ve güvenilir açık anahtar doğrulamasıyla birlikte kullanıldığında, verinin değişmediğini ve imzanın ilgili özel anahtarla üretildiğini kriptografik olarak doğrulamaya yarar. Gizlilik gerekiyorsa imzaya ek olarak şifreleme de kullanılmalıdır. Bir belge hem şifrelenebilir hem imzalanabilir; fakat bu iki işlem farklı güvenlik hedeflerine hizmet eder.

7.2 Dijital İmza Algoritmaları

Dijital imza üretmek için birden fazla algoritma mevcuttur. Hangi algoritmanın seçileceği; güvenlik seviyesi, performans, uyumluluk, standart gereksinimleri ve kullanım bağlamına bağlıdır.

RSA tabanlı imzalar, RSA’nın matematiksel yapısını imza üretimi için kullanır. RSA uzun yıllardır yaygın desteklenir ve birçok eski sistemde RSA ile imzalanmış sertifikalar hâlâ bulunur. Modern kullanımda RSA için güvenli imza şeması olarak RSA-PSS tercih edilmelidir. RSA anahtar uzunluğu güncel sistemlerde en az 2048 bit seviyesinde değerlendirilir; daha kısa anahtarlar modern güvenlik için uygun değildir. Bununla birlikte RSA-PSS hâlâ standart ve yaygın desteklenen bir imza seçeneğidir. Uyumluluk ihtiyacı yüksek olan sistemlerde RSA kullanımı devam edebilir. FIPS 186-5, RSA dijital imza algoritmasını onaylı imza teknikleri arasında ele alır.

ECDSA, yani Elliptic Curve Digital Signature Algorithm, eliptik eğri kriptografisi üzerine inşa edilmiş dijital imza algoritmasıdır. RSA’ya kıyasla daha küçük anahtar boyutlarıyla benzer güvenlik seviyeleri sağlayabilir. Bu nedenle TLS sertifikalarında, mobil uygulamalarda ve performansın önemli olduğu ortamlarda yaygın biçimde kullanılır. P-256 ve P-384 gibi standart, yaygın ve iyi incelenmiş eğrilerle kullanılması önemlidir.

EdDSA, yani Edwards-curve Digital Signature Algorithm, Ed25519 ve Ed448 gibi varyantlarla modern sistemlerde yer bulan bir imza ailesidir. Ed25519 özellikle SSH ve modern kripto kütüphanelerinde yaygınlaşmıştır. TLS 1.3 tarafında EdDSA desteği mümkündür; ancak web PKI ve tarayıcı ekosistemindeki kullanım bağlama, sertifika otoritesi desteğine ve uyumluluk gereksinimlerine göre değişebilir. EdDSA’nın yalın tasarımı ve güvenli varsayımlar sunması, onu yeni sistemler için önemli bir seçenek hâline getirir.

DSA, yani Digital Signature Algorithm, tarihsel olarak ABD federal standartlarında yer almış bir imza algoritmasıdır. Ancak yeni dijital imza üretimi için artık tercih edilmemelidir. FIPS 186-5’te DSA, dijital imza üretimi için artık onaylı değildir; yalnızca daha önce üretilmiş imzaların doğrulanması gibi legacy bağlamlarda karşımıza çıkabilir.

İmza algoritması seçerken yalnızca algoritma adı değil, kullanılan parametreler de önemlidir. ECDSA seçilmiş olsa bile zayıf veya yanlış eğri kullanımı risk oluşturabilir. RSA kullanılıyorsa anahtar uzunluğu ve padding/şema seçimi önemlidir. EdDSA kullanılıyorsa desteklenen protokol ve kütüphane uyumluluğu değerlendirilmelidir.

Burada korunması gereken temel ayrım şudur: imzalama, şifreleme değildir. İmzalanmış belge okunabilir. İmza yalnızca belgenin değiştirilmediğini ve ilgili özel anahtar tarafından imzalandığını doğrulamaya yardım eder. Gizlilik gerekiyorsa şifreleme ayrıca uygulanmalıdır.

7.3 PKI Temelleri

Dijital imzalar güçlü bir doğrulama mekanizması sunar; ancak tek başına şu kritik soruyu çözmez: “Bu açık anahtar gerçekten beklediğim kişiye veya sunucuya mı ait?” Bir saldırgan kendi açık anahtarını beklenen sunucunun açık anahtarı gibi gösterebilirse, matematiksel olarak geçerli görünen ama yanlış kimliğe ait bir doğrulama yapılmış olur. PKI bu problemi çözmek için kullanılan güven altyapısıdır.

PKI, yani Public Key Infrastructure, açık anahtarların belirli kimliklerle güvenilir ve doğrulanabilir biçimde ilişkilendirilmesini sağlayan kural, kurum, yazılım, sertifika ve doğrulama süreçlerinin bütünüdür. Teknik bileşenleri arasında X.509 sertifikaları, sertifika otoriteleri, sertifika zincirleri, trust anchor yapısı ve sertifika iptal mekanizmaları bulunur.

Sertifika Otoritesi, yani CA, açık anahtar ile kimlik arasındaki ilişkiyi imzalayarak doğrulayan kurumdur. Web PKI’de CA, sertifika türüne göre alan adı kontrolünü veya ek kuruluş bilgilerini doğrular. Domain Validation sertifikalarında temel güvence, ilgili alan adı üzerinde kontrol sahibi olunduğudur; bu, sitenin içeriğinin güvenilir olduğu veya site sahibinin iyi niyetli olduğu anlamına gelmez. Bu ayrım, tarayıcıdaki kilit simgesini doğru yorumlamak için kritiktir.

X.509 sertifikası, açık anahtarı, kimlik bilgisini, geçerlilik tarihlerini, alan adı bilgilerini ve sertifikayı imzalayan CA’nın imzasını içeren standart bir belgedir. X.509 sertifikaları RFC 5280’de tanımlanan PKIX profili ve sertifika yolu doğrulama mantığı içinde değerlendirilir.

Bir X.509 sertifikasında genellikle şu alanlar bulunur: sertifika sahibinin kimliği, sahibin açık anahtarı, sertifikanın geçerli olduğu alan adları, başlangıç ve bitiş tarihleri, sertifikayı imzalayan CA, imza algoritması, key usage ve basic constraints gibi uzantılar. Modern TLS doğrulamada bağlanılan alan adı, sertifikanın SAN alanındaki DNS veya IP girdileriyle eşleşmelidir. CN alanı tarihsel olarak kullanılmıştır; ancak yeni sertifikalarda SAN temel kontrol noktasıdır. RFC 6125, TLS bağlamında servis kimliğinin nasıl temsil edilip doğrulanacağını açıklar.

Sertifika zinciri, bir sertifikanın güvenilir bir köke kadar izlenebilmesini sağlar. En üstte root CA bulunur. Root CA’nın altında intermediate CA’lar yer alır. En altta ise son kullanıcı sertifikası, yani leaf certificate bulunur. Tarayıcı veya istemci, sunucudan gelen sertifikayı doğrularken bu zinciri takip eder.

Trust anchor, tarayıcının veya işletim sisteminin önceden güvendiği root CA sertifikalarını ifade eder. Bir sertifika zincirinin güvenilir bir trust anchor’a bağlanması gerekir; ancak bu tek başına yeterli değildir. Geçerlilik tarihleri, imzalar, sertifika uzantıları, alan adı eşleşmesi, key usage, basic constraints ve gerektiğinde iptal durumu da kontrol edilmelidir. RFC 5280, sertifika yolu doğrulama mantığını bu tür kontrollerle birlikte ele alır.

Mini örnek olarak example.com adresine bağlandığınızı düşünelim. Sunucu size kendi leaf sertifikasını gönderir. Bu sertifikanın issuer alanı bir intermediate CA’yı gösterir. Intermediate CA’nın sertifikası da bir root CA’ya bağlanır. Tarayıcı bu zinciri takip eder, imzaları doğrular, alan adının SAN içinde yer alıp almadığını kontrol eder ve zincirin güvenilen bir trust anchor’a ulaşıp ulaşmadığını değerlendirir.

Sertifika iptali de PKI’nin önemli parçasıdır. Bir özel anahtar ele geçirilirse, sertifika hatalı verilirse veya sertifika artık güvenilir olmamalıysa iptal edilmesi gerekir. Bunun için CRL, yani Certificate Revocation List, ve OCSP, yani Online Certificate Status Protocol gibi mekanizmalar kullanılır. İptal kontrolünün nasıl yapıldığı istemciye, tarayıcıya, uygulama politikasına ve yapılandırmaya göre değişebilir. Bu nedenle iptal mekanizmasının varlığı, her istemcide aynı davranışın garanti edildiği anlamına gelmez.

Sertifika ile açık anahtar arasındaki ilişki şöyle özetlenebilir: açık anahtar tek başına yalnızca matematiksel bir değerdir. Kime ait olduğu bilinmeden güvenilir değildir. Sertifika, bu açık anahtarı bir kimlik veya alan adıyla ilişkilendirir ve bu ilişkiyi bir CA imzasıyla doğrulanabilir hâle getirir. PKI olmadan asimetrik kriptografinin gerçek dünyadaki kimlik doğrulama problemi eksik kalır.

7.4 TLS ve Güvenli Kanal Mantığı

TLS, yani Transport Layer Security, ağ üzerindeki iletişimi güvenli kılmak için kullanılan protokoldür. HTTPS, TLS üzerinde çalışır. E-posta sunucuları, API servisleri, VPN çözümleri ve pek çok uygulama protokolü de TLS’i kullanır. TLS; simetrik AEAD şifreleme, anahtar anlaşması, dijital imza, hash ve KDF mekanizmalarını bir araya getiren güvenli kanal protokolüdür.

TLS’in üç temel hedefi vardır. Birincisi gizliliktir; iletişim içeriğinin üçüncü taraflarca okunmasını engeller. İkincisi bütünlüktür; verinin iletim sırasında değiştirilmesini tespit etmeye yarar. Üçüncüsü kimlik doğrulamadır; en yaygın kullanımda sunucunun, bazı senaryolarda ise istemcinin kimliği doğrulanır. Karşılıklı TLS, yani mTLS senaryolarında istemci de sertifika sunar ve sunucu istemci kimliğini doğrular.

TLS el sıkışması, güvenli kanal kurulmadan önce tarafların yaptığı protokol müzakeresidir. TLS 1.2 ve TLS 1.3’te mesaj adları ve akış detayları farklıdır; bu nedenle temel eğitimde bunu üst düzey mantıkla düşünmek daha doğrudur. Genel olarak istemci desteklediği sürüm ve parametreleri sunar, sunucu seçimlerini ve sertifikasını gönderir, istemci sertifikayı doğrular, ECDHE gibi bir anahtar anlaşmasıyla ortak sır üretilir ve uygulama verisi simetrik AEAD anahtarlarıyla korunur.

TLS 1.3, TLS 1.2’ye kıyasla daha sade ve güvenli bir yapı hedefler. Statik RSA ve statik Diffie-Hellman cipher suite’leri kaldırılmıştır; public-key tabanlı anahtar değişim mekanizmaları forward secrecy sağlayacak şekilde tasarlanmıştır. Ayrıca TLS 1.3’te eski ve zayıf algoritmalar büyük ölçüde elenmiştir.

Sertifika doğrulama sırasında istemci birkaç temel kontrol yapar. Sertifika zinciri güvenilir bir CA’ya bağlanıyor mu? Sertifikanın geçerlilik tarihleri aktif mi? Sertifikanın SAN alanı bağlanılan alan adını kapsıyor mu? Sertifika uygun key usage ve extended key usage değerlerine sahip mi? İmza algoritması ve anahtar uzunluğu güncel güvenlik beklentilerine uygun mu? Bu kontrollerden biri başarısız olursa tarayıcı uyarı gösterebilir veya bağlantıyı reddedebilir.

Oturum anahtarları el sıkışma sürecindeki ortak sırdan türetilir. Bu anahtarlar daha sonra AES-GCM veya ChaCha20-Poly1305 gibi simetrik AEAD algoritmalarıyla uygulama verisini korumak için kullanılır. Bu nedenle TLS’te asimetrik kriptografi çoğunlukla anahtar anlaşması ve kimlik doğrulama aşamasında; simetrik kriptografi ise asıl veri aktarımı sırasında devrededir.

TLS 1.2 hâlâ birçok sistemde kullanılabilir; ancak TLS 1.3 modern sistemlerde güçlü tercih hâline gelmiştir. TLS 1.3, eski RSA key exchange gibi forward secrecy sağlamayan seçenekleri kaldırır ve ephemeral DH/ECDHE tabanlı anahtar anlaşmasını kullanır. Bu nedenle uzun dönem özel anahtar sonradan ele geçirilse bile geçmiş oturumların otomatik olarak çözülmemesi hedeflenir. Cloudflare’in TLS 1.3 değerlendirmesinde de RSA encryption’ın TLS 1.3’ten kaldırıldığı ve ephemeral Diffie-Hellman’ın anahtar değişimi tarafında temel hâle geldiği vurgulanır.

SSL, yani Secure Sockets Layer, TLS’in tarihsel öncülüdür. SSL 2.0 ve SSL 3.0 uzun süredir güvenli kabul edilmez. Sektörde “SSL sertifikası” ifadesi hâlâ yaygın kullanılsa da teknik olarak güncel web bağlantılarında kullanılan protokol TLS’tir. Bu nedenle teknik anlatımda “TLS sertifikası” veya “TLS bağlantısı” demek daha doğrudur.

Tarayıcıdaki kilit simgesi, bağlantının TLS ile kurulduğunu ve sunucu sertifikasının tarayıcı tarafından doğrulandığını gösterir. Ancak kilit simgesi sitenin içeriğinin yasal, zararsız veya güvenilir olduğunu garanti etmez. Kimlik avı siteleri de geçerli TLS sertifikası alabilir. Kilit simgesi yalnızca iletişim kanalının şifreli olduğunu ve bağlanılan alan adı için geçerli bir sertifika doğrulaması yapıldığını gösterir. Kullanıcı, sitenin amacı ve içeriği konusunda ayrıca dikkatli olmalıdır.

7.5 Dijital İmza, Sertifika ve TLS Araçları

Bu modülün araç okuryazarlığı bölümü, dijital imza, sertifika ve TLS kavramlarının gerçek araç çıktılarında nasıl göründüğünü anlamaya odaklanır. Amaç komut ezberlemek değil; hangi çıktının ne anlama geldiğini okuyabilmektir.

GnuPG ile Dosya İmzalama ve Doğrulama Mantığı

GnuPG, OpenPGP standardı çerçevesinde dosya imzalama, imza doğrulama ve açık/özel anahtar yönetimi için kullanılan bir araçtır. E-posta güvenliği, yazılım dağıtımı ve belge doğrulama bağlamlarında sıkça kullanılır.

Eğitim ortamında GnuPG ile yalnızca uydurma anahtar çifti ve lab dosyaları kullanılmalıdır. Gerçek kullanıcıların özel anahtarlarıyla deneme yapılmamalıdır.

Temsili bir gpg --verify çıktısı şu şekilde görünebilir:

Bu çıktıda Good signature ifadesi, verilen dosya ve imza eşleşmesi için imzanın matematiksel olarak geçerli olduğunu ve dosyanın bu imzaya göre değişmediğini gösterir. Ancak bu, imzalayan anahtarın gerçekten beklenen kişiye ait olduğunu tek başına kanıtlamaz. This key is not certified with a trusted signature uyarısı, anahtarın güvenilir bir kimlik bağlamında doğrulanmadığını ifade eder.

GnuPG’de güven, klasik web PKI modelinden farklı olarak web of trust yaklaşımıyla ilişkilidir. Anahtarın kime ait olduğu güvenilir biçimde doğrulanmamışsa, imza matematiksel olarak geçerli olsa bile kimlik garantisi eksik kalır. Bu ayrım, PKI ile OpenPGP güven modelinin farkını anlamak için önemlidir.

OpenSSL ile Sertifika İçeriğinin Okunması

Bir X.509 sertifikası çoğunlukla PEM formatında metin dosyası olarak görülebilir. OpenSSL bu sertifikayı ayrıştırıp alanlarını okunabilir hâle getirir. Örneğin openssl x509 -text -noout -in sertifika.pem komutu, sertifika içeriğini insan tarafından okunabilir biçimde gösterir.

Üretim sertifikaları yönetimli tutulmalı; özellikle sertifikaya karşılık gelen özel anahtar sıkı erişim kontrolüyle korunmalıdır. Sertifika dosyası genellikle public bilgi içerse de, ona ait özel anahtar kritik sırdır.

Temsili OpenSSL çıktısı şu şekilde olabilir:

Bu çıktıda Signature Algorithm alanı sertifikanın hangi imza algoritmasıyla imzalandığını gösterir. sha256WithRSAEncryption veya ecdsa-with-SHA256 gibi modern algoritmalar beklenebilir. md5WithRSAEncryption veya SHA-1 tabanlı imza algoritmaları modern güvenlik bağlamında sorunlu kabul edilmelidir.

Not Before ve Not After alanları sertifikanın geçerlilik tarihlerini gösterir. Süresi dolmuş sertifika, tarayıcı ve istemciler tarafından güvenilir kabul edilmez.

Issuer, sertifikayı imzalayan CA’yı gösterir. Bu CA’nın güvenilir zincirde yer alması gerekir.

Subject ve özellikle Subject Alternative Name alanları, sertifikanın hangi alan adları için geçerli olduğunu gösterir. Modern TLS doğrulamada bağlanılan alan adının SAN içindeki DNS/IP girdileriyle eşleşmesi beklenir. CN alanı tek başına yeterli bir modern doğrulama noktası olarak düşünülmemelidir.

Public Key Algorithm ve Public-Key satırları, sertifikada yer alan açık anahtarın türünü ve boyutunu gösterir. EC public key ve 256 bit anahtar P-256 gibi bir eğriye işaret edebilir. RSA 1024 bit gibi eski anahtarlar görülürse bu güvenlik bulgusu olarak ele alınmalıdır.

Basic Constraints: CA:FALSE, sertifikanın CA olarak başka sertifika imzalamak için kullanılmaması gerektiğini gösterir ve leaf sertifikalarda beklenir. CA sertifikalarında CA:TRUE ve uygun key usage değerleri aranır. X.509 sertifikalarında basic constraints, key usage ve sertifika yolu doğrulama mantığı RFC 5280 içinde ele alınır.

Tarayıcı Üzerinden Sertifika Zinciri İnceleme

Modern tarayıcılar, TLS bağlantısının sertifika ayrıntılarını görsel olarak gösterir. Adres çubuğundaki kilit veya site bilgisi bölümünden sertifika ayrıntılarına ulaşılabilir. Burada issuer, geçerlilik tarihleri, SAN alanları ve sertifika zinciri görülebilir.

Bu yöntem, OpenSSL çıktısının grafik arayüzdeki karşılığı olarak düşünülebilir. Öğrenci gerçek bir web sitesinin sertifikasını açarak X.509 alanlarını tanıyabilir ve sertifika zincirini gözlemleyebilir. Ancak gerçek sistemlerde sertifika alanlarını yorumlarken yalnızca “sertifika var” sonucuna varılmamalı; alan adı eşleşmesi, geçerlilik, issuer ve zincir güvenilirliği birlikte değerlendirilmelidir.

Wireshark ile TLS El Sıkışmasının Kavramsal Olarak İncelenmesi

Wireshark, ağ trafiğini yakalamak ve analiz etmek için kullanılan bir araçtır. TLS trafiğinin nasıl göründüğünü kavramak için eğitim bağlamında değerlidir. Ancak yalnızca kendi lab makinenizde, kendi ağınızda veya açıkça yetki verilen test ortamlarında kullanılmalıdır. Başkasının trafiğini izinsiz yakalamak hukuki ve etik ihlaldir.

TLS trafiğinde şu tür paketler görülebilir:

TLS 1.2 ve TLS 1.3’te mesaj adları ve akış farklılık gösterebilir. TLS 1.2’de ClientKeyExchange ve ChangeCipherSpec gibi mesajlar görülebilirken, TLS 1.3’te key share ve daha sade bir handshake yapısı bulunur. Bu nedenle Wireshark çıktısı yorumlanırken kullanılan TLS sürümü mutlaka dikkate alınmalıdır.

Wireshark’ta TLSv1.3 veya TLSv1.2 ifadesi hangi sürümün kullanıldığını gösterir. Certificate mesajı sertifikanın iletildiğini gösterir. Encrypted Application Data paketleri ise uygulama verisinin artık şifreli taşındığını ifade eder.

Wireshark TLS el sıkışmasını gözlemleyebilir; ancak şifreli uygulama verisini kendiliğinden çözemez. Modern ECDHE/TLS 1.3 bağlantılarında sunucunun uzun dönem özel anahtarı tek başına geçmiş trafiği çözmek için yeterli değildir. Analiz için oturum anahtarları veya istemci tarafı key log gibi özel bilgiler gerekir. TLS 1.3’ün statik RSA key exchange’i kaldırması bu ayrımı daha da önemli hâle getirir.

SSL Labs, SSLyze ve testssl.sh

SSL Labs, SSLyze ve testssl.sh gibi araçlar, bir sunucunun TLS yapılandırmasını değerlendirmek için kullanılır. SSL Labs tarayıcı tabanlı bir hizmettir; TLS versiyonlarını, sertifika zincirini, desteklenen şifre paketlerini ve bilinen yapılandırma sorunlarını analiz eder. SSLyze ve testssl.sh ise komut satırından çalışan benzer amaçlı araçlardır.

Bu araçlar saldırı aracı olarak değil, yapılandırma değerlendirme aracı olarak düşünülmelidir. Öncelikle kendi yönettiğiniz veya açıkça izin verilen sistemlerde kullanılmalıdır. Kamuya açık bir sunucunun TLS sertifika bilgisi normal bağlantı sırasında görülebilir; ancak kapsam dışı, yoğun veya agresif taramalar etik ve hukuki risk doğurabilir.

Bir sunucunun “A+” veya “F” gibi bir not alması hızlı fikir verir; fakat tek başına nihai güvenlik değerlendirmesi değildir. Puanın arkasındaki bulgular, desteklenen protokoller, cipher suite’ler, sertifika zinciri ve güvenlik başlıkları ayrıca incelenmelidir.

Komut & Araç Okuryazarlığı

Bu modülde araç okuryazarlığı, bölüm 7.5 içinde bütünleşik biçimde verilmiştir. Ek olarak sertifika alanları aşağıdaki özet tabloyla okunabilir:

Temel Seviye Güvenli Kullanım / Kontrol Listesi

Dijital imza, sertifika ve TLS bağlamında bir sistem, yapılandırma veya bağlantı değerlendirilirken önce neyin doğrulanacağı netleştirilmelidir. Sertifika geçerliliği mi, TLS sürümü mü, imza algoritması mı, alan adı eşleşmesi mi, yoksa güven zinciri mi kontrol ediliyor? Bu soru, hangi aracın ve hangi çıktının inceleneceğini belirler.

Sertifika incelenirken geçerlilik tarihleri kontrol edilmelidir. Not After tarihi geçmiş bir sertifika bağlantı hatalarına neden olur ve güvenilir kabul edilmez.

Issuer alanı güvenilen CA zincirine bağlanmalıdır. Zincir root CA’ya kadar doğrulanamıyorsa sertifika güvenilir kabul edilmez.

SAN alanı bağlanılan alan adını kapsamalıdır. Modern TLS doğrulamada SAN alanı temel alınır. CN alanına dayanmak güncel değerlendirme için yeterli görülmemelidir.

İmza algoritması kontrol edilmelidir. SHA-1 veya MD5 gibi zayıf algoritmalar yeni sertifikalarda kullanılmamalıdır. SHA-256 veya daha güçlü modern algoritmalar beklenir.

TLS sürümü kontrol edilmelidir. TLS 1.2 veya TLS 1.3 modern sistemlerde kabul edilebilir; SSLv3, TLS 1.0 veya TLS 1.1 gibi eski sürümler devre dışı bırakılmalıdır.

Forward secrecy sağlayan anahtar anlaşması kullanılıp kullanılmadığı kontrol edilmelidir. TLS 1.3 bu açıdan daha sade ve güçlü varsayımlar sunar; TLS 1.2’de ise kullanılan cipher suite’e dikkat edilmelidir.

Tarayıcı üzerinden sertifika zinciri incelenebilir. OpenSSL ile sertifika dosyası ayrıştırılabilir. Yetkili sistemlerde SSL Labs, SSLyze veya testssl.sh ile TLS yapılandırması değerlendirilebilir.

Good signature sonucu, imzanın matematiksel olarak geçerli olduğunu gösterir; imzalayan kişinin gerçekten beklenen kişi olduğunun ayrıca doğrulanması gerekir.

Kilit simgesi sitenin güvenilirliğini değil, bağlantının TLS ile kurulduğunu ve sertifika doğrulamasının başarılı olduğunu gösterir.

Geliştirici veya güvenlik ekibine şu şekilde öneri verilebilir:

Sunucunun TLS sertifikası 30 gün içinde sona ermektedir. Bağlantı hataları yaşanmadan önce sertifika yenilenmelidir. Ayrıca sertifika zinciri, SAN alanı ve imza algoritması kontrol edilmelidir. Eğer SHA-1 tabanlı imza veya eski TLS sürümü kullanılıyorsa SHA-256 ve üzeri modern imza algoritmalarına, TLS 1.2/1.3 yapılandırmasına ve mümkünse TLS 1.3’e geçiş önerilir.

Analitik Senaryo

Bir kurumun dahili test ortamındaki web sunucusu olan TEST-APP01 üzerinde çalışan uygulamaya HTTPS bağlantısı yapılırken tarayıcı “bağlantınız güvenli değil” uyarısı veriyor. Uyarıda sertifikanın güvenilir olmadığı belirtiliyor. Güvenlik ekibi durumu incelemek için OpenSSL ile sertifika alanlarını gözden geçiriyor.

İlk değerlendirme şu olmalıdır: Tarayıcı uyarısı genellikle birkaç temel nedenden kaynaklanır. Sertifikanın süresi dolmuş olabilir, sertifika bağlanılan alan adı için geçerli olmayabilir, sertifikayı imzalayan CA güvenilir listede olmayabilir veya sertifikada modern istemcilerin beklediği SAN alanı bulunmayabilir. Lab ortamında self-signed sertifikalar bu uyarının sık görülen nedenlerindendir.

Kendini Değerlendir — PKI ve TLS

OpenSSL çıktısında şu temsili alanlar görülüyor:

Bu çıktıda birden fazla sorun vardır. Birincisi, sertifikanın süresi dolmuştur; Not After tarihi geçmiştedir. İkincisi, imza algoritması SHA-1 kullanmaktadır; SHA-1 modern sertifika ve imza bağlamında güvenli kabul edilmez. Üçüncüsü, sertifika self-signed görünmektedir; issuer alanı güvenilir bir CA zincirine işaret etmemektedir. Dördüncüsü, SAN alanı yoktur. Modern TLS doğrulamada bağlanılan alan adının SAN alanında yer alması beklenir.

Bu bulgular test ortamında açıklanabilir olabilir; ancak üretim ortamında kabul edilmemelidir. Üretim ortamında güvenilen bir CA tarafından imzalanmış, geçerlilik tarihi aktif, SHA-256 veya daha güçlü bir imza algoritması kullanan, SAN alanı doğru yapılandırılmış ve uygun key usage değerlerine sahip bir sertifika kullanılmalıdır.

Self-signed sertifikalar konusunda önemli ayrım şudur: self-signed sertifika da bağlantıyı şifreleyebilir; ancak güvenilir bir CA zincirine bağlanmadığı için sunucunun kimliğini tarayıcı açısından güvenilir biçimde doğrulamaz. Tarayıcı güvenilmeyen self-signed sertifikaya uyarı verir. Kullanıcı bu uyarıyı geçerse veya saldırganın sertifikası yanlışlıkla güvenilir depoya eklenmişse MITM riski ortaya çıkar.

Riskin pratik karşılığı büyüktür. Süresi dolmuş ve SHA-1 kullanan bir sertifika, modern tarayıcılar ve istemciler tarafından reddedilebilir. SAN alanı eksikse alan adı doğrulaması başarısız olabilir. Self-signed yapı ise güvenilir kimlik doğrulaması sağlamaz. Bu durum hem kullanıcı deneyimini bozar hem de güvenli iletişim beklentisini zayıflatır.

Test ortamı için daha güvenli yaklaşım, test amaçlı bir iç CA oluşturmak ve bu CA’yı yalnızca test makinelerinde güvenilir olarak tanımlamaktır. İç CA kullanılıyorsa bu CA’nın özel anahtarı da üretim anahtarı gibi korunmalı ve yalnızca test ortamı kapsamıyla sınırlandırılmalıdır. Üretim ortamına geçişte ise güvenilir bir CA’dan alınan, SAN alanı doğru yapılandırılmış, SHA-256 veya daha güçlü algoritmayla imzalanmış ve otomatik yenileme mekanizması olan sertifika kullanılmalıdır.

Güvenlik ekibine bulgu şu şekilde aktarılabilir:

TEST-APP01 üzerinde kullanılan TLS sertifikasında birden fazla sorun tespit edilmiştir: sertifika süresi dolmuş, SHA-1 imza algoritması kullanılmış, SAN alanı bulunmamaktadır ve sertifika güvenilir bir CA zincirine bağlanmamaktadır. Test ortamı için iç CA tabanlı yönetilebilir bir yapı kurulması; üretim ortamında ise güvenilir CA’dan alınmış, SAN alanı doğru yapılandırılmış, SHA-256 veya üzeri algoritmayla imzalanmış ve otomatik yenileme sürecine bağlı bir sertifika kullanılması önerilir.

Terimler Sözlüğü

Bu Modülde Neler Öğrendik?

Bu modül, kriptografinin en görünür pratik uygulamalarından olan dijital imza, PKI ve TLS yapılarını ele aldı.

Dijital imzanın şifrelemeden farklı bir amaç taşıdığı netleşti. İmza gizlilik sağlamaz; bütünlük, açık anahtara dayalı doğrulama ve doğru güven modeli içinde inkâr edememe hedefine katkı sağlar. İmzalama özel anahtarla, doğrulama açık anahtarla yapılır.

Hash ve imza ilişkisi kavrandı. İmza şemaları büyük veriyi doğrudan işlemek yerine verinin özeti veya algoritmanın tanımladığı mesaj temsili üzerinden çalışır. Veri değiştiğinde bu temsil değişir ve imza doğrulaması başarısız olur.

RSA, ECDSA, EdDSA ve DSA arasındaki güncel farklar öğrenildi. RSA-PSS hâlâ uyumluluk açısından önemli bir seçenekken, ECDSA ve EdDSA modern sistemlerde güçlü alternatiflerdir. DSA ise yeni imza üretimi için legacy kabul edilmelidir.

PKI’nin varlık nedeni anlaşıldı: açık anahtarın kime ait olduğunu doğrulanabilir biçimde göstermek. Sertifika zinciri, root CA, intermediate CA, leaf certificate ve trust anchor kavramları yerli yerine oturdu.

X.509 sertifikasının subject, issuer, SAN, geçerlilik tarihleri, imza algoritması, public key, basic constraints ve key usage gibi temel alanları OpenSSL veya tarayıcı arayüzü üzerinden okunabilir hâle geldi.

TLS’in amacı, el sıkışmasının üst düzey mantığı ve kilit simgesinin neyi ifade edip neyi ifade etmediği kavrandı. Kilit simgesinin “site güvenilirdir” anlamına gelmediği; yalnızca bağlantının TLS ile kurulduğu ve sertifika doğrulamasının başarılı olduğu anlaşıldı.

Wireshark ile TLS trafiğinin nasıl göründüğü, OpenSSL ile sertifika alanlarının nasıl yorumlanacağı ve testssl.sh/SSL Labs gibi araçların hangi sınırlar içinde kullanılacağı öğrenildi.

Bir güvenlik ekibine veya geliştiriciye sertifika sorununu — süresi, algoritması, SAN alanı, zincir bütünlüğü, TLS sürümü — sade ve doğru biçimde aktarmak için gerekli temel dil kazanıldı.

Bu modülde tehdit modeli ve güven varsayımlarından başlayarak yaygın kriptografik hatalar, güvenli rastgelelik, anahtar yaşam döngüsü, kütüphane seçimi ve güvenli API kullanımı ele alınacaktır. Modülün son bölümünde öğrenci, gerçek sistemlerde kriptografik bulguların nasıl göründüğünü ve bu bulguların güvenlik ekibine nasıl sade, doğru ve uygulanabilir biçimde aktarılacağını görecektir.

Bu modülü tamamlayan öğrenci, “şifreleme var mı?” sorusundan daha olgun bir noktaya geçer ve “hangi algoritma, hangi mod, hangi anahtar, hangi rastgelelik kaynağı, hangi kütüphane, hangi tehdit modeline karşı kullanılıyor?” sorusunu sormayı öğrenir.

Kriptografik bir güvenlik bulgusunu — yanlış algoritma, eski kütüphane, zayıf rastgelelik, süresi dolmuş sertifika, sabit IV, hardcoded anahtar — güvenlik ekibine sade ve doğru biçimde aktarabilir.

8.1 Tehdit Modeli ve Güven Varsayımları

Kriptografi belirli güvenlik sorunlarını çözmek için tasarlanmıştır; ancak hiçbir kriptografik araç her saldırıya cevap vermez. Bir sistemin ne kadar güvenli olduğunu değerlendirmek için önce “neye karşı korunmak istiyoruz?” sorusuna cevap vermek gerekir. Bu sorunun sistematik yanıtı tehdit modelidir.

Tehdit modeli, bir sistemin hangi saldırgan tiplerine karşı savunma kurduğunu, hangi varlıkları koruduğunu ve hangi güven varsayımlarına dayandığını tanımlayan çerçevedir. Tehdit modeli olmadan “bu sistem güvenli mi?” sorusu eksik kalır; çünkü güvenlik her zaman “hangi saldırgana, hangi yeteneklere ve hangi hedefe karşı?” sorularıyla birlikte değerlendirilir.

Pasif saldırgan, yalnızca trafiği izler ve mesajları değiştirmez. Örneğin ağda trafik dinleyen bir saldırgan, TLS ile korunmuş uygulama verisini doğrudan okuyamaz. Şifreli kanal, pasif dinleyiciye karşı güçlü koruma sağlar; fakat bu koruma doğru TLS yapılandırması, geçerli sertifika doğrulaması ve modern algoritmalarla anlamlıdır.

Aktif saldırgan, trafiği yakalayabilir, değiştirebilir, sahte mesaj enjekte edebilir veya iki tarafın iletişimine müdahale edebilir. Aktif saldırgana karşı yalnızca şifreleme yeterli değildir; kimlik doğrulama ve bütünlük mekanizmaları da gerekir. Bir saldırgan, kendisini iki tarafın arasına yerleştirip her iki tarafla ayrı ayrı güvenli gibi görünen bağlantılar kurabiliyorsa, sistemin yalnızca “şifreli” olması güvenli olduğu anlamına gelmez.

MITM, yani Ortadaki Adam saldırısı, iki taraf arasındaki iletişime girerek tarafları yanıltmayı hedefler. Diffie-Hellman anahtar anlaşması pasif dinleyiciye karşı güçlüdür; ancak kimlik doğrulama olmadan aktif MITM saldırısına açıktır. Saldırgan, her iki tarafla ayrı ayrı anahtar anlaşması yapabilir ve taraflar birbirleriyle konuştuğunu sanarken aslında saldırganla konuşuyor olabilir. TLS bu riski yalnızca “şifreleme” ile değil; sertifika zinciri doğrulaması, el sıkışma imzaları, anahtar anlaşması ve bütünlük koruması gibi mekanizmaları birlikte kullanarak azaltır.

Kriptografi yanlış sistem tasarımını tek başına düzeltemez. Kimlik doğrulaması eksik bir protokole yalnızca şifreleme eklemek, sistemi otomatik olarak güvenli hâle getirmez. Saldırgan hâlâ doğru tarafmış gibi davranabilir. Kriptografik araçlar ancak doğru tehdit modeline uygun biçimde seçilip yapılandırıldığında beklenen korumayı sağlar.

Kriptografi ayrıca uygulamanın mantık hatalarını, yetkilendirme eksikliklerini, sosyal mühendislik saldırılarını ve fiziksel güvenlik açıklarını çözmez. Veriler güçlü biçimde şifrelense bile, uygulama şifre çözme anahtarına sahipse ve yetkisiz kullanıcıya bu veriyi gösteriyorsa problem kriptografik değil, yetkilendirme problemidir. Kriptografi verinin korunmasına katkı sağlar; ancak erişim kararlarını doğru vermeyen bir uygulamayı tek başına güvenli yapmaz.

Her kriptografik sistem bazı güven varsayımlarına dayanır. Simetrik kriptografide tarafların anahtarı güvenli sakladığı varsayılır; anahtar sızarsa sistemin güvenliği bozulur. PKI’da root CA’ların güvenilir olduğu varsayılır. Bir root veya intermediate CA’nın güvenliği bozulursa o CA’ya bağlı sertifika zincirleri risk altına girer ve istemci güven depolarının güncellenmesi, iptal süreçleri veya acil müdahale gerekebilir. Bu varsayımları bilmek, sistemin gerçek güvenlik sınırlarını anlamak için zorunludur.

8.2 Yaygın Kriptografik Hatalar

Kriptografik güvenlik açıklarının büyük bölümü, algoritmanın doğrudan kırılmasından değil, güçlü bir algoritmanın yanlış kullanılmasından kaynaklanır. Gerçek sistemlerde en sık görülen problemler; eski algoritmalar, yanlış şifreleme modu, nonce/IV tekrarı, zayıf rastgelelik, hardcoded key ve yanlış kütüphane kullanımıdır.

Yanlış algoritma seçimi, temel ama hâlâ yaygın bir hatadır. MD5 ile güvenlik kararı vermek, 1024 bit RSA anahtarı kullanmak, DES ile veri şifrelemek, RC4’e güvenmek veya SHA-1 ile yeni sertifika/imza üretmek güncel güvenlik beklentileriyle uyumlu değildir. Bu algoritmaların bazıları hâlâ araçlarda ve kütüphanelerde bulunabilir; ancak destekleniyor olmaları güvenli oldukları anlamına gelmez. 3DES/TDEA de yeni sistemlerde kullanılmamalıdır; modern tasarımlarda AES-GCM veya ChaCha20-Poly1305 gibi AEAD sağlayan yapılar tercih edilmelidir.

ECB modu kullanımı, simetrik kriptografide klasik hatalardan biridir. ECB, aynı düz metin bloğunu aynı anahtar altında her seferinde aynı şifreli metin bloğuna dönüştürür. Bu nedenle veri içindeki blok düzeyi örüntüler şifreli metinde de korunabilir. Görüntü verisi ECB ile şifrelendiğinde orijinal görüntünün sınırlarının şifreli hâlde dahi seçilebildiği “ECB penguen problemi” bu hatayı görselleştiren yaygın bir örnektir. ECB, genel amaçlı veri şifreleme için güvenli kabul edilmez ve üretim sistemlerinde veri gizliliği sağlamak amacıyla kullanılmamalıdır. NIST SP 800-38A, ECB, CBC, CFB, OFB ve CTR gibi blok şifre çalışma modlarını ayrı ayrı tanımlar; bu da mod seçiminin algoritmadan ayrı bir güvenlik kararı olduğunu gösterir.

Nonce/IV tekrar kullanımı, kullanılan moda göre farklı sonuçlar doğurur; bu nedenle tek bir cümleyle genellenmemelidir. CBC gibi modlarda IV’nin tahmin edilemez olması gerekir. NIST SP 800-38A, CBC ve CFB modları için IV’nin tahmin edilemez olması gerektiğini belirtir. CTR ve GCM gibi modlarda ise kritik şart aynı anahtar altında nonce, IV veya sayaç bloğunun tekrar kullanılmamasıdır. OWASP da IV/nonce değerlerinin kullanılan moda uygun seçilmesi ve sabit anahtar altında tekrar kullanılmaması gerektiğini vurgular.

GCM’de aynı anahtar altında nonce/IV tekrar kullanımı çok ciddi bir güvenlik hatasıdır. Bu durumda gizlilik zayıflar; ayrıca GCM’nin GHASH tabanlı doğrulama yapısı nedeniyle saldırganın geçerli authentication tag üretme olasılığı artabilir. RFC 5116, GCM’de aynı nonce’un aynı anahtarla tekrar kullanılmasının gizliliği zayıflattığını ve o anahtar için sağlanan bütünlük/authenticity korumasını da temelden sarstığını belirtir.

Bir örnek düşünelim: Bir web uygulaması her kullanıcının oturum tokenını aynı AES anahtarı ve sabit IV ile CBC modunda şifreliyorsa, aynı ilk plaintext bloğu aynı ilk ciphertext bloğunu üretir. Bu durum token yapısı, kullanıcı rolü veya sabit alanlar gibi tekrar eden veriler hakkında örüntü sızıntısına yol açabilir. CTR veya akış şifresi benzeri yapılarda ise nonce ya da anahtar akışı tekrarlandığında iki ciphertext’in XOR’u, iki plaintext arasındaki ilişkiyi açığa çıkarabilir. Bu ayrım önemlidir; çünkü CBC’deki sabit IV hatası ile CTR/GCM’deki nonce tekrarı aynı matematiksel etkiyi üretmez, fakat ikisi de ciddi tasarım hatasıdır.

Zayıf rastgelelik, güçlü algoritmaları bile boşa çıkarabilir. Kriptografik anahtar, nonce, seed veya token üretiminde güvenli olmayan rastgele sayı üreteçleri kullanılması ciddi bir hatadır. rand(), zaman tabanlı seed veya bazı dillerin genel amaçlı random() fonksiyonları kriptografik sır üretimi için uygun değildir. Seed değeri tahmin edilebilirse saldırgan üretilen değerleri yeniden hesaplayabilir.

Anahtarın kod içine gömülmesi, yani hardcoded key, sahada en sık görülen ve en tehlikeli hatalardan biridir. Şifreleme anahtarını, API token’ını veya gizli değeri doğrudan kaynak koduna yazmak, kodu gören herkesin bu sırra erişebilmesi anlamına gelir. Kod bir sürüm kontrol sistemine yüklendiğinde risk büyür; anahtar daha sonra silinse bile git geçmişinde kalabilir. Yorum satırına alınmış bir anahtar da güvenli değildir. Kaynak kodu gören kişi yorum satırını da görür.

Eski algoritmaları kullanmaya devam etmek, “sistem çalışıyor, dokunmayalım” yaklaşımının kriptografideki karşılığıdır. Bir algoritmanın yıllardır sorunsuz çalışıyor gibi görünmesi, güvenli olduğu anlamına gelmez. Güvenlik standartları, saldırı teknikleri, donanım gücü ve kütüphane önerileri zamanla değişir. Bu nedenle algoritma ve parametre seçimi bir kez yapılıp unutulacak bir karar değildir.

Kendi kripto algoritmasını yazma hatası, kriptografi güvenliğinin en temel uyarılarından biridir. Kriptografik algoritma tasarımı çok hassas bir alandır. Küçük bir rastgelelik hatası, yanlış padding, hatalı nonce yönetimi veya öngörülemeyen yan kanal problemi tüm güvenliği ortadan kaldırabilir. Uygulama geliştirme bağlamında kendi algoritmasını tasarlamak yerine, standart hâle gelmiş algoritmaları güvenilir ve bakımı süren kütüphaneler aracılığıyla kullanmak gerekir.

8.3 Güvenli Rastgelelik

Kriptografide rastgelelik, yalnızca “karışık görünen sayı” üretmek değildir. Kriptografik rastgelelik, saldırganın çıktıları pratik hesaplama kaynaklarıyla tahmin edememesi ve önceki çıktılardan gelecek değerleri güvenilir biçimde çıkaramaması anlamına gelir. CSPRNG’ler, yeterli entropiyle başlatıldıklarında bu tür tahmin edilemez değerler üretmeyi hedefler. NIST SP 800-90A Rev. 1, deterministik rastgele bit üretim mekanizmalarını hash fonksiyonu veya blok şifre gibi yapılara dayalı olarak tanımlar.

Sıradan rastgele sayı üreteçleri oyun, simülasyon veya istatistiksel uygulamalar için yeterli olabilir; ancak güvenlik sırrı üretmek için uygun değildir. Kriptografik anahtar, parola sıfırlama tokenı, oturum tokenı, nonce veya seed üretimi için dilin veya platformun sağladığı güvenli rastgelelik API’leri kullanılmalıdır.

Modern uygulamalarda doğrudan düşük seviyeli sistem kaynağına erişmek yerine dilin veya platformun sunduğu güvenli API tercih edilmelidir. Python’da secrets modülü, güvenlik tokenları ve benzeri sırlar için kriptografik olarak güçlü rastgele değerler üretmek amacıyla tasarlanmıştır. Java’da SecureRandom, Node.js’te crypto.randomBytes, Windows’ta BCryptGenRandom gibi API’ler bu amaca hizmet eder.

Seed, deterministik rastgele sayı üretecinin başlangıç değeridir. Seed tahmin edilebilirse üretilen değerler de tahmin edilebilir hâle gelir. Bu nedenle kriptografik sistemlerde seed yüksek entropili ve güvenilir kaynaklardan gelmelidir. Zaman damgası, işlem ID’si veya tahmin edilebilir kullanıcı verisi seed için yeterli değildir.

Nonce üretimi, kullanılan algoritma ve moda bağlıdır. Nonce, aynı anahtar ve aynı kullanım bağlamı altında tekrar edilmemesi gereken değerdir. Nonce her zaman rastgele olmak zorunda değildir; bazı tasarımlarda sayaç tabanlı benzersiz nonce yönetimi güvenli olabilir. Ancak sayaç mantığı kullanılıyorsa sayaç durumunun güvenli tutulması, çakışmaması ve yeniden başlatmalarda aynı değerin tekrar üretilmemesi gerekir. Rastgele nonce kullanılıyorsa da çakışma riski tasarımın hacmine göre değerlendirilmelidir.

Anahtar üretimi mutlaka kriptografik açıdan güvenli rastgelelik kullanmalıdır. Anahtarı kullanıcı girdisinden, zaman damgasından veya düşük entropili herhangi bir kaynaktan doğrudan üretmek güvenli değildir. Kullanılan kütüphanenin anahtar üretim fonksiyonları tercih edilmeli, geliştirici kendi rastgelelik mekanizmasını oluşturmaya çalışmamalıdır.

2008’de Debian’a özgü bir OpenSSL değişikliği, rastgele sayı üretimini tahmin edilebilir hâle getirdi. Sonuç olarak Debian tabanlı sistemlerde üretilen birçok kriptografik anahtar çok dar bir olasılık alanına sıkıştı ve brute force ile tahmin edilebilir hâle geldi. Debian güvenlik duyurusu, bu hatanın Debian’a özgü bir OpenSSL değişikliğinden kaynaklandığını ve kriptografik anahtar materyalinin tahmin edilebilir olabileceğini belirtir. Bu olay, rastgelelik hatalarının güçlü algoritmaları bile nasıl boşa çıkarabileceğini gösteren klasik örneklerden biridir.

Rastgelelik tahmin edilebilir olduğunda güvenlik zinciri en baştan kırılır. Oturum tokenı zaman damgasına dayalı üretiliyorsa saldırgan tokenları tahmin edebilir. Anahtar deterministik ve düşük entropili biçimde üretiliyorsa anahtar uzayı pratikte küçülür. Nonce tekrar ediyorsa modern AEAD modu bile güvenlik beklentisini kaybedebilir.

Bu nedenle güvenli alışkanlık nettir: kriptografik amaçla genel amaçlı rand(), random() veya zaman tabanlı üretim kullanılmamalıdır. Dilin veya platformun sunduğu CSPRNG tabanlı güvenli API’ler tercih edilmelidir.

8.4 Anahtar Yaşam Döngüsüne Giriş

Kriptografik anahtarın güvenliği yalnızca üretildiği anda belirlenmez. Anahtarın üretimden imhaya kadar geçen tüm yaşam döngüsü güvenli yönetilmelidir. OWASP Key Management Cheat Sheet; anahtar üretimi, dağıtımı, saklanması, rotasyonu, imhası, compromise/recovery ve zeroization gibi süreçlerin dokümante edilmesini ve uyumlu biçimde yönetilmesini önerir.

Anahtar üretimi, CSPRNG kullanımını ve uygun anahtar uzunluğunu gerektirir. Kullanılan algoritmanın güvenlik seviyesine göre yeterli uzunlukta ve yeterli entropiye sahip anahtar üretilmelidir. Kullanıcıdan alınan parola doğrudan anahtar olarak kullanılmamalı; gerekiyorsa uygun bir KDF ile işlenmelidir.

Anahtar saklama, en kritik aşamalardan biridir. Anahtarlar erişim kontrolü olmayan düz metin dosyalar olarak saklanmamalıdır. Üretim ortamlarında anahtarlar mümkünse KMS, HSM, secrets manager veya işletim sisteminin güvenli anahtar deposu gibi kontrollü mekanizmalarla yönetilmelidir. OWASP, anahtarları basit yapılandırma dosyalarında tutmak yerine merkezi yönetim, kolay rotasyon ve daha zor anahtar dışa aktarımı gibi avantajlar sağlayan güvenli saklama çözümlerini vurgular.

Anahtar dağıtımı, anahtarın taraflar arasında güvenli biçimde ulaştırılması problemidir. Anahtarın düz metin olarak e-posta, mesajlaşma uygulaması veya şifrelenmemiş kanal üzerinden gönderilmesi kabul edilemez. Asimetrik kriptografi, DH/ECDH anahtar anlaşması ve sertifika tabanlı güven modeli bu problemi çözmek için kullanılır.

Anahtar rotasyonu, bir anahtarın belirli aralıklarla veya belirli olaylar sonrasında yenilenmesidir. Bir anahtar ne kadar uzun süre kullanılırsa o anahtarla korunan veri miktarı artar ve anahtar sızarsa etki alanı büyür. Rotasyon politikası; anahtarın kullanım süresi, veri hassasiyeti, sistemin işlem hacmi ve mevzuat gereksinimleri dikkate alınarak belirlenmelidir. Secrets yönetimi tarafında rotasyon genellikle yeni sırrın oluşturulması, test edilmesi, uygulamaya geçirilmesi ve eski sırrın kapatılması gibi adımlarla güvenli geçiş gerektirir.

Anahtar imhası, yalnızca dosyayı silmekten ibaret değildir. KMS/HSM üzerinde anahtarın devre dışı bırakılması veya yok edilmesi, yedeklerdeki kopyaların değerlendirilmesi, bellekten temizleme, erişimlerin iptali ve anahtarın artık kullanılamadığının doğrulanması birlikte düşünülmelidir. SSD, snapshot, yedekleme ve bulut depolama yapıları nedeniyle basit dosya silme veya üzerine yazma her zaman yeterli olmayabilir.

Anahtarların kullanım amacına göre ayrılması, güvenli anahtar yönetiminin temel ilkelerindendir. Şifreleme, MAC üretimi, imzalama ve anahtar sarmalama gibi farklı amaçlarda aynı anahtarı kullanmak güvenlik modelinin karışmasına, yetki sınırlarının belirsizleşmesine ve anahtar sızıntısında etki alanının büyümesine yol açabilir. NIST SP 800-57, anahtar yönetiminde kullanım amacı, güvenlik gücü ve yaşam döngüsü yönetimi gibi konuları ayrı ayrı ele alır.

Bir sistemde “tek master anahtar her şeyi şifreler” yapısı görülüyorsa bu önemli bir risk işaretidir. O anahtarın ele geçirilmesi tüm sistemi etkileyebilir. Farklı işlevler için farklı anahtarlar kullanmak, olası bir sızıntıda hasarı sınırlamaya yardımcı olur.

8.5 Kriptografik Kütüphane Kullanım Prensipleri

Kriptografik algoritmayı doğru seçmek yeterli değildir; o algoritmayı kullanan kütüphanenin güvenilir, güncel ve doğru yapılandırılmış olması da en az algoritma seçimi kadar önemlidir.

Uygulama geliştirme bağlamında temel ilke şudur: kendi kriptografik algoritmanızı veya protokolünüzü yazmayın. Kriptografik algoritmayı sıfırdan uygulamak yalnızca derin kriptografi uzmanlığı, kapsamlı test, kriptanaliz ve güvenlik incelemesi gerektiren özel ekiplerin işidir. Standartlaşmış algoritmaları, bakımı süren ve geniş topluluk tarafından incelenen kütüphanelerle kullanmak çok daha güvenlidir.

Güvenilir kütüphane seçimi için yalnızca kütüphanenin adını duymak yeterli değildir. Şu sorular sorulmalıdır: Kütüphane aktif olarak bakım görüyor mu? Güvenlik açıklarına zamanında yanıt veriliyor mu? Dokümantasyonu açık mı? Güvenlik topluluğu tarafından incelenmiş mi? Eski algoritmaları varsayılan olarak mı kullanıyor? Deprecated fonksiyonları örnek kodlarda hâlâ öneriyor mu? Sürümler güvenilir şekilde yayımlanıyor mu?

Varsayılan ayarlar önemlidir. İyi tasarlanmış kütüphaneler, güvenli varsayımlar ve güvenli yüksek seviyeli API’ler sunar. Eski veya kötü tasarlanmış kütüphaneler ise uyumluluk gerekçesiyle güvensiz modları ve zayıf parametreleri hâlâ kolayca erişilebilir bırakabilir. “Kütüphane neyi varsayılan olarak seçiyor?” sorusu her zaman sorulmalıdır.

Standartlara bağlı kalmak gerekir. NIST, IETF ve benzeri standart kuruluşlarının önerdiği algoritmalar uzun süreli inceleme ve geniş uygulama deneyiminden geçmiştir. Standart dışı veya özel tasarım kriptografik çözümler ciddi risk taşır.

Güncel algoritma ve parametre kullanımı statik bir karar değildir. Yıllar önce kabul edilebilir görülen algoritmalar veya anahtar uzunlukları bugün yetersiz kalabilir. DES, RC4, MD5, SHA-1 ve bazı eski RSA anahtar boyutları bu dönüşümün örnekleridir. Bu nedenle kütüphaneler, algoritmalar ve parametreler düzenli aralıklarla güncel rehberlerle karşılaştırılmalıdır.

Kütüphane dokümantasyonlarında deprecated, legacy, insecure, not recommended, unsafe, hazardous gibi ifadeler görüldüğünde bunlar ciddi uyarı işaretleridir. Bu etiketler genellikle söz konusu algoritmanın veya fonksiyonun yeni sistemlerde tercih edilmemesi gerektiğini veya daha güvenli bir alternatifin bulunduğunu gösterir.

Bir kütüphanede hem AES-CBC hem AES-GCM seçeneğinin bulunması, ikisinin de aynı güvenlik seviyesinde önerildiği anlamına gelmez. Kütüphaneler geriye dönük uyumluluk için eski seçenekleri tutabilir. Kullanım bağlamı ve güncel kriptografi rehberleri belirleyicidir.

8.6 Güvenli Kriptografik Kütüphane Kullanımı

Bu bölüm, öğrencinin güvenli API tasarımı fikrini tanımasına odaklanır. Amaç düşük seviyeli kriptografik kod yazdırmak değil; hangi API katmanının daha güvenli varsayımlar sunduğunu ve hangi uyarıların ciddiye alınması gerektiğini öğretmektir.

Python cryptography kütüphanesi, Python ekosisteminde yaygın kullanılan ve aktif bakımı olan kriptografi kütüphanelerinden biridir. Kütüphane iki temel katman sunar: daha güvenli ve yönlendirilmiş “recipes” katmanı ile düşük seviyeli “hazardous materials”, yani hazmat katmanı. Resmî dokümantasyon, mümkün olduğunda recipes katmanının kullanılmasını ve hazmat katmanına yalnızca gerektiğinde inilmesini önerir.

Fernet, recipes katmanının örneklerinden biridir ve belirli bir simetrik şifreleme kullanım senaryosu için daha güvenli varsayımlar sunar. Hazmat katmanı ise düşük seviyeli kriptografik primitives içerir. Bu katmanın dokümantasyonunda açıkça “Hazardous Materials” uyarısı yer alır; çünkü bu seviyede yanlış parametre seçimi, yanlış mod kullanımı veya eksik doğrulama ciddi güvenlik hatalarına yol açabilir.

Bir öğrenci bu dokümantasyonda şu işaretlere özellikle dikkat etmelidir: “This is a Hazardous Materials module”, “not recommended for most use cases”, “deprecated since version X”, “use this only if you know what you are doing” gibi uyarılar, API’nin yanlış kullanıma açık olduğunu gösterir. Bu uyarıların varlığı, o fonksiyonun asla kullanılamayacağı anlamına gelmez; fakat temel seviye geliştiricinin bu katmandan uzak durması ve daha güvenli yüksek seviyeli API’leri tercih etmesi gerektiğini gösterir.

libsodium, modern kriptografi kütüphaneleri içinde güvenli API tasarımı fikrini göstermek için iyi bir örnektir. Yaygın kullanım senaryoları için güvenli varsayımlar ve yüksek seviyeli fonksiyonlar sunar. crypto_secretbox, crypto_box, crypto_sign gibi API’ler, geliştiricinin yanlış algoritma veya parametre seçme riskini azaltmayı hedefler. Ancak bu, uygulamanın otomatik olarak güvenli olduğu anlamına gelmez. Anahtar yönetimi, nonce benzersizliği, hata yönetimi, entegrasyon ve kullanım bağlamı hâlâ geliştiricinin sorumluluğundadır. Libsodium secretbox dokümantasyonu, nonce’un gizli olmak zorunda olmadığını; ancak aynı anahtarla asla tekrar kullanılmaması gerektiğini açıkça belirtir.

Yüksek seviyeli güvenli API ile düşük seviyeli tehlikeli API arasındaki fark burada belirginleşir. Yüksek seviyeli API, doğru algoritmaları ve güvenli parametreleri arka planda yönetir; kullanıcı hatası için daha az alan bırakır. Düşük seviyeli API ise daha fazla kontrol sunar; fakat IV boyutu, nonce üretimi, padding şeması, authentication tag doğrulaması ve algoritma seçimi gibi detayların bilinçli biçimde yönetilmesini gerektirir.

Kütüphane dokümantasyonu okuma alışkanlığı, güvenli kriptografi kullanımının parçasıdır. Bir kütüphaneyi kullanmadan önce veya mevcut bir sistemi değerlendirirken şu sorular sorulmalıdır: Önerilen kullanım hangisi? Deprecated olan fonksiyonlar var mı? Örnek kodlar güncel mi? Kütüphane hangi algoritmaları varsayılan seçiyor? Güvenlik güncellemeleri ne kadar hızlı yayımlanıyor?

Kütüphane güvenliği, yalnızca alt kütüphanenin kalitesiyle de sınırlı değildir. Güvenli bir kütüphanenin bakımsız veya hatalı bir wrapper üzerinden kullanılması riski yeniden artırabilir. Bu nedenle doğrudan kütüphane kadar kullanılan sarmalayıcıların, framework entegrasyonlarının ve örnek kodların da güncelliği incelenmelidir.

Komut & Araç Okuryazarlığı

Bu modülde araç okuryazarlığı, deprecated veya legacy algoritma uyarılarını tanımaya odaklanır. Ek olarak 8.6 bölümünde Python cryptography ve libsodium dokümantasyonlarının güvenli API tasarımı açısından nasıl okunacağı ele alınmıştır.

Deprecated Algoritma Uyarısını Araç Çıktısında Tanımak

OpenSSL gibi araçlar, eski veya zayıf algoritmalar kullanıldığında sürüme ve komuta bağlı olarak uyarı verebilir. Gerçek uyarı metni kullanılan OpenSSL sürümüne, provider yapılandırmasına ve komuta göre değişebilir. Bu nedenle aşağıdaki çıktı birebir gerçek çıktı olarak değil, temsili bir eğitim örneği olarak okunmalıdır.

Öğrenci çıktıda özellikle deprecated, legacy, unsupported, disabled, weak, insecure, not recommended, warning gibi ifadelere dikkat etmelidir. Bu ifadeler, kullanılan algoritma veya fonksiyonun modern güvenlik beklentilerini karşılamadığını ya da daha güvenli bir alternatifin bulunduğunu gösterebilir.

Hiçbir uyarı olmaması, kullanılan kriptografinin otomatik olarak güvenli olduğu anlamına gelmez. Ancak uyarı varsa bu mutlaka incelenmelidir. Araç işlemi tamamlayabilir; fakat bu, yapılan işlemin güvenli olduğu anlamına gelmez. “Uyarı var ama çalışıyor” yaklaşımı kriptografide ciddi bir risk doğurur.

OpenSSL 3.x ile birlikte provider yapısı ve legacy provider kavramı daha görünür hâle gelmiştir. Bazı eski algoritmalar ancak legacy provider etkinleştirildiğinde kullanılabilir. Bu, o algoritmaların modern sistemlerde önerildiği anlamına gelmez; çoğu zaman yalnızca eski verilerle uyumluluk için tutulduklarını gösterir.

Temel Seviye Güvenli Kullanım / Kontrol Listesi

Bu modülün konusu, kriptografinin doğru uygulanıp uygulanmadığını değerlendirmeye yönelik bir bakış açısı kurmayı gerektirir. Aşağıdaki kontrol listesi, bir sistemi veya kodu incelerken temel düzeyde yön gösterir.

Önce sistemin kriptografik envanteri çıkarılmalıdır. Hangi algoritmalar kullanılıyor? Hangi modlar seçilmiş? Hangi kütüphane ve hangi sürüm kullanılıyor? Anahtarlar nerede saklanıyor? Rastgele değerler hangi API ile üretiliyor? Sertifikalar, anahtarlar, tokenlar ve parola hashleme yapısı nasıl yönetiliyor?

Kullanılan algoritmalar güncel standartlara uygun olmalıdır. MD5, SHA-1, DES, RC4, düşük RSA anahtar boyutları ve yeni sistemlerde 3DES/TDEA gibi seçenekler tespit edilirse bunlar zayıf veya legacy bileşen olarak değerlendirilmelidir.

Şifreleme modu kontrol edilmelidir. ECB genel amaçlı veri şifreleme için kullanılmamalıdır. CBC kullanılıyorsa IV’nin tahmin edilemez olduğu ve bütünlük korumasının ayrıca sağlandığı doğrulanmalıdır. CTR/GCM gibi modlarda aynı anahtar altında nonce veya sayaç değerinin tekrar etmediği kontrol edilmelidir.

IV/nonce üretimi kullanılan moda uygun olmalıdır. CBC gibi modlarda IV’nin tahmin edilemez olması gerekir. CTR/GCM gibi modlarda ise kritik şart aynı anahtar altında nonce/sayaç değerinin tekrar kullanılmamasıdır. CSPRNG rastgele nonce üretmek için iyi bir seçenek olabilir; ancak bazı bağlamlarda sayaç temelli benzersiz nonce yönetimi de güvenli biçimde tasarlanabilir.

Anahtarlar kaynak koda, .env dosyalarına, yapılandırma dosyalarına veya sürüm kontrol sistemine gömülmemelidir. Kod deposu geçmişi de incelenmelidir; çünkü silinen sırlar commit geçmişinde kalabilir.

Rastgele değer üretimi CSPRNG ile yapılmalıdır. Anahtar, token, seed ve parola sıfırlama bağlantıları için genel amaçlı random() veya zaman tabanlı üretim kullanılmamalıdır.

Kütüphaneler aktif bakımda olmalıdır. Son güvenlik yamaları uygulanmış mı? Kullanılan sürüm eski mi? Dokümantasyonda deprecated uyarısı var mı? Güvenli yüksek seviyeli API yerine düşük seviyeli API yanlış kullanılmış mı? Bu sorular kontrol edilmelidir.

Anahtar rotasyon politikası tanımlanmalıdır. Anahtarın ne zaman yenileneceği, sızıntı durumunda ne yapılacağı, eski anahtarlarla şifrelenmiş verilerin nasıl yönetileceği ve anahtarın nasıl imha edileceği belirlenmiş olmalıdır.

Parola saklama ayrıca incelenmelidir. MD5, SHA-1 veya düz SHA-256/SHA-512 ile parola saklanmamalıdır. Argon2id, bcrypt veya scrypt gibi parola saklama için tasarlanmış fonksiyonlar ve her kullanıcı için benzersiz salt kullanılmalıdır.

Yanlış yorumlama riskleri unutulmamalıdır. “Şifreleme var, güvenli” demek yeterli değildir. “Ünlü kütüphane kullanılmış, o hâlde güvenlidir” demek de eksiktir. Güvenlik; algoritma, mod, parametre, anahtar yönetimi, rastgelelik, kütüphane sürümü ve tehdit modeli birlikte değerlendirilerek anlaşılır.

Geliştirici veya güvenlik ekibine öneri dili şöyle olabilir:

Mevcut sistemde DES-CBC şifreleme ve MD5 tabanlı hash üretimi tespit edilmiştir. DES, 56 bit anahtar uzunluğu nedeniyle modern güvenlik için yetersizdir; MD5 ise güvenlik amaçlı bütünlük ve parola saklama bağlamlarında kullanılmamalıdır. Güncel tasarım için AEAD sağlayan AES-GCM veya ChaCha20-Poly1305 gibi yaklaşımlara, hash tarafında SHA-256 veya daha güçlü modern algoritmalara ve parola saklama için Argon2id/bcrypt/scrypt gibi özel parola hashleme fonksiyonlarına geçilmesi önerilir. Ayrıca IV/nonce üretiminin kullanılan moda uygunluğu ve anahtar yönetimi ayrıca doğrulanmalıdır.

Analitik Senaryo

Bir kurum içi test uygulaması olan TEST-APP01 üzerinde yapılan güvenlik incelemesinde, uygulama kodunda şifreleme işlemi yapıldığı görülüyor. İnceleme sırasında kaynak kod dosyasında şu temsili yapıyla karşılaşılıyor:

Ayrıca veritabanında kullanıcı parolalarının saklandığı alanda şu formatta değerler görülüyor:

5f4dcc3b5aa765d61d8327deb882cf99

İlk değerlendirme şu olmalıdır: Burada birden fazla kriptografik hata bir arada görünmektedir. Birincisi, şifreleme anahtarı doğrudan kaynak koda gömülmüştür. Bu, kaynak koda erişen herkesin şifreleme anahtarını elde edebileceği anlamına gelir. İkincisi, IV sabittir. AES-CBC bağlamında sabit IV kullanımı, özellikle aynı ilk plaintext bloğunun aynı ilk ciphertext bloğunu üretmesine ve tekrar eden veri yapıları hakkında bilgi sızmasına neden olabilir. Üçüncüsü, parola alanında görülen değer 32 karakterlik hex çıktıdır. Bu, 128 bitlik bir çıktı olduğunu gösterir ve MD5 şüphesini güçlendirir. Verilen 5f4dcc3b5aa765d61d8327deb882cf99 değeri bilinen olarak password kelimesinin MD5 hash’iyle eşleştiği için bu senaryoda MD5 kullanıldığı güçlü biçimde anlaşılır.

Kontrol edilecek ilk nokta, anahtarın başka dosyalarda veya geçmiş commit’lerde de yer alıp almadığıdır. Bir anahtar yalnızca mevcut koddan silinse bile, sürüm kontrol geçmişinde kalmış olabilir. Bu nedenle repository geçmişi, CI/CD değişkenleri, .env dosyaları ve yapılandırma depoları incelenmelidir.

İkinci kontrol noktası IV üretimidir. IV her şifreleme çağrısında aynı mı kullanılıyor? CBC modunda IV tahmin edilemez biçimde mi üretiliyor? IV ciphertext ile birlikte saklanıyor mu? Aynı anahtar altında tekrar eden IV kullanımı var mı? Bu sorular netleştirilmeden sistemin güvenli olduğu söylenemez.

Üçüncü kontrol noktası parola saklama formatıdır. Veritabanındaki tüm parola kayıtları 32 hex karakterden oluşuyorsa, MD5 veya başka 128 bitlik hızlı hash kullanımı ihtimali araştırılmalıdır. Eğer $2b$, $argon2id$ veya benzeri bcrypt/Argon2 formatları görülmüyorsa parola saklama tasarımının zayıf olduğu düşünülmelidir.

Buradaki yaygın yanlış yorumlardan biri şudur: “Şifreleme var, o hâlde veriler korunuyor.” Bu doğru değildir. Anahtar kaynak kodda bulunduğu için koda erişen herkes veriyi çözebilir. Sabit IV ise CBC kullanımında örüntü sızıntısına neden olabilir. Diğer yanlış yorum da şudur: “Parola hash değeri var, o hâlde parola güvenli.” MD5 hızlı bir hash fonksiyonu olduğu ve parola saklama için tasarlanmadığı için saldırgan çok yüksek sayıda parola tahmini deneyebilir. Zayıf veya yaygın parolalar sözlük saldırılarıyla çok hızlı bulunabilir; güçlü parolalarda süre değişse de MD5 parola saklama için uygun değildir.

Riskin pratik karşılığı ciddidir. Kaynak kod deposuna yetkisiz erişen biri şifreleme anahtarını elde edebilir. Bu anahtar ile daha önce şifrelenmiş veriler çözülebilir veya gelecekteki veriler hedef alınabilir. Sabit IV nedeniyle tekrar eden veri yapıları ciphertext içinde iz bırakabilir. Veritabanı sızdığında MD5 ile saklanan zayıf parolalar hızlıca tahmin edilebilir.

Güvenli yaklaşım şu olmalıdır: Şifreleme anahtarı kaynak koddan çıkarılmalı ve güvenli yapılandırma yönetimi, secrets manager, KMS veya benzeri kontrollü bir mekanizmaya taşınmalıdır. CBC kullanılacaksa IV her şifreleme işlemi için tahmin edilemez biçimde üretilmeli ve ciphertext ile birlikte saklanmalıdır. Daha modern bir tasarımda AES-GCM veya ChaCha20-Poly1305 gibi AEAD sağlayan yapılar tercih edilmeli; bu yapılarda nonce benzersizliği dikkatle yönetilmelidir. Parola saklama MD5 yerine Argon2id veya uygun parametrelerle bcrypt/scrypt kullanacak şekilde yeniden tasarlanmalıdır. Mevcut kullanıcılar bir sonraki girişte parolalarını yeni sistemle yeniden hashletmelidir.

Güvenlik ekibine bulgu şu şekilde aktarılabilir:

TEST-APP01 uygulamasında üç kritik kriptografik sorun tespit edilmiştir. Şifreleme anahtarı kaynak koda gömülüdür, AES-CBC kullanımında IV sabit olarak tanımlanmıştır ve kullanıcı parolaları MD5 ile saklanıyor görünmektedir. Anahtarın güvenli sır yönetimi altyapısına taşınması, IV/nonce üretiminin kullanılan moda uygun biçimde yeniden tasarlanması ve parola saklama mekanizmasının Argon2id veya uygun parametrelerle bcrypt/scrypt tabanlı hâle getirilmesi önerilir. Ayrıca kaynak kod geçmişi anahtar sızıntısı açısından incelenmelidir.

Kendini Değerlendir — Güvenli Kullanım

Terimler Sözlüğü

Bu Modülde Neler Öğrendik?

Bu modül, temel kriptografi eğitimini pratiğe bağlayan kapanış bölümüdür. Öğrenci artık yalnızca algoritma isimlerini değil, bu algoritmaların doğru kullanılıp kullanılmadığını değerlendirecek temel bakış açısına sahiptir.

Tehdit modeli kavramı yerleşti. “Bu sistem güvenli mi?” sorusunun tek başına yeterli olmadığı; asıl sorunun “hangi saldırgana, hangi koşullarda, hangi varlığı korumak için güvenli?” olduğu anlaşıldı. Pasif ve aktif saldırgan modelleri arasındaki fark, MITM saldırısının kimlik doğrulama olmadan neden engellenemediğiyle birlikte kavrandı.

Kriptografinin sınırları netleşti. Şifreleme; kötü yetkilendirme kararlarını, iş mantığı hatalarını, sosyal mühendisliği veya fiziksel güvenlik açıklarını tek başına çözmez. Kriptografik araçlar doğru tehdit modeline uygun seçildiğinde ve doğru yapılandırıldığında koruma sağlar.

Yaygın kriptografik hatalar tanınabilir hâle geldi. ECB kullanımı, sabit IV, nonce tekrarı, hardcoded anahtar, zayıf rastgelelik, eski algoritma ve deprecated API kullanımı gerçek sistemlerde hangi izleri bırakır ve hangi riski oluşturur soruları cevaplandı.

CSPRNG ile sıradan rastgele sayı üreteci arasındaki fark kavrandı. Rastgelelik hatalarının, güçlü algoritmaları bile nasıl güvensiz hâle getirebileceği Debian OpenSSL olayı üzerinden somutlaştı.

Anahtar yaşam döngüsünün aşamaları öğrenildi: üretim, saklama, dağıtım, rotasyon ve imha. Aynı anahtarın farklı amaçlarla kullanılmasının güvenlik modelini bozabileceği ve anahtar sızıntısında etki alanını büyütebileceği anlaşıldı.

Kütüphane seçiminde bakım durumu, güvenlik geçmişi, dokümantasyon, varsayılan ayarlar ve deprecated uyarılarının önemi kavrandı. “Kütüphane çalışıyor” ile “kütüphane güvenli ve doğru kullanılıyor” arasındaki fark netleşti.

Yüksek seviyeli ve düşük seviyeli API ayrımı, Python cryptography ve libsodium örnekleri üzerinden somutlaştı. Güvenli varsayımlar sunan API’lerin hata yüzeyini azalttığı; ancak anahtar yönetimi, nonce benzersizliği ve entegrasyon güvenliğinin hâlâ uygulamanın sorumluluğunda olduğu öğrenildi.

Araç çıktılarında deprecated, warning, legacy, not recommended gibi ifadelerin ne anlama geldiği ve bu uyarıların neden ciddiye alınması gerektiği anlaşıldı.

Bir kriptografik güvenlik bulgusunu — hardcoded anahtar, zayıf parola hashleme, sabit IV, eski algoritma, hatalı nonce yönetimi — güvenlik ekibine sade, doğru ve öneri içeren bir dille aktarabilmek için gereken temel çerçeve kazanıldı.