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, üst seviye şifreleme API'lerinde nonce yönetimini daha az riskli hale getirmek için 256 bit anahtar ve 192 bit nonce kullanan yeni bir AEAD belirtimidir
  • Büyük nonce, her mesaj için işletim sistemi CSPRNG'sinden otomatik olarak yeni bir değer üretme yaklaşımını mümkün kılar ve 2⁸⁰ mesajda çakışma riskini 2⁻³² seviyesinde hedefler
  • İçeride, giriş anahtarı ve büyük nonce'tan türetilmiş bir anahtar ile 96 bit nonce üretildikten sonra standart AES-256-GCM aynen kullanılır; bu bir genişletilmiş nonce yapısıdır
  • Go referans uygulaması yalnızca crypto/cipher ve crypto/aes ile 100 satırın altına sığar; mesaj başına yapılan 3 adet AES-256 çağrısının bir kısmı önceden hesaplanabilir
  • FIPS 140 uyumluluğu ve kütüphane uyumluluğunu önemseyerek, XChaCha20Poly1305 ve AES-GCM-SIV ile birlikte nonce'suz AEAD API adayı olarak kullanılabilir

Üst seviye API'ler için büyük nonce AEAD

  • XAES-256-GCM, ek kimlik doğrulama verisine sahip kimlik doğrulamalı şifreleme (AEAD) algoritmasıdır ve 256 bit anahtar ile 192 bit nonce kullanır
  • Tasarım hedefleri üç başlıkta özetlenir
    • Pratikte sınırsıza yakın sayıda mesajda bile rastgele üretimi güvenli olan büyük nonce desteği
    • Tam ve doğrudan FIPS 140 uyumluluğu
    • Yaygın kriptografi kütüphaneleri üzerinde kolay uygulama
  • Büyük nonce sayesinde, kullanıcının birthday bound hesabını bizzat yapmasına gerek kalmadan her mesaj için işletim sistemi CSPRNG'sinden yeni bir nonce okuyan API'ler oluşturulabilir
  • Uyumluluk ve birlikte çalışabilirlik önceliklidir; bu sayede diğer büyük nonce AEAD'lerinin kullanılamadığı ortamlarda da AEAD gereken yerlere uygulanabilir

AES-256-GCM'i aynen kullanan genişletilmiş nonce yapısı

  • XAES-256-GCM, XChaCha20Poly1305 gibi mevcut bir AEAD'in üzerine kurulan bir genişletilmiş nonce yapısıdır
  • Giriş anahtarı ve 192 bit nonce'tan, dahili AES-256-GCM için türetilmiş anahtar ve türetilmiş nonce hesaplanır
    • Giriş anahtarı ve nonce sırasıyla K, N
    • Türetilmiş AES-256-GCM anahtarı ve nonce ise Kₓ, Nₓ
  • AES-256ₖ çağrıları ve nonce'un ön kısmı kullanılarak Kₓ üretilir; giriş nonce'unun son 96 biti Nₓ olarak kullanılır
  • Mesaj başına 3 adet AES-256ₖ çağrısı gerekir
    • Bunlardan biri, verilen anahtar için önceden hesaplanabilir
    • Kalan iki çağrı aynı anahtar zamanlamasını yeniden kullanabilir

Uygulama kısa ve standart bileşenlerle ifade edilebilir

  • Go referans uygulaması, ön hesaplama optimizasyonu ve boilerplate kodun çoğu dahil olmak üzere 100 satırın altındadır
  • Go uygulaması yalnızca standart kütüphanedeki crypto/cipher ve crypto/aes paketlerini kullanır
  • XAES-256-GCM, standart NIST SP 800-108r1 KDF ve standart NIST AES-256-GCM AEAD ile de ifade edilebilir
    • KDF, counter-based KDF'dir
    • PRF, CMAC-AES256'dır
    • Giriş anahtarı Kin'dir
    • Etiket, ASCII X karakteri yani 0x58'dir
    • Bağlam, giriş nonce'unun ilk 96 bitidir
    • Sayaç boyutu 16 bittir
    • İsteğe bağlı L alanı atlanır
    • Çıktı, 256 bit türetilmiş anahtardır
  • Türetilmiş anahtar ile giriş nonce'unun son 96 biti AES-256-GCM'e verilir
  • Parametre seçimi sayesinde, KDF ve CMAC soyutlamaları kaldırıldığında, yalnızca sayaç üzerinde AES-256 çağıran bir yaklaşımdan biraz daha yavaş ve biraz daha karmaşıktır
  • Aynı parametreler üst seviye OpenSSL API tarafından da desteklenir

Üçüncü taraf uygulamalar ve test vektörleri

/11'den vazgeçiş ve alternatifler

  • Önceki taslakta XAES-256-GCM/11 adı vardı, ancak nihai belirtimde /11 kaldırıldı
  • /11 bir performans optimizasyonuydu; AES-GCM kullanma nedenlerinden biri FIPS 140 uyumluluğu olduğundan, tur sayısını değiştirmek bu uyumluluğu ortadan kaldırır
  • FIPS 140 uyumluluğu hedef değilse çeşitli alternatifler vardır
    • AES-GCM-SIV
    • AES çekirdeği tabanlı modern AEAD yapıları
  • Belirtimdeki Alternatives bölümü, her alternatifi XAES-256-GCM ile karşılaştırır

Go ve nonce'suz AEAD API içindeki konumu

  • XAES-256-GCM; güvenli, sıkıcı, uyumlu ve birlikte çalışabilir bir AEAD olmayı hedefler
  • Başlıca kullanım alanı, Go'ya eklenmesi istenen türden bir üst seviye API'dir
  • XAES-256-GCM, XChaCha20Poly1305 ve AES-GCM-SIV'i tamamlar; varsayımsal bir nonce'suz AEAD API için uygulama adayı olarak tasarlanmıştır
  • Go standart kütüphanesine Go'ya özgü bir yapı eklemek tercih edilmediğinden, diğer kriptografi kütüphanesi bakımcılarının görüşleri gereklidir

İlgili okumalar

1 yorum

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

  • Tasarım oldukça zekice: CMAC tabanlı olduğu için alt seviye yapı taşları olmasa bile AES-CBC ile anahtar türetilebiliyor
    AES-CBC açısından bakıldığında bu, L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16] ile başlayıp K1 oluşturma, ardından M1 ve M2 şifrelenerek Kₓ elde edilmesi ve Nₓ = N[12:] kullanılması şeklinde görülebilir
    AES-CBC-256'nın yalnızca şifreli metnin ilk 128 bitlik bloğunu döndürdüğü ve padding bloğunu attığı varsayılabilir; padding kapatılamasa bile alt seviye bir uygulamaya kıyasla aynı anahtarla sadece 3 ek AES çağrısı gerektirmesi fena değil
    Bu özelliği kullanan WebCrypto API tabanlı JS uygulaması https://github.com/dchest/xaes adresinde bulunuyor; AES-CBC için CryptoKey nesnesini doğrudan kabul ediyor ve extractable=false ile IndexedDB'ye kaydetme gibi CryptoKey özelliklerini de destekliyor

    • Bu alanda standart gösterim gibi görünüyor ama dürüst olmak gerekirse kriptografi notasyonundan nefret ediyorum
      O sözde kodda sayıların yarısı bayt sayısını, diğer yarısı bit sayısını ifade ediyor gibi duruyor ve algoritmayı zaten bilmiyorsanız hangisinin hangisi olduğunu anlamak neredeyse imkânsız
      Örneğin N[:12] 12 bayt gibi görünüyor ama 0¹²⁸ 16 bayt, ayrıca X gerçekten 'X' karakteri yani 01011000 bit dizisi iken L, 01001100 bit dizisi değil bir değişken
      Matematikçilerin, bilgisayar bilimciler kadar belirsiz olmayan gösterimi sevmediği açıkça görülüyor
    • 0¹²⁰10000111 gibi ürkütücü görünen sabitler, CMAC'in kullandığı alttaki blok şifresinin blok boyutu b için derecesi b olan indirgenemez polinomlar arasında sıfır olmayan terim sayısı en az olanlardan sözlük sırasına göre ilk olanın katsayılarını gösteren bit dizisidir
      Bunun arkasında gizli bir niyet yok
    • Kripto tarafında uzman değilim ama özetle standart AES-GCM AEAD, aynı nonce farklı mesajlarda iki kez kullanılırsa felaket şekilde bozuluyor[1] ve nonce boyutu da çoğu durumda rastgele nonce'u güvenle kullanmak için küçük kalıyor diye anlıyorum
      Bu çalışma, her AES-GCM çağrısında yalnızca nonce'u değil anahtarı da değiştirerek bu sorunu kolayca aşmayı sağlıyor
      Ayrıca AES-GCM varsa genelde kullanılabilen “sıradan” AES'i kullanıyor ve henüz zayıflıkları olabilir diye bilinmeyen yeni karmaşık yapılardan kaçınıyor
      Mesaj başına ek yük, “sıradan” AES ile şifrelenmesi/çözülmesi gereken iki küçük tampon ve daha uzun 192 bitlik bir nonce kadar
      [1]: https://frereit.de/aes_gcm/

  • Rastgele nonce kullanırken saf AES-GCM'de görülen, yaklaşık her 2^32 mesajda bir anahtar değiştirme tuzağını ortadan kaldırıyor gibi görünüyor
    AES-GCM'de nonce çakışması felakettir ve en azından saldırganın keyfi mesajlar için imza üretebilmesine yol açar
    Rastgele nonce kullanmak zorunlu değil ama genelde tavsiye edilir; karşı tabanlı bir anahtar türetme işlevi ile saf GCM olmak üzere iki temel yapı taşını kullanıp bunu FIPS uyumlu hale getirmesi oldukça zekice

    • Daha doğrusu bu yöntem en başta rastgele nonce kullanımını güvenli hale getiriyor
      Standart AES-GCM'de 96 bit, rastgele çakışmaları önlemek için yeterli değil; bu yüzden belirlenimsel nonce üretimi kullanılmalı
      Ayrıca nonce nasıl üretilirse üretilsin sayaç taşacağı için sonraki blok ilk blokla aynı nonce+sayaç değerini kullanır; dolayısıyla 2^32 bloktan sonra nonce ya da anahtar değiştirilmelidir

  • Gerçekten müthiş. Birkaç yıl önce son kez şifreli bir dosya sistemi yaparken bunun olmasını isterdim
    Büyük ölçekli dosya sistemi dağıtımlarında nonce çakışması büyük bir endişe kaynağı
    2^32 büyük görünüyor olabilir ama PB ölçeğindeki dizilerde saniyede 100k IOPS yazarken sözde rastgele sayı üretecinin rastgeleliğine güveniyorsanız çakışma ihtimali neredeyse garanti seviyesine geliyor

    • CAESAR yarışması[1] 2019'da sona erdi ve sonuç olarak yeterince geniş nonce alanına sahip çeşitli AEAD'ler ortaya çıktı
      [1] https://en.m.wikipedia.org/wiki/CAESAR_Competition
    • Ama neden nonce çakışmasının sorun olduğunu merak ediyorum
      Bu sadece iki bloğun aynı şifreleme anahtarını paylaştığı anlamına gelmiyor mu?
      Hiçbir bloğun düz metni bilinmiyorsa bunun sistem güvenliğini nasıl zayıflattığını anlamıyorum

  • Arşiv amaçlı dosya şifreleme için FIPS uyumlu bir age türevinde bunun kullanılması güzel olurdu
    Bankacılık denetiminde age, ChaCha kullandığı için bu kullanım amacı açısından reddedildi; age'in X25519 açık anahtar kısmı ise kabul edilebilir görülmüştü. X25519'un görece yakın zamanda NIST onayı aldığını sanıyordum
    Go deneyimim yok ama age belirtimine bakınca bunu doğrudan takıp çalıştırmak mümkün gibi görünüyor; zaman bulursam deneyebilirim
    Adı da “compliant actually good encryption” anlamında “cage” olabilir
    1: https://github.com/FiloSottile/age

    • “compliant actually good encryption” belki de bir oksimoron olabilir
    • Kontrol ettim; Ed25519 onaylı gibi görünüyor (FIPS 186-5) ama X25519 henüz değil gibi
    • Bu arada Go standart kütüphanesinde henüz bir XAES uygulaması yok; yalnızca C2SP'nin referans uygulaması mevcut
    • bge, bureaucratic good encryption

  • Kriptograf olmayan biri olarak merak ediyorum: neden 192 bit nonce kullanılıyor da 256 bit değil?
    Pratik uygulamalarda bu ek bitlerin bir maliyet unsuru sayılacağını sanmıyorum

    • 256 bit koyacak yer yok. 192 bit; alt nonce alanından gelen 96 bit ile gerekli önekle birlikte 128 bitlik CMAC bloğuna sığan 96 bitten oluşuyor
      CMAC girdisini daha uzun yapmak mümkün ama bu durumda AES-256 blok fonksiyonunu daha fazla kez çalıştırmak gerekir ve CMAC anahtar türetme işlevinde can sıkıcı anahtar kontrolü sorunları da ortaya çıkar
      Bu, XChaCha20Poly1305'in 192 bit nonce kullanma gerekçesine de benziyor; diğer önemli genişletilmiş nonce AEAD'lerle tutarlı olması da küçük bir artı

  • “2⁸⁰ mesajda çakışma riski 2⁻³²” denmiş ama AES blok boyutunun yalnızca 128 bit olması nedeniyle daha önce sorun çıkmaz mı?

    • Eğer bloklar için doğum günü sınırından (https://sweet32.info) söz ediyorsanız, bu tek bir anahtarla şifrelenen blok sayısına ilişkin bir sınırdır
      XAES, her mesaj için büyük bir anahtar türettiği için genelde doğum günü sınırından daha iyi güvence denilen şeyi elde eder
    • Hayır
      Bunun neden sorun olacağını düşündüğünüze dair daha fazla bağlam olmadan bundan daha ayrıntılı yanıt vermek zor

  • “Güvenli, sıkıcı, uyumlu ve birlikte çalışabilir”
    En sevdiğim teknoloji türü bu

  • Güzel. Gerçekten NIST tabanlı bir yapı olması sevindirici
    Ancak NIST anahtar türetme işlevinin etiket ve bağlam gibi avantajlı özelliklerinden birkaçından vazgeçilmesi biraz üzücü
    AES çağrılarının sayısını en aza indirmek için bunun feda edildiğini anlıyorum ama özellikle birkaç yüz bayttan uzun mesajlarda birkaç AES çağrısı tasarruf etmektense daha güçlü kriptografik ayrımı tercih ederdim
    Son olarak, 96 bitten uzun rastgele GCM nonce'larının kesinlikle çok yanlış anlaşıldığını ve 96 bit nonce'lardan daha iyi güvenceler sunduğunu da belirtmek gerekir[1]
    Elbette mesaj başına yeni bir anahtar türetilebiliyorsa bu açıkça daha iyi
    [1] https://neilmadden.blog/2024/05/23/galois-counter-mode-and-r...