Yapay zeka denetim hattımızı Cloudflare'in CIRCL deneysel kriptografi kütüphanesine yönlendirdik ve eşik RSA'daki kritik float64 hassasiyet kaybından nitelik tabanlı şifrelemede tam erişim kontrolü kesintisine kadar yedi gerçek hatayı doğruladık. Artık yedisi de yukarı yönde sabitlendi. Bu, temsilcilerimizin açık kaynak şifrelemede bulduğu hatalar hakkındaki serinin ilk yazısıdır.
zkSecurity olarak bir yapay zeka denetim aracısı olan zkao'yu geliştiriyoruz. Hedefi belirtmesi basit, yapması ise zordur: Diğer yapay zeka araçlarının bulabileceği hiçbir hata kalmayıncaya kadar yapay zekanın sürekli olarak kodunuza bakmasını sağlayın. Bu yaklaşımın neden önemli olduğunu zkao: Birleştiren Güvenlik'te yazdık.
Zkao'yu oluşturmak, yapay zeka tarafından tespit edilebilecek tüm hataları bulabilecek otomatik bir denetçi oluşturma nihai hedefiyle yinelenen bir süreç oldu. Bu, yeni fikirler ve teknikler için beyin fırtınası yapmayı, zkSecurity'nin güvenlik araştırmacılarının uzmanlığını sistematik olarak zkao'ya kodlamayı, kıyaslamalara karşı önyargılı olmaksızın en yeni ve en ciddi güvenlik açıklarını tespit etmesini sağlamayı ve daha da önemlisi neyin işe yarayıp neyin yaramadığını, modellerin nasıl geliştiğini anlamak ve yapay zeka ile hata bulma anlayışımızı derinleştirmek için sürekli deneyler yapmayı içeriyordu. Bu deneylerden bazıları, üründen bağımsız olarak kendi başlarına paylaşmaya değer şeyler üretiyor ve bu yazı serisinin konusu da bu.
Teknik Analiz
İkinci bir motivasyon daha var. Bu deneyler, zkao için nasıl bir kıyaslama paketi oluşturduğumuzdur ve bu arada, Yüksek Lisans'ların kriptografi hakkında gerçekte nasıl akıl yürüttüğüne dair içgörüleri gün yüzüne çıkarmaya devam ediyorlar: nerede keskinler, nerede körler ve ilkini nasıl güçlendirip ikincisini nasıl kontrol altına alabilirler. Hatalar görünür çıktı olsa da, akıl yürütme kalıpları en çok önemsediğimiz kısımdır.
Detaylar ve Etkileri
Birkaç ay önce seçilen kod tabanları üzerinde denemeler yapmaya başladık. Birkaç açık kaynaklı kriptografi projesini iki yapılandırmada taramak için Yüksek Lisans'ı kullandık:
Gelecekte Ne Bekleniyor?
Basit bir istemle yalnızca Yüksek Lisans. Becerilerin ekibimizdeki uzmanlar tarafından korunduğu becerilere sahip LLM.
Ardından, Yüksek Lisans'ların gerçek güvenlik açıkları bulduğu önemli projeler için aynı sorunları kendi başına tespit edip edemeyeceğini görmek için zkao'yu da çalıştırdık. Çoğu durumda, zkao yalnızca hepsini bulmakla kalmadı, aynı zamanda daha karmaşık ve daha şiddetli olanları da belirledi.
Nasıl Önlem Alınmalı?
Sonuçlar yeterince iyiydi ve bunları yazmaya karar verdik. Bu seriye, gelişmiş ve kuantum sonrası kriptografi kütüphanesi olan Cloudflare'in CIRCL'si ile başlıyoruz. CIRCL'de boru hattımız birçok aday bulgu üretti ve bunlardan yedisi burada rapor edilmeye değer. Artık yedisi de yukarı yönde sabitlendi. Bunların çoğu Cloudflare'in HackerOne programı kapsamında onaylandı ve ödüllerle ödüllendirildi.
Açıklama: Yapay zeka, nihai raporları değil, aday bulguları üretti. Ekibimizdeki insanlar yine de her sorunu doğruladı, kullanılabilirliği kontrol etti, gerektiğinde POC'yi en aza indirdi ve açıklamayı gerçekleştirdi. Bu döngüdeki insan adımı hâlâ büyük önem taşıyor çünkü yapay zeka adaylarının bulguları ucuzken güvenilir raporlar ucuz. Bu adımı en aza indirmek, zkao'nun yapmak üzere tasarlandığı ana şeylerden biridir ve halen devam eden bir çalışma olmasına rağmen, mevcut sürüm zaten bu doğrulama işinin çoğunu kendisi üstlenmektedir.
Bir bakışta önem dereceleri ve düzeltmeler
Ayrıntılardan önce belirtmeye değer bir şey var: Bir yapay zekanın kendi bulgusuna verdiği önem gürültülüdür. Yapay zekanın derecelendirdiği ve Cloudflare'in düzeltildikten sonra onayladığı şekliyle her bir hatayı burada bulabilirsiniz. Ayrıca bu yedi belgenin tamamının zkao'nun mevcut sürümü tarafından tutarlı bir şekilde tekrarlanabildiğini de kontrol ettik.
Önemli Gelişmeler
AI ciddiyeti ile teyit edilen ciddiyet arasındaki farkın kendisi ilginç bir fikirdir ve sonunda buna geri döneceğiz. Şimdi yedi böcek, birer birer.
Hata 1: float64'te polinom değerlendirmesi
Uzmanların Görüşleri
Bu, CIRCL'in eşik RSA uygulamasında ( tss/rsa ) yaşıyor. Eşik imzalama, Shamir tarzı gizli paylaşımı kullanarak bir sırrı n oyuncuya böler. Deal() her oyuncunun indeksindeki gizli bir polinomu değerlendirir. Katsayılar büyük.Int olması gerektiği gibi, ancak x^i terimi şu şekilde hesaplandı:
// tss/rsa/rsa_threshold.go xi := int64 ( math . Pow ( float64 ( x ), float64 ( i )))
float64'ün 53 bitlik bir mantisi vardır. $x^i$ $2^{53}$'ı (kabaca $9 \times 10^{15}$) aştığı anda sonuç, bir tam sayıya geri dönüştürülmeden önce sessizce yuvarlanır. Örneğin, 100 oyuncu ve 27 eşik ile, $i = 26$ ile $x = 100$ olarak değerlendirmek, $100^{26} = 10^{52}$ gerektirir; bu da $2^{53}$ değerini 36 kat aşar. $x = 20$, $i = 16$ bile zaten onu bozuyor.
Sonuç şu ki, p olinom yanlış değerlendirildiğinden oyunculara verilen anahtar payları yanlıştır. Parametrelere bağlı olarak, imza kombinasyonu ya tamamen başarısız olur ya da iyi görünen ancak amaçlanan anahtarı yeniden oluşturmayan paylaşımlar üretir. Temsilcimiz bunu kritik olarak işaretledi, çünkü bu durum yanlış anahtar paylaşımlarının oluşmasına neden olarak protokolün doğruluğunu tehlikeye atıyor. Cloudflare sonuçta, etkilenen koşulların pratikte ortaya çıkma olasılığının düşük olmasına dayanarak sorunu Düşük önem derecesi olarak değerlendirdi.
Düzeltme, kayan nokta üssünü, kodun kendi TODO yorumunun başından beri önerdiği Horner yöntemi değerlendirmesiyle değiştiriyor ve her şeyi big.Int içinde tutuyor. f7d2180 komutunu verin.
Hata 2: Kanıtlayıcı tarafından kontrol edilen bir güvenlik parametresi aracılığıyla DLEQ korumalı sahtecilik
Sonuç ve Değerlendirme
Bu, $(\mathbb{Z}/n\mathbb{Z})^*$ içindeki karelerin alt grubu için CIRCL'nin DLEQ (ayrık-log-eşitlik) kanıtı olan zk/qndleq dosyasındadır. Bir DLEQ kanıtı, iki çiftin aynı ayrık günlüğü paylaştığını doğrular; Eğer bir saldırgan, doğrulayıcının yanlış bir beyan için bir kanıtı kabul etmesini sağlayabilirse, kanıt sistemi bozulur.
Bu kanıttaki zorluk Fiat-Shamir stilinden türetilmiştir ve bit uzunluğu bir SecParam tarafından yönetilmektedir. Sorun SecParam'ın Proof yapısının içinde yaşamasıydı:
Sistem Güvenliği
type Proof struct {Z, C*big. Int SecParam uint }
Doğrulama sırasında kod, kanıtın kendi SecParam'ını kullanarak sorunu yeniden hesapladı. O alan saldırganın kontrolündedir. SecParam = 1'i ayarlayın ve zorluk, $0$ veya $1$ değerindeki tek bir bit'e (sahtecilik girişimi başına yazı-tura) düşer. SecParam = 8'i ayarlayın ve kaba kuvvet yaklaşık 2^8 = 256$ denemedir. Her iki durumda da sağlamlık gitti.
Bu yinelenen bir modelin temiz bir örneğidir: kanıtlayıcı tarafından sağlanan verilerden okunmak yerine doğrulayıcı tarafından düzeltilmesi gereken bir güvenlik parametresi. Düzeltme, SecParam'ı kanıttan kaldırır ve Verify'ın bunu açık bir argüman olarak almasını sağlar, böylece doğrulayıcı bunu ayarlar. 757dde4'ü taahhüt edin.
Hata 3: Mesaj farklılığı olmadan BLS toplu doğrulaması
Bu, yapay zekanın küçümsediği gruptaki tek hatadır. Temsilci bunu orta olarak etiketledi. Aslında bu, yaygın olarak bilinen bir kritik sınıf kusuru olan, ders kitabına uygun bir hileli anahtar saldırısıdır; biz bunun kritik olduğunu bildirdik ve Cloudflare bunun yüksek olduğunu doğruladı.
Sign/bls'deki VerifyAggregate, BLS BASIC toplama modunu uygular. Bu mod yalnızca gruptaki tüm mesajların farklı olması durumunda güvenlidir; bu, hileli anahtar saldırılarına karşı savunmasıdır. İşlev, toplam eşleştirme denklemini kontrol etti ancak mesajların farklı olup olmadığını hiçbir zaman kontrol etmedi ve bu kritik gereksinimi arayana bıraktı.
Bu olmadan standart hileli anahtar saldırısı geçerlidir. Bir kurbanın genel anahtarını $\mathsf{pk__v$ ve bir $m$ mesajını gören bir düşman, $\mathsf{pk__a = g^{\mathsf{sk} - \mathsf{pk__v$ kaydedebilir ve kurbanın sırrını hiç bilmeden $(\mathsf{pk__v, m)$ ve $(\mathsf{pk__a, m)$ üzerinde toplu bir imza oluşturabilir anahtar. CIRCL, başvurulacak hiçbir mülkiyet kanıtı altyapısı sunmuyor, bu da eksik kontrolü daha tehlikeli hale getiriyor.
Yapay zeka neden bu ortamı çağırdı? Bilmiyoruz. Gerekçesini okuduğunda, eksik farklılık kontrolünü doğru bir şekilde tespit etti ve hatta hileli anahtar saldırısına isim verdi, ancak daha sonra BASIC modunun sözleşmesinin arayan kişiye farklılık gereksinimi getirdiği gerçeğine dayandı. "Arayanın bunu halletmesi gerekiyor" ifadesini bir hafifletici önlem olarak değerlendirdi ve ciddiyeti düşürdü.
Düzeltme, VerifyAggregate'in yinelenen iletilerle oluşturulan toplu işlemleri reddetmesine neden oluyor. 9798df7'yi taahhüt edin.
Hata 4: FillBytes işaret çarpışması yoluyla DLEQ sağlamlığının bozulması
Gruptaki en incelikli ve açıkçası en ilginç hata için zk/qndleq'e geri dönelim. Kanıta dokunmayı kesinlikle gerektirmez.
$S_1 = (g, g_x, h, h_x)$ ifadesi için $\log_g(g_x) = \log_h(h_x) = x$ olduğunu doğrulayan dürüst ve geçerli bir pi kanıtı alın. $x$ bilmeyen bir saldırgan, doğrulayıcıya aynı pi'yi sunar, ancak onu farklı bir ifadeyle eşleştirir: $S_2 = (g, -g_x, h, h_x)$, burada $-g_x$ negatif big.Int new(big.Int).Neg(gx)'dir.
Sahte ifade, $c$ meydan okumasının çift olduğu durumlarda kabul edilir, çünkü iki şey aynı anda sıralanır.
Cebirsel iptal. Doğrulayıcı, değerini $-g_x$'dan yeniden hesaplar ve işaret doğrudan çarpanlara ayrılır:
$$(-g_x)^c \bmod N = (N - g_x)^c \bmod N = (-1)^c \cdot g_x^c \bmod N.$$
$c$ çift olduğunda, $(-1)^c = 1$ olur, dolayısıyla doğrulayıcı, dürüst kanıtlayıcının yaptığı ara değerlerin aynısını yeniden oluşturur.
Karmada bir işaret çarpışması. Zorluk, ifadenin karma hale getirilmesiyle elde edilir ve karma, Fil'i kullanır. lBytes big.Int öğesinin mutlak değerini yazar ve işareti çıkarır. Yani doChallenge(..., -gx, ...) ve doChallenge(..., gx, ...) aynı şeye hash edilir.
Burada, $c$ muhtemelen en az $1/2$'dır (bu, hash çıktısının yalnızca düşük kısmıdır), dolayısıyla saldırı, dürüstçe oluşturulmuş tüm kanıtların kabaca yarısında başarılı olur. Doğrulayıcı $\log_g(-g_x) = \log_h(h_x)$ olduğuna ikna olmuş durumda ve bu yanlıştır. İşte kavram kanıtlamanın özü:
// (g, gx, h, hx) için dürüst kanıt, eşit zorlukla karşılaşacak şekilde seçildi c gxNeg := new ( big . Int ). Neg ( gx ) // -gx, saldırganın x forgedAccepted := kanıt bilgisine ihtiyacı yoktur. Doğrulayın ( g , gxNeg , h , hx , N ) // kabul edildi!
Bunu öne çıkaran şey tek bir özensiz çizgi olmaması. Bu, cebirsel bir kimlik ($(-1)^{\text{even}} = 1$) ile masum görünen bir serileştirme seçeneği (FillBytes işaretini bırakarak) arasındaki etkileşimdir. Hiçbiri tek başına yanlış değildir. Birlikte sağlamlığı bozarlar. Bu tür bir sınırın ötesinde akıl yürütmek, modellerin ortaya çıkardığı şey karşısında en çok şaşırdığımız noktadır.
Şiddet açısından ajan bunu yüksek olarak derecelendirdi çünkü bu bir sağlamlık bozulmasıydı, ancak Cloudflare yüksek saldırı karmaşıklığı nedeniyle bunun düşük olduğunu doğruladı.
Düzeltme, her girişin 0 < x < N'yi karşılamasını gerektiren hesaplamayı zorlamak için bir checkBounds adımı ekler. Negatif -gx'in işareti negatiftir ve herhangi bir zarar vermeden reddedilir. 19848a5'i taahhüt edin.
Hata 5: HPKE PSK doğrulaması bit düzeyinde VEYA anahtarı tarafından atlandı
Bu neredeyse dil düzeyinde bir tuzaktır. HPKE'nin validPSKInputs öğesinde, anahtar etiketleri bitsel-OR ile yazılmıştır:
// hpke/util.go vaka modeBase | modAuth : // 0x00 | 0x02 == 0x02, yani yalnızca modeAuth durumu modePSK | modeAuthPSK : // 0x01 | 0x03 == 0x03, yani yalnızca modeAuthPSK
Go'da bir durum | b: değeri iki durum değil, iki sabitin VEYA'sı olan tek bir durumdur. Yani durum moduPSK | modeAuthPSK aslında 0x03 durumudur ve modePSK (0x01) hiçbir durumla eşleşmez. PSK modunda eksik bir PSK'yı reddetmesi gereken dal atlanır.
Etkisi: SetupPSK(..., nil, nil) reddedilmek yerine boş bir PSK ile devam eder. PSK modunun PSK malzemesi gerektirmesi gerekiyor; bu, kimlik doğrulama önkoşulunu sessizce bırakır ve dağıtımın yapılandırıldığından daha zayıf bir modda çalışmasına olanak tanır. Düzeltme, OR'dan virgülle ayrılmış harflere (büyük/küçük harf modePSK, modeAuthPSK:) tek karakterli sınıf değişikliğidir. a3b4fa3'ü taahhüt edin. Kopya olduğu doğrulandı.
Hata 6: int64'teki Lagrange katsayıları
Tss/rsa'da, hisseler dağıtıldıktan sonra imzaların birleştirilmesi Lagrange enterpolasyonunu gerektirir. computeLambda, int64'te her Lagrange katsayısının payını ve paydasını oluşturdu:
// tss/rsa/rsa_threshold.go num := int64 ( 1 ) den := int64 ( 1 ) for _ , s := range S { jprime := int64 ( s . Index ) if jprime == j { devam } num *= i - jprime // orta düzey oyuncu sayıları için int64'ü taşar den *= j - jprime } lambda. Div( big.NewInt(num), big.NewInt(den)) // tamsayı bölümünün kesilmesi lambda. Mul (delta ve lambda)
Aslında burada birbirinden tamamen bağımsız iki hata var ve bunlardan her biri bir imzayı bozmaya yetiyor. Bunlardan ilki taşmadır: yaklaşık 21 oyuncuyla ürünler int64 tavanını geçer ($\approx 9,2 \times 10^{18}$) ve sessizce sarılır, çünkü Go tamsayı taşması nedeniyle paniğe kapılmaz. computeLambda daha sonra yanlış, genellikle negatif bir katsayı döndürür.
İkincisi ise kesmedir ve hiçbir şey taşmadığında bile ısırır. Kod önce num / den'i hesaplar ve ancak daha sonra delta ile çarpar. Shoup'ın planında $\delta \cdot \text{num}$'ın den tarafından tam olarak bölünebilir olduğu garanti edilir, ancak hisse endeksleri ardışık olmadığında tek başına num bölünemez; bu, $t$-of-$n$ alt kümesi için normal bir durumdur. $\{1, 3, 5\}$ paylarını birleştiren 3/5 şemasını alın: bir katsayı için $\text{num} = (0-3)(0-5) = 15$ ve $\text{den} = (1-3)(1-5) = 8$. Hatalı sipariş $\delta \cdot \lfloor 15/8 \rfloor$'ı hesaplar; bu, $\delta = 120$ ile $120$'dır; doğru değer $\delta \cdot 15 / 8$ $225$'dır.
Düzeltme, tüm hesaplamayı big.Int'e taşır ve çarpma ve bölme işlemlerini yeniden sıralayarak tam bölünebilirlik garantisinin geçerli olmasını sağlar. Bu taahhüt 751e372'dir. İki konu birbiriyle ilgisizdir, ancak temsilci bunları tek bir bulgu olarak birlikte bildirdi ve biz de temsilcinin çalışmasına saygımızdan dolayı gönderimi bu şekilde bıraktık.
Hata 7: Tek satırlık VE paylaşım hatası nedeniyle CP-ABE erişim kontrolü kesintisi
Bu zkao'nun kendi başına bulduğu hatadır. Altı konuyu onayladıktan sonra yukarıda ne bulacağını görmek için aynı kütüphaneye işaret ettik ve o da bunu bildirdi. Bu, CIRCL'in şifreli metin politikası öznitelik tabanlı şifrelemesindeki ( abe/cpabe/tkn20 ) erişim kontrolü garantisinin tamamen bozulmasıdır ve Cloudflare bunun geçerliliğini doğrulamıştır.
Şifreli Metin Politikası Öznitelik Tabanlı Şifreleme (CP-ABE), bir mesajı (konum: ABD VE departman: finans) VEYA (rol: yönetici) gibi bir politika kapsamında şifrelemenizi sağlar. Bir kullanıcı, kendi özniteliklerine bağlı bir anahtarı tutar ve şema, yalnızca bu özniteliklerin politikayı karşılaması durumunda şifreyi çözebileceğini garanti eder. ABD'deki finans çalışanı ve yönetici mesajı okuyabilir ve herkes aynı şifreli metni almasına rağmen başka kimse okuyamaz.
Dahili olarak, tkn20 politikayı, yapraklardaki niteliklere sahip AND ve OR kapılarından oluşan bir ağaca dönüştürür ve gizli, bu ağaçta bir sırrı (mesajı koruyan anahtar) paylaşır. Paylaşım boole mantığını takip etmelidir:
VEYA kapısı her iki çocuğa da tüm sırrı verir, çünkü her iki dalın da tatmin edilmesi yeterli olmalıdır.
VE kapısı sırrı böler, dolayısıyla onu yeniden inşa etmek için her iki çocuğa da ihtiyacınız vardır. Çocuklardan biri rastgele bir r değeri alır, diğeri ebeveyn - r alır ve yalnızca r + (ebeveyn - r) ebeveyni kurtarır.
Bu hatayı anlamak için aklınızda bulundurmanız gereken tek parça AND kapısıdır: her çocuk kısmi bir pay almalıdır ve hiçbir çocuk tek başına ebeveyni yeniden yapılandırmamalıdır.
Share'in AND durumunu gerçekte nasıl ele aldığı aşağıda açıklanmıştır:
// abe/cpabe/tkn20/internal/tkn/formula.go case Andgate: paylaşımlar [gate. In0 ], err = randomMatrixZp ( rand , k . satırlar , k . sütunlar ) // In0 = rastgele r ... paylaşımlar [ kapı . In1] = newMatrixZp (k.satırlar, k.sütunlar) // In1 = 0 paylaşım [gate. 0'da] sub ( paylaşımlar [ kapı . Çıkış ], paylaşımlar [ kapı . Giriş 1 ]) // In0 = ebeveyn - 0
Rastgele paylaşım oluşturulur ve ardından hemen atılır. In1 sıfıra ayarlanır ve son satır In0'ın üzerine sadece parent olan parent - In1 yazar. Yani bir çocuk sırrın tamamını alır, diğeri hiçbir şey almaz. AND kapısı artık bir AND değildir: ilk yaprağı ebeveyni kendi başına yeniden yapılandırır.
Bunun doğruluğu bozmadığını unutmayın. İki paylaşımın toplamı hala üst öğenin toplamıdır ( parent + 0 = parent), dolayısıyla politikayı karşılayan herhangi bir anahtarın şifresi çözülmeye devam eder ve eski kod tarafından oluşturulan şifreli metinler uyumlu kalır. Bozduğu şey gizliliktir: Artık tek bir AND yaprağı, her ikisini de gerektirmesi gereken bir sırrı kurtarmaktadır.
Bunu tam bir kopuşa dönüştüren şey, bu kırık VE geçidinin sona erdiği yerdir. CCA güvenliğine ulaşmak için tkn20, her politikayı yeni bir dış AND kapısına saran bir Boneh-Katz dönüşümü uygular ve bu kapının sol çocuğu dahili bir "joker" yaprağıdır. Otoritenin verdiği her özellik anahtarı bu joker karakteri taşır, dolayısıyla her anahtar o bir yaprağı karşılar. Şimdi iki gerçeği bir araya getirin: joker karakter yaprağı bir AND kapısının ilk çocuğudur ( In0 ) ve In0 tam olarak sırrın tamamını alan çocuktur. Bu nedenle her anahtar, politikadan bağımsız olarak mesaj anahtarını kendi kendine yeniden yapılandıran tek bir yaprak içerir!
Basit bir yazım hatası gibi görünse de bizi etkileyen şey, zkao'nun CP-ABE gibi karmaşık bir kavram hakkında akıl yürütme ve etkisini doğru bir şekilde değerlendirme becerisiydi. Pek çok Yüksek Lisans hâlâ yazım hatasını tespit ediyor ancak daha fazla mantık yürütmeden bunu "derinlemesine savunma" veya "kod hijyeni" sorunu olarak görmezden geliyor. Bu, geliştiricilerin güvenlik açığını küçümsemesine veya gözden kaçırmasına neden olabilir.
Düzeltme tek satırdır. Ebeveyni doğru şekilde paylaşın, böylece rastgele paylaşım In0'da kalır ve In1 tamamlayıcı olur:
hisseler [ kapı . 1'de] sub ( paylaşımlar [ geçit . Çıkış ], paylaşımlar [ geçit . Giriş0 ]) // In1 = ebeveyn - rastgele
Artık In0 rastgele değerini korur ve In1 ebeveyn - In0'ı tutar, dolayısıyla hiçbir AND yaprağı sırrı tek başına taşımaz. def2fd3 komutunu verin.
Öğrendiğimiz birkaç şey
Üç gözlem bizi etkiledi.
Yapay zeka şiddet açısından kötü ve asimetrik açıdan da kötü. Yukarıdaki tabloya tekrar bakın. "Temel gerçekler" olarak Cloudflare tarafından onaylanan ciddiyete güvenirsek, çoğu durumda aracı bulduğu şeyin etkisini abartmıştır. Ancak BLS hatasında durum tersine gitti ve yaygın olarak bilinen bir kritik kusuru küçümsedi ve temiz bir hileli anahtar saldırısını yalnızca orta düzey bir saldırı olarak etiketledi. Henüz tam bir açıklamamız veya çözümümüz yok. Çalışma hipotezimiz, hedefin CIRCL gibi birçok farklı uygulamada kullanılan bir kitaplık olması durumunda bunun gerçekten zor olduğudur, çünkü etki, modelin göremediği aşağı yöndeki arayanlara bağlıdır. Tutarlı bir şiddet matrisi artı açık bir tehdit modelleme adımı eklemenin, Yerel yasa yerine tüm sistem (ve potansiyel entegrasyon) düzeyindeki etkiyle ilgili model nedeni. Şimdilik ciddiyet, bir insana güvendiğimiz triyajın bir parçası olmaya devam ediyor.
Zkao'da, geliştiricilerin bir kullanıcı yapılandırması ( zkao.md ) aracılığıyla tehdit modellerini ve önem derecesi tercihlerini netleştirmelerine izin vererek bu sorunu geçici olarak çözüyoruz ve zkao'nun önem derecesi ayarını yinelemeli olarak iyileştirmeye devam ediyoruz. Zkao'nun tutarlı bir şekilde PoC üretebilmesi, yanlış pozitifleri de azaltıyor, dolayısıyla gerçek sorunlara güveniyoruz. Geliştiriciler için kritik önem taşıdığından, yine de varsayılan önem atamasını daha sistematik bir şekilde iyileştirmeye çalışıyoruz. Cloudflare'in ciddiyetini, bir hatanın canlı hizmetlerini etkileyip etkilemediğini değerlendiren ödül programının merceğinden değerlendirdiğini de belirtmekte fayda var. Örneğin Hata 2, kanıtın sağlamlığını tamamen bozmasına rağmen düşük olarak derecelendirildi. Bu derecelendirme yalnızca etkilenen kodun Cloudflare hizmetleri tarafından kullanılmadığını veya Cloudflare ortamında sınırlı etkiye sahip olduğunu gösterir. Bu, diğer dağıtımlarda etkinin bu kadar küçük olduğu anlamına gelmez; bu, özellikle birçok projenin üzerine inşa edilebileceği bir kitaplık için önemlidir.
Model eşleştirmeleri simetrik değildir ve roller değişebilir. Altı hatadan beşi, becerilerimizle eşleştirilen Claude Opus 4.6 tarafından bulundu. Aynı beceriler ve aynı sistem istemi altında, GPT-5.3 çoğunlukla keşfedilmek yerine doğrulandı; Tablodaki HPKE hatası, kendi başına ortaya çıkan hatadır. İşbölümünün istikrarlı kalmasını beklemiyorduk ve olmadı. Birkaç hafta sonra, taramayı o zamanki en yeni eşleştirme olan Opus 4.7 ve GPT-5.4 ile yeniden çalıştırdık ve roller esasen tersine döndü: GPT-5.4 daha fazla hata bulurken, Opus 4.7 yalnızca bunları doğrulama yeteneğine sahip. Bu, sonuçların herhangi bir model adına gereğinden fazla uydurulmaması konusunda iyi bir hatırlatmadır. O günden bu yana sınır yeniden ilerledi ve ilerlemeye de devam edecek. Bunu başka bir yazımızda inceleyeceğiz.
Zkao'yu "modelden bağımsız" olacak şekilde oluşturmamızın nedeni tam olarak bu modeldir, gelecek ay hangi modelin en iyi olacağını tahmin etmenize gerek kalmadan performansını en iyi durumda tutar.
Yapay zeka sorunları toplar ancak bunları her zaman zincirlemez. Hata 6 anlatıyor. Temsilci, tamamen bağımsız iki hatayı, bir taşma ve bir tamsayı kesmeyi tek bir bulguya sığdırdı. Her ikisi de gerçek, dolayısıyla bu gerçekten faydalı bir çalışma. Ancak aralarındaki ilişki hakkında akıl yürütmek yerine onları yan yana sundu ve aynı modeli başka yerlerde de gördük: birkaç gerçek gözlem, herhangi bir açıklama yapılmadan veya bunları daha etkili bir kullanıma zincirleme girişimi olmadan bir araya getirildi.
İşte tam da bu noktada, zkao'da ayrı sorunları gerçek bir uçtan uca istismara zincirleyen hata kompozisyonunu mümkün kılmak için yeni süreçler geliştirdik.
Bildirilen tüm sorunları derhal düzelten CIRCL bakımcılarına teşekkür ederiz. Bu bir serinin ilk yazısı; Diğer projelerdeki onaylanmış hataları çözüldükçe yayınlamaya devam edeceğiz.
200'den fazla kriptografik projeyi taradık (en çok indirilen kriptografi kasaları/paketleri arasından seçim yaparak) ve binin üzerinde aday bulguyla karşılaştık. Sonuç olarak günümüzün en büyük darboğazı triyajdır. Bildirilen her hatanın bir projeye ulaşmadan önce teknik geçerliliği açısından uzmanlarımız tarafından kontrol edilmesi gerekir, çünkü AI spam'ından herkes kadar biz de nefret ediyoruz. Bu çok fazla insan çabası gerektiriyor çünkü oluşturduğumuz otomatik önceliklendirme akışına henüz tam olarak güvenmiyoruz (daha iyiye gidiyor). Bu nedenle, iyi korunan en popüler projelerden bazılarına öncelik verdik.
Bir kriptografi projeniz varsa ve bu ilginizi çekiyorsa, ciddi hataların zamanında bulunup düzeltilmesi için sizinle birlikte doğrulamayı çok isteriz. Henüz tarama yapılmadıysa veya kod tabanınız son taramadan bu yana önemli ölçüde değiştiyse, yeni bir tarama yapmaktan memnuniyet duyarız. Bu türden sürekli yapay zeka kapsamı, zkao'nun tam olarak bunun için yaratıldığı şeydir. zksecurity.xyz/contact adresinden ulaşın.
