mthiim/dilithium-java - Java ile kuantum bilişime dayanıklı kriptografi algoritması uygulaması

• Dilithium 3.1’i Java ile uygulayan ve ilkel işlemleri bir JCE provider olarak saran bir uygulamadır; standart Java kriptografi arayüzleri üzerinden anahtar üretme, imzalama ve doğrulama kullanılabilir
• RSA ve ECC’nin Shor's algorithm kullanan kuantum bilgisayar saldırılarına karşı savunmasız olduğu arka planından hareketle, NIST’in seçtiği kuantum sonrası dijital imza yöntemlerinden biri olan Dilithium’i denemek ve öğrenmek için yapılmış bir uygulamadır
• CRYSTALS algoritma ailesine dahildir; cebirsel kafeslere dayanan Dilithium, C referans uygulaması ve belgeler temel alınarak uygulanmıştır; içeride kullanılan SHAKE128/256 ise Bouncy Castle bağımlılığıyla sağlanır
• Belgelenmiş güvenlik seviyeleri 2, 3 ve 5’in tamamını destekler; üç seviyenin tamamı deterministic signature scheme kullanır ve resmi paketin KAT testlerinden geçer
• JCE kullanım akışı, DilithiumProvider kaydedildikten sonra KeyPairGenerator.getInstance("Dilithium"), Signature.getInstance("Dilithium"), KeyFactory.getInstance("Dilithium") ile anahtar üretme, imzalama, doğrulama ve anahtar geri yükleme yapma şeklindedir
  • Güvenlik seviyesi DilithiumParameterSpec.LEVEL2, LEVEL3, LEVEL5 veya getSpecForSecurityLevel() ile belirtilir
  • Açık anahtar ve özel anahtar için .getEncoded() ile bayt temsili alınır; referans uygulamayla uyumlu biçimde serileştirme ve ters serileştirme yapılır
  • Bayt temsilinde parameter spec kodlanmadığı için anahtar geri yüklenirken DilithiumPublicKeySpec veya DilithiumPrivateKeySpec içinde parameter spec açıkça belirtilmelidir
• Resmi Dilithium paketinin known-answer test istek dosyasını okuyup yanıt dosyası üreten KAT.java yardımcı aracını sağlar; çalıştırma argümanları <input-request-file> <output-response-file> <level> biçimindedir
• Mevcut uygulama Dilithium 3.1’i yansıtır; standartlaştırma süreci devam eden FIPS 204 veya ML-DSA sürümlerinden farklıdır
• Birkaç gün içinde “for fun” yazılmış bir uygulamadır; production-grade code değildir, üçüncü taraf zafiyet incelemesi yoktur ve herhangi bir garanti ya da destek sunulmaz
• Apache 2.0 lisansıyla sunulur

[GN⁺]

Hacker News yorumları

• Projemin Hacker News’te ilgi gördüğünü görmek sevindirici. Bu, makaleden ve referans implementasyondan esinlenilmiş tamamen oyuncak bir implementasyon
  Sağlanan tüm test senaryolarını geçiyor, ancak ağırlıklı olarak eğlence için yaptım ve standart JCE arayüzüyle doğal biçimde uyumlu çalışıp çalışmadığını görmek için yazdım. Sorularınız veya geri bildirimleriniz varsa çekinmeden sorabilirsiniz

  • Gerçek bir serviste kullanmak için nelerin gerektiğini merak ediyorum. Kuantuma dayanıklı kriptografi için Java kütüphaneleri arasında üretim ortamında kullanılmaya hazır olanlar var mı, onu da bilmek isterim

• Bu Dilithium oyuncak implementasyonunun temel kısmının çoğunu burada görebilirsiniz: https://github.com/mthiim/dilithium-java/blob/main/src/main/...

  • Dilithium spesifikasyonu da burada: https://pq-crystals.org/dilithium/data/dilithium-specificati...

• RSA/ECDSA gibi daha yerleşik ve yaygın kullanılan algoritmaların üstüne kuantuma dayanıklı kriptografi algoritmaları ekleyerek kullanmanın iyi bir fikir olup olmadığını merak ediyorum
  Kuantuma dayanıklı kriptografi hâlâ çok uç noktada; kullanımı pek rahat değil

  • Aslında topluluğun yaptığı şey tam da bu yöntem gibi görünüyor
    Cloudflare kısa süre önce kuantuma dayanıklı kriptografiyi etkinleştirdi ve X25519+Kyber kullanıyor [0]. Signal’in kuantuma dayanıklı kriptografisi de aynı yaklaşımı kullanıyor [1].
    Birkaç yıl önce bir kuantuma dayanıklı algoritmanın klasik bir bilgisayarda kırılmasından sonra bu eğilimin ortaya çıktığını düşünüyorum [2].
    Artık saldırganın hem klasik algoritmayı hem de kuantuma dayanıklı algoritmayı kırması gerekiyor
    [0] https://blog.cloudflare.com/post-quantum-to-origins/
    [1] https://signal.org/blog/pqxdh/
    [2] https://www.quantamagazine.org/post-quantum-cryptography-sch...
  • Bildiğim kadarıyla Shor algoritması hâlâ pratik olmaktan uzak. Makul bir sürede çalıştırmak için bugün mümkün olandan çok daha fazla kübite ihtiyaç var
    Muhtemelen milyonlarca kübit gerekir; en gelişmiş cihazlar bile şu an en fazla yüzler mertebesinde. Önümüzdeki birkaç yıl, hatta belki birkaç on yıl boyunca üretim kodunda kuantuma dayanıklı algoritmalar konusunda çok endişeleneceğimi sanmıyorum
  • Şu anda genel olarak kabul gören, ancak herkesin üzerinde uzlaşmadığı standart hibrit şifreleme. KEM/DEM’deki “hibrit” anlamından farklı, ama genellikle hibrit bir KEM/DEM kriptosistemiyle birlikte kullanılıyor
    Bu yöntem, düz metne erişmek için hem klasik algoritmanın hem de kuantuma dayanıklı algoritmanın kırılmasını garanti eder. Şifrelemeyi basitçe sarmalayıp sarmalamamak mı, yoksa Campagna ve Petcher örneğindeki gibi hibrit bir KEM birleştiricisi kullanmak mı gerektiği daha incelikli bir konu; benim seviyemin üzerinde daha sofistike bir değerlendirme gerektiriyor
  • Bizim ömrümüzde kuantum bilgisayarlar daha pratik hâle gelirse, bugünün sırlarının gelecekte böyle bir analize maruz kalmaması gerekir. Kuantum bilgisayarları ölçeklendirmek, vakum tüplerinden ve transistörlerden entegre devrelere geçiş kadar basit değil; ancak uzmanların zorluk tahminleri “çok çok çok zor” ile “fiziksel olarak imkânsız kalacak” arasında değişiyor
    Her iki durumda da, modern standartlardaki şifreleme anahtarlarını kaba kuvvetle kırmaktan daha olası olduğu için bugün kuantum sonrası güvenliği önceliklendirmek için bir gerekçe var.
    Bununla birlikte dikkatli olmak gerektiği de doğru. PQ algoritmalarında yan kanal veya implementasyon açıkları varsa durum çok daha kötüleşebilir. En kötü durumda bir PQ implementasyonunda uzaktan kod çalıştırma açığı olduğunu hayal edin. Bu yüzden temkinli yaklaşmak ve kodu sıkı biçimde incelemek iyi olur
  • Kuantuma dayanıklı kriptografi ile mevcut kriptografiyi birlikte kullanıp, ikisinden biri kırılsa bile birleşimin tamamı çökmeyecek şekilde tasarlanan yaklaşımlarda pratik bir risk yok
    Anahtar değişimi tarafında bu oldukça kolay; yönteme göre çıktı değerlerini XOR’lamak ya da uç uca eklemek yeterli

• README’de Bouncy Castle bağımlılığından bahsediliyor; BC’de zaten Java tabanlı birkaç PQC imza yöntemi bulunuyor. https://doc.primekey.com/bouncycastle/interoperability#Inter... ve https://github.com/bcgit/bc-java adreslerine bakabilirsiniz

• Birkaç gün önce Daniel Bernstein, NSA’nın kusurlu kuantum sonrası kriptografi implementasyonları yaymaya çalıştığı konusunda uyarıda bulundu. Bağlantıyı bulamıyorum

  • Bahsettiğin yazı burada. Ancak Dilithium değil, Kyber hakkında
    https://news.ycombinator.com/item?id=37756656

• Başka bir kuantum sonrası imza yöntemi olan sphincs+ için yazdığım/taşıdığım tek dosyalık Java implementasyonu burada
  https://github.com/Peergos/sphincsplus

• “RSA ve ECC kriptografi algoritmalarının, Shor algoritmasını kullanan kuantum bilgisayar saldırılarına karşı savunmasız olduğu uzun zamandır biliniyor.”
  Bu doğruysa ve bu ölçekte bir kuantum bilgisayar gerçekten ortaya çıkarsa Bitcoin üzerinde nasıl bir etkisi olur merak ediyorum

  • Sorun hâline gelmeden önce geçiş yapılır. Gerçekten gerçekleşse bile, bilinen ilk saldırı noktasında kuantuma dayanıklı kriptografi eklenerek fork yapılabilir

• “Bu, birkaç gün içinde eğlence için yazılmış bir implementasyondur. Üretim seviyesinde kod olması amaçlanmamıştır. Herhangi bir garanti veya destek sunulmaz. Ancak kuantum sonrası algoritmaları incelemek ve denemek için faydalı olabilir. Kendi sorumluluğunuzda kullanın. Bu şart hoşunuza gitmiyorsa bu yazılımı kullanmamalısınız”