- libsodium'un düşük seviyeli
crypto_core_ed25519_is_valid_point() fonksiyonunda, Edwards25519 eğrisinde uygunsuz nokta doğrulama hatası tespit edildi
- Bu fonksiyonun bir noktanın ana kriptografik gruba ait olup olmadığını doğrulaması gerekirken, karma mertebeli (subgroup) bazı noktaları yanlışlıkla geçirdiği belirlendi
- Sorunun nedeni, dahili koordinat doğrulamasında yalnızca X=0'ın kontrol edilmesi ve Y=Z doğrulamasının atlanması olan bir kod hatasıydı; bu da hatalı noktaların geçerli sayılmasına yol açabiliyordu
- Düzeltilen sürümde her iki koşul da (X=0, Y=Z) kontrol edilecek şekilde değiştirildi; 1.0.20 ve altı sürümler veya 30 Aralık 2025'ten önceki sürümler etkileniyor
- Yüksek seviyeli API (
crypto_sign_*) etkilenmiyor ve güvenlik ile performans açısından Ristretto255 grubu kullanımı öneriliyor
libsodium projesine genel bakış
- libsodium, 13 yıl önce başlamış bir proje ve amacı kriptografiyi kullanımı kolay, basit bir API ile sunmak
- Kullanıcının dahili algoritmaları bilmesine gerek kalmadan yalnızca yüksek seviyeli işlemleri gerçekleştirebilmesi için tasarlandı
- API'nin geriye dönük uyumluluğunu korumaya önem veriyor ve NaCl API temelinde bugüne kadar tutarlılığını sürdürdü
- Bazı kullanıcıların belgelerde belirtilen sınırların ötesine geçip düşük seviyeli fonksiyonları doğrudan kullanmasıyla, kütüphanenin bir kriptografi araç takımı gibi kullanıldığı örnekler arttı
Bulunan hatanın nedeni
- Sorunlu fonksiyon:
crypto_core_ed25519_is_valid_point()
- Edwards25519 eğrisinde ana gruba (L mertebesi) ait olmayan noktaları reddetmesi gerekiyor
- Ancak karma mertebeli (2L, 4L, 8L vb.) bazı noktalar doğrulamayı geçebiliyor
- İçeride, noktanın mertebesini kontrol etmek için L ile çarpım yapıldıktan sonra sonucun birim eleman (identity) olup olmadığına bakılıyor
- Birim eleman X=0, Y=Z biçiminde temsil edilir, fakat mevcut kod yalnızca X=0'ı kontrol ediyordu
- Bu nedenle Y≠Z olan hatalı noktalar geçerli kabul edilebiliyordu
- Örnek: ana gruptaki bir Q noktasına mertebesi 2 olan (0, -1) noktası eklenerek elde edilen Q+(0, -1) hatalı bir nokta olmasına rağmen, düzeltme öncesinde doğrulamayı geçiyordu
Düzeltme içeriği
- Yama commit'i şu şekilde değiştirildi
- Eski kod:
return fe25519_iszero(pl.X);
- Düzeltilmiş kod:
fe25519_sub(t, pl.Y, pl.Z); return fe25519_iszero(pl.X) & fe25519_iszero(t);
- Artık doğru doğrulama için hem X=0 hem de Y=Z koşulları kontrol ediliyor
Etki alanı
- Aşağıdaki koşullarda etkilenme ihtimali var
- 1.0.20 ve altı sürümler veya 30 Aralık 2025'ten önceki sürümler kullanılıyorsa
- Güvenilmeyen giriş noktaları
crypto_core_ed25519_is_valid_point() ile doğrulanıyorsa
- Edwards25519 eğrisi işlemlerini doğrudan uygulayan kullanıcılar söz konusuysa
- Ancak çoğu kullanıcı etkilenmiyor
- Yüksek seviyeli API (
crypto_sign_*) bu fonksiyonu kullanmıyor
crypto_scalarmult_ed25519, hatalı açık anahtarlarda bile bilgi sızıntısına yol açmıyorcrypto_sign_keypair ve crypto_sign_seed_keypair ile üretilen anahtarlar doğru gruba ait oluyor
Önerilen önlemler
- Ristretto255 grubu kullanılması öneriliyor
- 2019'dan beri libsodium'a dahil ve cofactor ile ilgili sorunları çözüyor
- Decode edilen noktalar otomatik olarak güvenli olduğundan ek doğrulama gerekmiyor
- Edwards25519'dan daha hızlı işlem performansı sunuyor
- Güncelleme mümkün değilse, önerilen uygulama seviyesi alternatif fonksiyon (
is_on_main_subgroup) ile doğrulama yapılabilir
Düzeltilmiş dağıtımlar ve destek
- Sorun fark edilir edilmez hemen düzeltildi ve 30 Aralık 2025'ten sonra dağıtılan tüm kararlı sürümlere dahil edildi
- Resmî tarball, Visual Studio/MingW ikili dosyaları, NuGet paketi, Android yapıları,
swift-sodium xcframework, Rust libsodium-sys-stable, libsodium.js dahil
- Yeni bir point release de planlanıyor
- Proje tek kişilik bakım ile yürütülüyor; sürekli iyileştirmelere OpenCollective desteği üzerinden katkı sağlanabiliyor
1 yorum
Hacker News yorumları
PHP kütüphanesi sodium_compat da bu sorundan etkilenmiş
İlgili ayrıntılar security-advisories PR #756 içinde görülebilir
Bu akşam ayrıca açık kaynak ekosistemindeki diğer Ed25519 implementasyonlarının tamamını kontrol edip aynı doğrulama eksikliğinin bulunup bulunmadığına bakmayı planlıyorum
Ancak yukarıda bahsedilen zafiyette olduğu gibi yanlış şekilde uygulanmış örnekler yoktu
Eğer e-posta göndermediysem, muhtemelen ya ianix'in Ed25519 dağıtım listesinde yoktur, ya gözümden kaçmıştır ya da güvenli bir implementasyondur
Son 4 aydır Lean4 için sodium binding'leri geliştiriyorum
Artık Ristretto255 aşamasına geldim ve yazarın bu teknolojiye neden heyecan duyduğunu anlamaya başladım
Ristretto, Curve25519 üzerinde rastgele polinomlar kurabilen sofistike bir API ve onunla denemeler yapmak gerçekten çok eğlenceli
Yazar bunu görürse içten teşekkürlerimi iletmek isterim
Libsodium'ın amacı düşük seviyeli fonksiyonlar değil, yüksek seviyeli bir API sunmaktı
Kullanıcıların iç algoritmaları bilmesine gerek kalmayacak şekilde tasarlanmıştı, ancak zamanla düşük seviyeli fonksiyonların doğrudan kullanıldığı örnekler giderek arttı
Sonuçta Libsodium bir algoritma araç takımı gibi kullanılmaya başlandı
Önemli olan, kullanıcıların ne istediğini fark etmek ve projeyi onlara belli bir şekilde dayatmamak
Bazı projeler bu noktada dogmatikleşip başarısız oluyor
Uzman olmayanların kriptografik ilkel fonksiyonları doğrudan kullanması tehlikelidir
Libsodium, kullanıcıların kendilerini tehlikeye atmaması için tasarlanmıştı
İdeal olan, kütüphanenin yanlış kullanımın imkansız olmasını sağlamasıdır
Bununla ilgili olarak “If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong” yazısını öneririm
Bu yüzden bazı özellikleri private veya internal ile sınırlamak çoğu zaman doğru tercihtir
Libsodium'ın bu sınırı iyi çizip çizmediğinden emin değilim ama denge önemlidir
Ama bazı kullanıcılar bunu bir batch runner gibi kullanıyordu
Onların ihtiyaçlarını desteklemek için birkaç hata düzelttim
Sonuçta kullanıcıların olması bile beni mutlu etmişti
Bu hata ince ama önemli bir kriptografik doğrulama hatası
“Geçerli mi diye kontrol etme” gibi basit görünen bir denetim aslında çok karmaşıktır
Asal dereceli alt grup dışındaki noktaları kabul etmek, anında bir zafiyet yaratmıyor gibi görünse bile üst katman varsayımlarını bozabilir
Ayrıca düşük seviyeli ilkel fonksiyonlar amaçlanandan çok daha geniş biçimde yeniden kullanılır; bu yüzden küçük bir doğrulama eksiği büyük bir etkiye yol açabilir
Alt grup sorunu yalnızca Curve25519 üzerinde daha karmaşık protokoller kurduğunuzda ortaya çıkar
Bu yüzden mümkün olduğunca tüm noktaları asal dereceli alt gruba yeniden eşliyorum
Monocypher bu tür gelişmiş fonksiyonlara sahip
Örneğin
crypto_x25519_dirty_fast()veyacrypto_elligator_map()gibi fonksiyonlar varBu tür “dirty” fonksiyonlar, tüm eğriyi kapsayan ve rastgelelikten ayırt edilemeyen açık anahtarlar üretir
Sonrasında X25519 anahtar değişiminde de aynı paylaşılan sırrı elde edebilirsiniz
Bu, DJB'nin tasarımı sayesinde mümkündür; çünkü açık anahtar anormal olsa bile paylaşılan sır asal dereceli alt gruba eşlenir
Sonuç olarak Ristretto'ya yalnızca bu yeniden eşlemenin mümkün olmadığı durumlarda ihtiyaç vardır
Elbette asal dereceli grup soyutlaması faydalıdır, ancak böyle protokoller tasarlayabilecek biri trivial olmayan cofactor ile başa çıkabilmelidir
Büyük bir şirkette çalışıyorsanız, Frank için şirket düzeyinde sponsorluk düşünmenizi öneririm
Bilsem bile muhtemelen şirket hesabından değil kendi cebimden destek vermem gerekirdi
libnacl da etkileniyor mu merak ediyorum
Ben her gün libnacl ile derlenmiş yazılımlar kullanıyorum ama “libsodium” ile derlenmiş olanları kullanmıyorum
Gerçekten harika bir kütüphane
Frank Denis'e teşekkürler