DJB ve Security-by-Construction: qmail'den Curve25519'e

Jargondan Uzak: Security-by-Construction Ne Anlatıyor?\n\nSecurity-by-construction, yaygın hataların yapılmasını zorlaştıran ve kaçınılmaz hataların zararını sınırlayan bir sistem kurmak demektir. Uzun bir kontrol listesine («X'i doğrula, Y'yi temizle, Z'yi yapılandır…») güvenmek yerine, en güvenli yolun aynı zamanda en kolay yol olması için yazılımı tasarlarsınız.\n\nBunu çocuk güvenlik ambalajına benzetin: herkesin mükemmel dikkatli olacağını varsaymaz; insanların yorgun, meşgul ve bazen yanlış olduğunu varsayar. İyi tasarım, geliştiricilerden, işletmecilerden ve kullanıcılardan beklenen “mükemmel davranış” miktarını azaltır.\n\n### Neden sadelik riski düşürür\n\nGüvenlik sorunları genellikle karmaşıklığın içinde gizlenir: çok fazla özellik, çok fazla seçenek, bileşenler arası çok fazla etkileşim. Her ekstra düğme yeni bir hata durumu yaratabilir—sistemin kırılması veya kötüye kullanılmasının beklenmedik bir yolu.\n\nSadelik iki pratik şekilde yardımcı olur:\n\n- Denetlenecek daha az kod: daha az dal, daha az istisna durumu, daha az gizli davranış.\n- Yanlış yapılandırma için daha az yol: on tane “esnek” seçenek yerine bir güvenli varsayılan olduğunda, kazara güvensizlik için daha az yer vardır.\n\nBu, salt minimalizmle ilgili değil. Amaç, sistem davranış kümesini o kadar küçük tutmaktır ki gerçekten anlayıp test edebilesiniz ve bir şey ters gittiğinde ne olacağını mantıksal olarak çıkarabilesiniz.\n\n### Bu yazıda neler ele alınıyor (neler değil)\n\nBu yazı, Daniel J. Bernstein’in çalışmalarını security-by-construction örnekleri olarak kullanır: qmail’in hata modlarını nasıl azalttığı, sabit-zaman düşüncesinin görünmez sızıntılardan nasıl kaçındığı ve Curve25519/X25519 ile NaCl’in kriptografinin yanlış kullanılmasını zorlaştırmaya nasıl yaklaştığı.\n\nYapmayacağı şeyler: kriptografinin tam tarihini sunmak, algoritmaların güvenliğini ispat etmek ya da her ürün için tek “en iyi” kütüphane olduğunu iddia etmek. Ayrıca iyi primitiflerin her şeyi çözdüğünü de iddia etmeyecek—gerçek sistemler yine anahtar yönetimi, entegrasyon hataları ve işletimsel boşluklar yüzünden başarısız olur.\n\nHedef basit: kriptografi uzmanı olmasanız bile güvenli sonuçları daha olası yapan tasarım kalıplarını göstermek.\n\n## Daniel J. Bernstein Kimdir ve Neden Çalışmaları Atıf Alır\n\nDaniel J. Bernstein (genellikle “DJB”), uygulamalı güvenlik mühendisliğinde sıkça adı geçen bir matematikçi ve bilgisayar bilimcisidir: e-posta sistemleri (qmail), kriptografik primitifler ve protokoller (özellikle Curve25519/X25519) ve gerçek dünyaya kriptografiyi paketleyen kütüphaneler (NaCl).\n\nİnsanlar DJB’yi, güvenlik için tek “doğru” yolu yazdığı için değil, projelerinin ortak bir mühendislik sezgisi seti taşıması ve böylece yanlış gitme yol sayısını azaltması nedeniyle atıf yaparlar.\n\n### Mühendislerin DJB tarzı çalışmalardan ödünç aldığı şeyler\n\nTekrarlayan tema daha küçük, daha sıkı arayüzlerdir. Bir sistem daha az giriş noktası ve daha az yapılandırma seçeneği sunarsa, incelemesi, test etmesi ve yanlış kullanımı zorlaştırması daha kolaydır.\n\nBir başka tema açık varsayımlardır. Güvenlik hataları genellikle rastgele beklentilerden gelir—rastgelelik, zamanlama davranışı, hata işleme veya anahtarların nasıl saklandığı hakkında. DJB’nin yazıları ve uygulamaları tehdit modelini somutlaştırma eğilimindedir: ne korunuyor, kimden ve hangi koşullar altında.\n\nSon olarak, güvenli varsayılanlara ve sıkıcı doğruluğa bir eğilim vardır. Bu gelenekteki birçok tasarım, belirsiz parametreleri, isteğe bağlı modları ve bilgi sızdıran performans kısayollarını ortadan kaldırmaya çalışır.\n\n### Biyografi değil—mühendislik bakışı\n\nBu makale bir yaşam öyküsü veya kişilik tartışması değildir. Mühendislik odaklıdır: qmail, sabit-zaman düşüncesi, Curve25519/X25519 ve NaCl’da gözlemleyebileceğiniz kalıplar ve bu kalıpların üretimde daha doğrulanabilir ve daha az kırılgan sistemler inşa etmeye nasıl dönüştüğü.\n\n## qmail: Daha Az Hata Modu İçin Tasarımın Pratik Bir Örneği\n\nqmail, çok gösterişli olmayan ama kritik bir problemi çözmek için inşa edildi: posta teslimini güvenilir yapmak ve posta sunucusunu yüksek değerli bir hedef olarak ele almak. Posta sistemleri internette durur, gün boyu düşmanca girdiler kabul eder ve hassas verilerle (mesajlar, kimlik bilgileri, yönlendirme kuralları) uğraşır. Tarihsel olarak, tek bir hata monolitik bir posta daemon’unda tam sistem ele geçirmeye ya da kimsenin fark etmediği sessiz mesaj kaybına yol açabilirdi.\n\n### İş böl, patlama yarıçapını küçült\n\nqmail’de belirleyici fikir, “posta teslimi”ni küçük programlara bölmektir: alma, kuyruklama, yerel teslim, uzak teslim vb. Her parça tek bir işi yapar: dar bir arayüz ve sınırlı sorumluluk.\n\nBu ayrım önemlidir çünkü hatalar lokal olur:\n\n- Bir bileşen çökerse, bu otomatik olarak kuyruğu bozmaz veya tüm sistemi devre dışı bırakmaz.\n- Bir bileşende güvenlik hatası varsa, saldırgan hemen diğer tüm parçaların ayrıcalıklarını elde edemez.\n- Bir bileşeni izole şekilde düşünebiliyorsanız, onu daha etkili test ve denetim yapabilirsiniz.\n\nBu, pratik bir biçimde security-by-construction’dır: “bir hata”nın “tam felaket”e dönüşmesini zorlaştıracak şekilde sistemi tasarlamak.\n\n### Kopyalanmaya değer tasarım alışkanlıkları\n\nqmail ayrıca e-posta dışındaki alanlara iyi aktarılan alışkanlıklar modelidir:\n\n- Net sınırlar: bir bileşenin hangi girdileri kabul ettiğini ve hangi çıktıları ürettiğini tam olarak tanımlayın. Küçük, açık sözleşmeler uygulaması daha kolaydır.\n- Sıkı girdi işleme: ağdan gelen her şeyi potansiyel olarak kötü niyetli kabul edin; erken doğrulayın, tuhaf durumları reddedin ve “yardımcı” tahminlerden kaçının.\n- Varsayılan en az ayrıcalık: bileşenleri yalnızca ihtiyaçları olan izinlerle çalıştırın, böylece bir hata otomatik olarak tam ele geçirme yaratmaz.\n\nÇıkarım “qmail kullanın” değil. Çıkarım, genellikle daha fazla kod yazmadan veya daha fazla düğme eklemeden önce daha az hata moduna göre yeniden tasarlayarak büyük güvenlik kazanımları elde edebileceğinizdir.\n\n## Saldırı Yüzeyini Daraltmak: Sıkı Arayüzler\n\n“Attack surface”, sisteminizin dürtülebileceği, kandırılabileceği veya yanlış işe zorlanabileceği tüm yerlerin toplamıdır. Bunu bir eve benzetin: her kapı, pencere, garaj kumandası, yedek anahtar ve teslimat bölmesi potansiyel bir giriş noktasıdır. Daha iyi kilitler takabilirsiniz, ama ayrıca daha az giriş noktasıyla da daha güvenli olursunuz.\n\nYazılım da aynı. Açtığınız her port, kabul ettiğiniz her dosya formatı, ortaya çıkardığınız yönetici uç noktası, eklediğiniz yapılandırma düğmesi ve desteklediğiniz eklenti kancası hata yollarını artırır.\n\n### Sıkı arayüzler: daha küçük API’ler, daha az hata modu\n\n“Sıkı arayüz”, daha az yapan, daha az varyasyonu kabul eden ve belirsiz girdileri reddeden bir API demektir. Bu genellikle kısıtlayıcı gelir—ama güvenlik açısından daha kolaydır çünkü denetlenecek daha az kod yolu ve beklenmedik etkileşim vardır.\n\nİki tasarımı düşünün:\n\n- Geniş arayüz: “Her dosya tipini yükleyin; formatı algılarız; isteğe bağlı sıkıştırma; isteğe bağlı şifreleme; isteğe bağlı metadata; birden çok kimlik doğrulama şeması.”\n- Sıkı arayüz: “Baytları yükleyin; içerik tipini küçük bir izin listesinden beyan etmelisiniz; maksimum boyut sabittir; şifreleme dahili olarak halledilir; tek bir kimlik doğrulama yöntemi.”\n\nİkinci tasarım, saldırganların manipüle edebileceği şeyi azaltır. Ayrıca ekibinizin kazara yanlış yapılandırma yapma olasılığını azaltır.\n\n### Neden daha az seçenek daha güvenli olabilir\n\nSeçenekler testi çoğaltır. On adet togglle destekliyorsanız, yalnızca 10 davranışınız yoktur—kombinasyonlarınız vardır. Birçok güvenlik hatası bu dikiş yerlerinde yaşar: “bu bayrak kontrolü devre dışı bırakıyor,” “bu mod doğrulamayı atlıyor,” “bu eski ayar oran limitlerini atlıyor.” Sıkı arayüzler “kendi maceranı seç” güvenliğini iyi aydınlatılmış bir yola çevirir.\n\n### Kontrol listesi: karmaşıklığın gizlendiği yerler\n\nSaldırı yüzeyinin gizlice büyüdüğü yerleri tespit etmek için kullanın:\n\n- Birçok girdi tipi: birden fazla dosya formatı, kodlama veya “otomatik algılama” ayrıştırması.\n- Çok fazla giriş yolu: ekstra ağ portları, yönetici panelleri, hata ayıklama uç noktaları, webhooks.\n- Güvenlik mantığını değiştiren özellik bayrakları: doğrulamayı, kimlik doğrulamayı veya kripto davranışını değiştiren toggllelar.\n- Eklene bilirlik: çalışırken değerlendirilen betikler, şablonlar, eklentiler veya “özel ifadeler”.\n- Geriye dönük uyumluluk modları: eski protokoller, eski şifreler, kullanımdan kalkmış API sürümleri.\n- Örtük varsayılanlar: ortam değişkenlerine veya eksik yapılandırmaya bağlı olarak değişen davranış.\n\nArayüzü küçültme imkanı yoksa, onu sıkılaştırın: erken doğrulayın, bilinmeyen alanları reddedin ve “güçlü özellikleri” açıkça sınırlandırılmış endpointlerin arkasına koyun.\n\n## Sabit-Zaman Düşüncesi: Gözle Görülmeyen Sızıntıları Önlemek\n\n“Sabit-zaman” davranış, bir hesaplamanın gizli değerlerden (özel anahtarlar, nonceler veya ara bitler gibi) bağımsız olarak yaklaşık aynı süreyi almasını ifade eder. Amaç hızlı olmak değil; sıkıcı olmaktır: saldırgan çalışma zamanı ile sırlar arasında korelasyon kuramazsa, sırları gözlemleyerek çıkarması çok zorlaşır.\n\nZamanlama sızıntıları önemlidir çünkü saldırganlar her zaman matematiği kırmaya ihtiyaç duymaz. Aynı işlemi birçok kez çalıştırabiliyorlarsa (veya paylaşılan donanımda izleyebiliyorlarsa), mikro saniyeler, nano saniyeler hatta önbellek etkileri bile biriktiğinde anahtar kurtarmaya yol açan örüntüleri açığa çıkarabilir.\n\n### Zamanlama değişkenliği nereden sızar\n\nNormal kod bile veriye bağlı olarak farklı davranabilir:\n\n- Gizli veriye göre dallanan kontrol: if (secret_bit) { ... } kontrol akışını ve genellikle çalışma zamanını değiştirir.\n- Gizli indeksli tablo aramaları: gizli bağımlı indekslerin farklı önbellek hatlarına yol açması klasik örnektir.\n- Önbellek ve bellek etkileri: gizli bağımlı bellek erişimi CPU önbellekleri, sayfa hataları veya önekleme davranışları aracılığıyla sızabilir.\n- Değişken-zamanlı talimatlar: bazı büyük sayı işlemleri, bölme veya erken çıkışlı döngüler belirli girdilerde daha uzun sürebilir.\n\n### Zamanlama riski denetimi için üst düzey yollar\n\nAssembly okumaya gerek yok, denetimden değer elde etmek için:\n\n1. Gizli etkiyi izleyin: hangi değişkenlerin gizli olduğunu (özel anahtarlar, paylaşılan sırlar, kimlik doğrulama etiketleri) ve bunların nerelere aktığını listeleyin.\n2. Kırmızı bayrakları arayın: gizli veriye dayalı if ifadeleri, dizi indeksleri, sır tabanlı sonlanma döngüleri ve “hızlı yol/yavaş yol” mantığını arayın.\n3. Bağımlılıkları tehdit modelinin parçası sayın: kripto kütüphanelerinin ilgili işlemler için sabit-zaman iddiası olup olmadığını doğrulayın.\n4. Varyansı test edin: farklı sırlarla işlemleri birçok kez çalıştırın ve dağılımları ölçün; tutarlı büyük farklılıklar uyarı işaretidir.\n\nSabit-zaman düşüncesi kahramanlıktan çok disiplinle ilgilidir: sırların zamanlamayı yönlendirmemesini sağlayacak şekilde kod tasarlamak.\n\n## Curve25519 ve X25519: Yanlış Kullanımı Zorlaştıran Kripto\n\nEliptik eğri anahtar değişimi, iki cihazın yalnızca “açık” mesajlar göndererek aynı paylaşılan sırrı oluşturmasını sağlar. Her taraf gizli bir değer (özel) üretir ve buna karşılık gelen bir açık değer (gönderilmesi güvenli) çıkarır. Açık değerler değiş tokuş edildikten sonra, her taraf kendi özel değeri ile diğer tarafın açık değerini birleştirerek aynı paylaşılan sırra ulaşır. Dinleyen kişi açık değerleri görür ama pratikte paylaşılan sırrı yeniden oluşturamaz; bu sayede taraflar simetrik şifreleme anahtarları türetebilir ve gizlice iletişim kurabilir.\n\n### Curve25519/X25519 neden popüler oldu\n\nCurve25519 temel eğridir; X25519 bunun üzerine kurulmuş standartlaştırılmış, “bu belirli işlemi yap” anahtar-değişimi fonksiyonudur. Çekicilikleri büyük ölçüde security-by-construction’dur: daha az tetikleyici hata, daha az parametre seçimi ve kazara güvensiz ayar seçme yollarının azalması.\n\nAyrıca geniş bir donanım aralığında hızlıdır; bu, çok sayıda bağlantıyı yöneten sunucular ve pil tasarrufu yapmaya çalışırken telefonlar için önemlidir. Tasarım, sabit-zamana uygun uygulamaları desteklemeyi teşvik eder (zamanlama saldırılarına karşı direnç), bu da küçük performans farklılıklarını ölçerek sırları çıkarmaya çalışan saldırgan riskini azaltır.\n\n### Ne sağlar—ne sağlamaz\n\nX25519 size anahtar anlaşması sağlar: iki tarafın simetrik şifreleme için paylaşılan sır türetmesine yardımcı olur.\n\nKendisi tek başına kimlik doğrulama sağlamaz. X25519’yi karşı tarafın kim olduğunu doğrulamadan kullanırsanız (örneğin sertifikalar, imzalar veya ön paylaşılan anahtarlarla), yine yanlış tarafla güvenli görüşme yapacak şekilde kandırılabilirsiniz. Başka bir deyişle: X25519 dinlemeyi engellemeye yardımcı olur, ama tek başına taklit etmeyi durdurmaz.\n\n## NaCl’in Büyük Fikri: Daha Az Seçenek, Daha Az Hata\n\nNaCl (Networking and Cryptography library), uygulama geliştiricilerinin kazara güvensiz kriptografiyi birleştirmesini zorlaştırmak amacıyla inşa edildi. Çeşitli algoritmalar, modlar, padding kuralları ve yapılandırma düğmeleri sunmak yerine NaCl sizi yüksek seviyeli, güvenli bir şekilde birlikte çalışan işlemler kümesine yönlendirir.\n\n### “box” ve “secretbox” daha güvenli yapı taşları olarak\n\nNaCl’in API’leri ne yapmak istediğinize göre adlandırılır, hangi primitifleri birleştireceğinize göre değil.\n\n- crypto_box (“box”): açık anahtarlı doğrulanmış şifreleme. Özel anahtarınızı, alıcının açık anahtarını, bir nonce ve mesaj verirsiniz. Mesajı gizleyen ve doğru anahtara sahip birinden geldiğini kanıtlayan bir şifremetin elde edersiniz.\n- crypto_secretbox (“secretbox”): paylaşılan anahtarlı doğrulanmış şifreleme. Aynı fikir, ama tek bir paylaşılan sır anahtarı ile.\n\nAnahtar fayda, ayrı ayrı “şifreleme modu” ve “MAC algoritması” seçmemenizdir; bunları kendiniz doğru şekilde birleştirmeyi ummazsınız. NaCl’in varsayılanları modern, yanlış kullanıma dirençli bileşimleri (encrypt-then-authenticate gibi) zorlar, bu yüzden bütünlüğü unutma gibi yaygın hata modları çok daha az olasıdır.\n\n### Takas: daha az seçenek vs esneklik\n\nNaCl’in sıkılığı, eski protokoller, özel formatlar veya düzenleyici gereksinimli algoritmalarla uyumluluk gerektiğinde sınırlayıcı gelebilir. “Her parametreyi ayarlayabilirim”ı “kripto uzmanı olmadan güvenli bir şey gönderebilirim” ile takas ediyorsunuz.\n\nBirçok ürün için bu tam da amaçtır: hata olasılıklarını azaltmak için tasarım alanını kısıtlamak. Gerçekten özelleştirme gerekiyorsa, daha düşük seviyeli primitiflere inebilirsiniz—ama keskin kenarlara geri dönmeyi kabul etmiş olursunuz.\n\n## Güvenli Varsayılanlar ve Çok Fazla Düğmenin Maliyeti\n\n“Varsayılan olarak güvenli” demek, hiçbir şey yapmadığınızda en makul ve en güvenli seçeneği elde ettiğiniz anlamına gelir. Bir geliştirici bir kütüphane kurduğunda, hızlı bir örneği kopyaladığında veya çerçeve varsayılanlarını kullandığında sonuç yanlış kullanımı zorlaştırmalı ve kazara zayıflatmayı zorlaştırmalıdır.\n\nVarsayılanlar önemlidir çünkü gerçek dünyadaki çoğu sistem bunlarla çalışır. Ekipler hızlı hareket eder, dökümantasyon aceleyle okunur ve yapılandırma organik olarak büyür. Varsayılan “esnek” ise, bu genellikle “yanlış yapılandırması kolay” demektir.\n\n### Varsayılanların sessizce risk yaratması\n\nKripto hataları her zaman “kötü matematik”ten kaynaklanmaz. Genellikle tehlikeli bir ayarın seçilmesiyle oluşur çünkü o seçenek vardı, tanıdıktı veya kolaydı.\n\nYaygın varsayılan tuzakları şunlardır:\n\n- Zayıf veya öngörülebilir rastgelelik: kriptografik olmayan PRNG’ler kullanmak, tohumları yeniden kullanmak veya konteyner/VM’lerde düşük entropi kaynaklarına geri dönmek. Anahtar üretimi sallantılı rastgeleliğe bağlıysa, onun üstüne inşa edilen her şey bu zayıflığı miras alır.\n- Uyumluluk için hala desteklenen eski algoritmalar: SHA-1, MD5 veya eski RSA boyutlarını “her ihtimale karşı” açık bırakmak ve sonra sistemin üretimde onlara düşmesi.\n- Özel veya sıra dışı modlar ve parametreler: blok şifre modları, padding kuralları, nonce işleme veya ev yapımı şemalar için çok sayıda düğme sunmak. Seçenekler arttıkça, şifreli görünen ama güvenli olmayan bir protokol oluşturma olasılığı artar.\n\n### Pratik bir kural: daha az seçenek, daha güvenli sonuçlar\n\nGüvenli yolu en kolay yol haline getiren yığınları tercih edin: denetlenmiş primitifler, ihtiyatlı parametreler ve güvenli olmayan seçenekleri sormayan API’ler. Bir kütüphane sizi on algoritma, beş mod ve birden çok kodlama arasında seçim yapmaya zorluyorsa, yapılandırma ile güvenlik mühendisliği yapmaya davet ediyorsunuz demektir.\n\nMümkün olduğunda, kütüphaneleri ve tasarımları seçin ki:

\n- modern, geniş incelemeye tabi algoritmaları varsayılan yapsınlar