XAES-256-GCM genişletilmiş nonce AEAD

 (words.filippo.io)
1 puan yazan GN⁺ 2024-06-30 | 1 yorum | WhatsApp'ta paylaş

XAES-256-GCM'e giriş

  • XAES-256-GCM, 256 bit anahtar ve 192 bit nonce kullanan kimlik doğrulamalı bir şifreleme algoritmasıdır (AEAD)
  • Başlıca hedefler:
    • Rastgele üretilen nonce'ları güvenli biçimde desteklemek
    • FIPS 140 uyumluluğu
    • Yaygın şifreleme kütüphanelerinde kolayca uygulanabilmek

XAES-256-GCM'in tasarım hedefleri

  • Büyük nonce kullanarak sınırsız sayıda mesaj için güvenli şekilde rastgele üretim yapılabilmesi
  • FIPS 140 uyumluluğu sayesinde çeşitli ortamlarda kullanılabilmesi
  • Basit uygulama ile kullanıcı üzerindeki yükü azaltmak

XAES-256-GCM'in çalışma prensibi

  • AES-256-GCM'i temel alan genişletilmiş bir nonce yapısı kullanır
  • Girdi anahtarı ve nonce kullanılarak türetilmiş anahtar hesaplanır
  • Mesajı işlemek için üç AES-256 çağrısı yapılır

Uygulama ve optimizasyon

  • Go referans uygulaması 100 satırdan az koddan oluşur
  • Yalnızca standart kütüphanedeki crypto/cipher ve crypto/aes kullanılır
  • NIST SP 800-108r1 KDF ve NIST AES-256-GCM AEAD kullanılarak açıklanabilir

Üçüncü taraf uygulamalar ve uyumluluk

  • .NET 8+, pyca/cryptography ve Web Cryptography API üzerinde üçüncü taraf uygulamalar bulunur
  • FIPS 140 uyumluluğu için round sayısı değiştirilemez

Alternatifler ve test vektörleri

  • AES-GCM-SIV gibi çeşitli alternatifler mevcuttur
  • Ana kod yolları için test vektörleri içerir

Özet

  • XAES-256-GCM, güvenli, uyumlu ve birlikte çalışabilir bir AEAD olarak tasarlanmıştır
  • XChaCha20Poly1305 ve AES-GCM-SIV'i tamamlayıcı bir rol üstlenir
  • Go standart kütüphanesine eklenmesi umuluyor

GN⁺ görüşü

  • XAES-256-GCM'in büyük nonce kullanarak güvenliği artırması dikkat çekicidir
  • FIPS 140 uyumluluğu sayesinde çeşitli ortamlarda kullanılabilir
  • Go gibi dillerde kolayca uygulanabilmesi, geliştiriciler için faydalıdır
  • AES-GCM-SIV gibi alternatifleri de değerlendirmekte fayda vardır
  • Yeni bir teknolojiyi devreye alırken performans ve uyumluluğun dikkatle incelenmesi gerekir

İlgili okumalar

1 yorum

 
GN⁺ 2024-06-30
Hacker News görüşü

  • Tasarım çok akıllıca: CMAC tabanlı ve düşük seviye primitive'ler olmadığında anahtar türetmek için AES-CBC kullanılabiliyor

    • AES-CBC terimleriyle açıklarsak: 
      1. L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16]
2. MSB₁(L) = 0 ise, K1 = L << 1;
   aksi halde K1 = (L << 1) ⊕ 0¹²⁰10000111
3. M1 = 0x00 || 0x01 || X || 0x00 || N[:12]
4. M2 = 0x00 || 0x02 || X || 0x00 || N[:12]
5. Kₓ = AES-CBC-256ₖ(iv = K1, plaintext = M1)[:16] || AES-CBC-256ₖ(iv = K1, plaintext = M2)[:16]
6. Nₓ = N[12:]
    • AES-CBC-256 ilk 128 bitlik bloğu döndürür ve padding uygulanmış blok atılır
    • Anahtar türetildikten sonra standart AES-GCM ile birlikte kullanılır
    • WebCrypto API tabanlı JS uygulama örneği: GitHub bağlantısı
    • AES-CBC için amaçlanan uygun bir CryptoKey'i kabul eder ve IndexedDB'de saklanabilir

  • Filippo'nun işi harika: rastgele nonce kullanıldığında her yaklaşık 2^32 mesajda bir anahtarı döndürme sorununu çözüyor

    • AES-GCM'de nonce çakışması ölümcüldür (saldırganın keyfi mesajları imzalamasına olanak tanır)
    • Rastgele nonce kullanmak zorunlu değil ama genel olarak tavsiye ediliyor
    • Bunu FIPS uyumlu hale getirmek için iki primitive'in (sayaç tabanlı KDF ve normal GCM) kullanılmış olması çok akıllıca

  • Bu keşke birkaç yıl önce bir şifreli dosya sistemi yazarken var olsaydı

    • Nonce çakışmaları büyük ölçekli dosya sistemi dağıtımlarında büyük bir sorun
    • 2^32 büyük görünüyor ama saniyede 100k IOPS yazan PB dizilerinde, PRNG rastgeleliğine güveniliyorsa çakışma olasılığı neredeyse garantili

  • Bunun, arşiv dosyası şifreleme amacıyla age'in FIPS uyumlu bir varyantında[1] kullanılmasını umuyorum

    • Bankacılık sektörü denetçileri, ChaCha yerine AES kullanılmadığı için age'e karşı çıkmıştı (X25519 açık anahtar kısmı yakın zamanda NIST tarafından onaylandı)
    • Golang deneyimim yok ama age spesifikasyonuna göre kolayca uygulanabilir gibi görünüyor
    • Zamanım olursa deneyeceğim
    • Buna "cage" diyeceğim ("compliant actually good encryption" kısaltması)

  • Kriptograf olmayan biri olarak soruyorum: neden 256 bit yerine 192 bit nonce kullanılıyor?

    • Pratik uygulamalarda ek bitlerin maliyetli olacağını sanmıyorum

  • (2⁸⁰ mesajda çakışma riski 2⁻³²)

    • AES blok boyutu 128 bit olduğu için bundan önce sorun çıkıp çıkmayacağını merak ediyorum