Bu çalışma, klasik eliptik eğri kriptografisini NIST tarafından standartlaştırılmış kuantum sonrası ML-KEM ve ML-DSA algoritmalarıyla birleştiren hibrit TLS 1.3 yapılandırmalarının Linux çalıştırabilen uç IoT donanımlarındaki performansını incelemiştir. NVIDIA Jetson Orin Nano ve Raspberry Pi 4B istemcileri; L1/L2, L3 ve L5 güvenlik kategorilerinde, 5, 10, 15, 20 ve 50 eşzamanlı bağlantı iş parçacığıyla sınanmıştır. Toplam 30 deneyde 160.584 sunucu tarafı ve 160.485 istemci tarafı el sıkışma kaydı oluşturulmuş; el sıkışma gecikmesi, ML-KEM ve ML-DSA işlem süreleri, bellek tüketimi, CPU kullanımı ve yüzde 95’lik kuyruk gecikmesi ölçülmüştür.

Ortalama TLS el sıkışma süresi bütün deney koşullarında bir saniyenin altında kalmıştır. Beş istemciden 50 istemciye geçildiğinde ortalama gecikme yapılandırmaya ve platforma göre yaklaşık 7,5–10,8 kat artmıştır. Ölçeklenme yaklaşık 20 eşzamanlı bağlantıya kadar görece düzenli ilerlemiş, 20 ile 50 bağlantı arasında ise doğrusalın üzerinde büyümüştür. Elli istemcide L5 ortalaması Jetson Orin Nano ile başlatılan bağlantılarda 848,8 ms, Raspberry Pi 4B ile başlatılan bağlantılarda 870,0 ms’dir. Aynı koşullardaki yüzde 95’lik değerler yaklaşık 1,79 saniyeye ulaşmıştır.

Çalışmada ayrı zamanlanan kuantum sonrası ML-KEM ve ML-DSA işlemleri toplam el sıkışma süresinin yaklaşık %2–5’ini oluşturmuştur. Sunucuda en pahalı kuantum sonrası işlem ML-DSA tabanlı hibrit imza üretimi, istemcide ise imza doğrulamasıdır. Bununla birlikte bu oran bütün kriptografik işlemlerin maliyeti değildir; klasik ECDH ve ECDSA aşamaları ayrı zamanlanmamıştır. Ayrıca el sıkışmanın ağ üzerinden gerçek bayt büyüklüğü ve kablosuz bağlantı gecikmesi kaydedilmediğinden geri kalan sürenin ne kadarının sertifika aktarımı, TLS kayıt işleme, işletim sistemi, ağ veya ölçüm günlüklemesinden kaynaklandığı doğrudan belirlenememektedir.

Türkiye açısından değerlendirme: Bulgular; Türkiye’de akıllı fabrika ağları, endüstriyel IoT geçitleri, enerji ve ulaşım sistemleri, yerel yapay zekâ düğümleri ve uzun ömürlü güvenli haberleşme altyapıları geliştiren ekipler açısından önemlidir. Çalışma, kuantum sonrası TLS’nin Raspberry Pi ve Jetson sınıfı cihazlarda çalıştırılabildiğini, ancak eşzamanlı bağlantı mimarisinin dikkatle tasarlanması gerektiğini göstermektedir. Türkiye’de uygulama kararı verilmeden önce yerel donanım modelleri, gerçek operatör ve kurum ağları, kablolu ve kablosuz bağlantılar, klasik TLS karşılaştırması, karşılıklı kimlik doğrulama, uzun süreli yük, elektrik tüketimi ve gerçek sertifika zincirleriyle yeni testler yapılmalıdır. Bu çalışmadan Türkiye’deki bütün uç sistemlerde aynı gecikmenin görüleceği, 50 fiziksel cihazın sorunsuz destekleneceği veya kuantum sonrası geçişin yalnızca yazılım güncellemesiyle tamamlanabileceği sonucu çıkarılamaz.

Araştırmanın temel sorusu nedir?

TLS 1.3, internet ve özel ağlardaki istemci–sunucu bağlantılarının gizliliğini ve kimlik doğrulamasını sağlayan temel güvenlik protokollerinden biridir. Ancak TLS 1.3’ün günümüzde kullandığı klasik açık anahtarlı yöntemlerin, yeterince güçlü kuantum bilgisayarları ortaya çıktığında kırılabileceği öngörülmektedir.

Bu risk yalnızca gelecekte kurulacak bağlantıları ilgilendirmez. Şifreli trafik bugün kaydedilip ileride kuantum bilgisayarıyla çözülebilir. Uzun süre gizli kalması gereken endüstriyel, sağlık, kamu veya kritik altyapı verileri açısından bu durum “şimdi topla, sonra çöz” tehdidi oluşturur.

Geçiş döneminde önerilen yaklaşımlardan biri, klasik ve kuantum sonrası yöntemleri aynı TLS el sıkışmasında birlikte kullanmaktır. Böylece iki bileşenden biri gelecekte zayıflasa bile diğerinin bağlantıyı koruması hedeflenir. Bunun bedeli daha büyük anahtarlar, sertifikalar, şifreli kapsüller ve dijital imzalardır.

Araştırmanın temel sorusu şudur: Bu daha ağır hibrit TLS 1.3 el sıkışmaları, veri merkezinden daha sınırlı fakat mikrodenetleyicilerden daha güçlü Linux sınıfı uç IoT cihazlarında kaç eşzamanlı bağlantıya kadar kabul edilebilir performans gösterebilir?

Hibrit kuantum sonrası TLS 1.3 ne anlama gelmektedir?

Hibrit yapı, anahtar anlaşması ve kimlik doğrulamasında klasik ve kuantum sonrası algoritmaları birlikte kullanır. Çalışmada anahtar kapsülleme tarafında klasik ECDH ile ML-KEM; dijital imza tarafında klasik ECDSA ile ML-DSA eşleştirilmiştir.

• ML-KEM: TLS oturum anahtarının oluşturulmasına katkı sağlayan modül kafes tabanlı anahtar kapsülleme mekanizmasıdır. Çalışmada eski uygulama adları olan Kyber-512, Kyber-768 ve Kyber-1024 kullanılmıştır.
• ML-DSA: Sunucunun kimliğini ve el sıkışma transkriptini imzalayan modül kafes tabanlı dijital imza standardıdır. Çalışmada ML-DSA-44, ML-DSA-65 ve ML-DSA-87 kullanılmıştır.
• ECDH: Klasik eliptik eğri tabanlı ortak anahtar oluşturma yöntemidir.
• ECDSA: Klasik eliptik eğri tabanlı dijital imza yöntemidir.

Hibrit yapı, klasik ve kuantum sonrası bileşenlerden en az biri güvenli kaldığı sürece bağlantının korunmasını amaçlar. Ancak çalışma bu birleşimin kriptografik güvenlik ispatını değerlendirmemekte; uygulanmış yapılandırmaların performansını ölçmektedir.

Hangi güvenlik kategorileri sınanmıştır?

L1/L2, L3 ve L5 kategorileri kabaca giderek yükselen güvenlik düzeylerini temsil etmektedir. Güvenlik kategorisi arttıkça açık anahtar, özel anahtar, kapsül ve imza boyutları büyümektedir.

Hibrit sertifikada kullanılan imza büyüklüğü Durum 1’de 2.495 bayt, Durum 2’de 3.418 bayt ve Durum 3’te 4.771 bayttır. Bu büyüme yalnızca matematiksel işlem süresini değil, sertifikanın TLS kayıt katmanından ve ağ üzerinden taşınma maliyetini de artırabilir.

TLS 1.3 el sıkışmasında hangi işlemler yapılmaktadır?

Çalışmanın 4. sayfasındaki akış şeması, hibrit TLS 1.3 oturumunun temel sırasını göstermektedir:

1. İstemci TCP bağlantısını kurar.
2. İstemci, desteklediği hibrit anahtar grupları ve imza algoritmalarıyla ClientHello mesajını gönderir.
3. Sunucu hibrit ML-KEM ve ECDH bileşenleriyle ortak sır oluşturur.
4. Sunucu hibrit sertifikasını ve el sıkışma imzasını gönderir.
5. İstemci ML-KEM kapsülünü açar ve hibrit imzayı doğrular.
6. Taraflar Finished mesajlarını doğruladıktan sonra şifreli uygulama verisi aktarılır.

Çalışmadaki süre ölçümü TCP üç yönlü bağlantı kurulumunu kapsamamaktadır. HTTP isteği ve yanıtı da TLS el sıkışması bittikten sonra ayrı ölçülmüştür.

Deney düzeneğinde cihazların gerçek rolleri nelerdir?

6. sayfadaki deney düzeneğine göre Jetson Orin Nano ve Raspberry Pi 4B istemci cihazlarıdır. TLS sunucusu, Xeon W-2155 işlemcili Precision 5820 masaüstü bilgisayar üzerindeki tek sanal CPU’lu sanal makinede çalışmaktadır.

Her iki uç cihaz özel bir IEEE 802.11 erişim noktasına kablosuz bağlanmış, sunucu aynı ağın kablolu tarafında yer almıştır. Bu düzen iki uç cihazın aynı yazılım yığınıyla karşılaştırılmasını sağlamıştır.

Bununla birlikte çalışmanın bazı bölümlerinde Jetson ve Raspberry Pi’nin “sunucu rolleri”nden söz edilmektedir. Bu ifade, Şekil 2’deki sistem modeli ve yöntem açıklamasıyla uyumlu değildir. Sonuç tablolarındaki “sunucu tarafı süre”, ortak PC sunucusunun kaydettiği süreyi; platform adı ise bağlantıyı başlatan uç istemciyi göstermektedir.

Bu nedenle deney, “Jetson veya Raspberry Pi üzerinde çalışan TLS sunucusuna 50 fiziksel cihaz bağlanması” biçiminde yorumlanmamalıdır.

Eşzamanlı istemci yükü nasıl üretilmiştir?

Her uç cihazda seçilen eşzamanlı kullanıcı sayısı kadar C++ iş parçacığı oluşturulmuştur. Her iş parçacığı aşağıdaki kapalı döngüyü bir dakika boyunca aralıksız tekrarlamıştır:

1. TCP bağlantısı kurma,
2. TLS 1.3 el sıkışması,
3. 100 baytlık gövde içeren tek HTTP POST isteği,
4. Sunucudan yankı yanıtı alma,
5. Bağlantıyı kapatma,
6. Yeni bağlantıya başlama.

HTTP kalıcı bağlantısı kapatılmıştır. Bu nedenle her uygulama isteği için yeni bir TCP bağlantısı ve yeni bir TLS el sıkışması gerçekleştirilmiştir.

Beş, 10, 15, 20 ve 50 düzeyleri bağımsız fiziksel cihaz sayısını değil, aynı cihazda aynı anda dönen bağlantı iş parçacığı sayısını göstermektedir. Ayrıca iş parçacıkları arasında bekleme veya sabit istek hızı bulunmamaktadır. Deney, açık döngülü gerçek kullanıcı geliş modelinden çok sürekli azami yük oluşturan kapalı döngülü bir stres testidir.

Ortalama el sıkışma süreleri ne göstermektedir?

Güvenlik kategorisi yükseldikçe gecikme bütün yük düzeylerinde artmıştır. On istemcide Jetson tarafındaki L3 süresi L1/L2’nin 2,20 katı, L5 süresi 3,85 katıdır. Raspberry Pi 4B’de aynı oranlar sırasıyla 2,61 ve 5,38’dir.

Bu sonuçlar, daha yüksek güvenlik kategorilerindeki büyük anahtar ve imza yapılarına geçmenin sabit bir ek süre değil, platforma ve eşzamanlı yüke bağlı bir maliyet oluşturduğunu göstermektedir.

“Bütün el sıkışmalar bir saniyenin altında” sonucu nasıl okunmalıdır?

Bu ifade yalnızca aritmetik ortalamalar için doğrudur. Elli istemcili L5 deneylerinde ortalamalar yaklaşık 0,85–0,87 saniyedir. Ancak yüzde 95’lik gecikme Jetson istemcisiyle 1.792,5 ms, Raspberry Pi istemcisiyle 1.780,9 ms’ye ulaşmıştır.

Başka bir ifadeyle yüksek yükte bağlantıların önemli bir bölümü ortalamadan çok daha uzun sürmüştür. Gerçek zamanlı veya kesin gecikme sınırı olan sistemlerde yalnızca ortalama değere bakmak yeterli değildir.

Neden yaklaşık 20 istemciden sonra ölçeklenme bozulmuştur?

Beş istemciden 50 istemciye çıkıldığında Jetson Orin Nano ile başlatılan bağlantılardaki ortalama gecikme yapılandırmaya göre yaklaşık 7,5–9,6 kat; Raspberry Pi 4B’de yaklaşık 9,5–10,8 kat artmıştır. İstemci sayısı 10 kat artarken bazı koşullarda gecikmenin 10 kattan fazla büyümesi doğrusalın üzerinde ölçeklenmeye işaret etmektedir.

Çalışma bu artışı öncelikle sunucu tarafındaki istek işleme çekişmesine bağlamaktadır. Sunucu:

• Tek sanal CPU üzerinde çalışmaktadır.
• Her yeni bağlantı için ayrı ve kopuk bir iş parçacığı oluşturmaktadır.
• Her ölçüm olayında ortak bir kilit kullanmaktadır.
• Her kayıt satırından sonra dosyayı eşzamanlı olarak diske yazdırmaktadır.

Elli etkin bağlantı iş parçacığının tek sanal CPU üzerinde zamanlanması ve bütün günlük kayıtlarının tek kilit üzerinden geçirilmesi, CPU yüzdesi %100’e ulaşmadan da bekleme kuyruğu oluşturabilir.

Bu nedenle sonuç, kuantum sonrası TLS’nin doğal olarak 20 istemcide ölçeklenme sınırına ulaştığını göstermemektedir. Daha çok, çalışmada kullanılan iş parçacığı ve günlükleme mimarisinin yaklaşık bu noktada gecikme üretmeye başladığını göstermektedir.

Kuantum sonrası matematik gerçekten darboğaz değil midir?

Çalışma, liboqs içindeki ML-KEM ve ML-DSA giriş noktalarını mikrosaniye çözünürlüğünde ayrı zamanlamıştır. On istemcili deneyde sunucu tarafındaki sonuçlar şöyledir:

İstemci tarafında anahtar üretimi, imza doğrulaması ve kapsül açma toplamı L5 altında Jetson’da yaklaşık 1,14 ms, Raspberry Pi 4B’de 1,22 ms’dir. Sunucu ve istemci tarafındaki ölçülen OQS süreleri birlikte ele alındığında on istemcili deneylerde toplam el sıkışma süresinin yaklaşık %3,5–4,8’i elde edilmektedir.

Bu, ölçülen ML-KEM ve ML-DSA çekirdeklerinin toplam sürenin küçük bir bölümünü oluşturduğunu güçlü biçimde göstermektedir. Ancak “bütün kriptografinin payı %2–5’tir” biçiminde genişletilmemelidir. Çalışma:

• ECDH hesaplamasını ayrı zamanlamamıştır.
• ECDSA imza ve doğrulamasını ayrı zamanlamamıştır.
• OpenSSL’in anahtar türetme ve kayıt şifreleme işlemlerini ayırmamıştır.
• Sertifika ayrıştırma ve ASN.1 işlemlerini ayrı ölçmemiştir.

Dolayısıyla güvenli sonuç, “ölçülen kuantum sonrası OQS işlemleri ana gecikme bileşeni değildir” ifadesidir.

Kalan gecikmenin büyük hibrit mesajlardan kaynaklandığı kanıtlanmış mıdır?

Çalışma, kuantum sonrası işlem süresi ile toplam el sıkışma arasındaki büyük farkı hibrit sertifika, anahtar paylaşımı ve imza mesajlarının taşınmasına; TLS durum makinesine; işletim sistemi ağ yığınına; kablosuz bağlantıya; iş parçacığı zamanlamasına ve günlüklemeye bağlamaktadır.

Bu yorum büyüyen anahtar ve imza boyutlarıyla uyumludur. Ancak doğrudan bir ayrıştırma yapılmamıştır. Deney sırasında:

• TLS el sıkışmasının gerçek ağ baytları yakalanmamıştır.
• Bağlantı RTT’si ölçülmemiştir.
• Wi-Fi bağlantı hızı ve kanal genişliği kaydedilmemiştir.
• RSSI ve paket yeniden iletimleri raporlanmamıştır.
• Çekirdek içi kopyalama veya sistem çağrısı süreleri ölçülmemiştir.

Bu nedenle “veri taşıma ana darboğazdır” sonucu, ölçülmüş kuantum sonrası işlem süresinden geriye kalan kısmın yorumlanmasına dayanmaktadır. Makul fakat doğrudan ölçülmemiş bir çıkarımdır.

Raspberry Pi 4B neden bazı testlerde daha hızlı görünmüştür?

Raspberry Pi 4B dört Cortex-A72 çekirdeğini 1,8 GHz’de, Jetson Orin Nano ise altı Cortex-A78AE çekirdeğini 1,5 GHz’de çalıştırmıştır. Tek bir TLS el sıkışması büyük ölçüde sıralı olduğundan Jetson’ın fazla çekirdekleri ve GPU’su tek oturumun süresini doğrudan azaltmamıştır.

L1/L2 yapılandırmasında Raspberry Pi 4B ortalama olarak %5–25 daha kısa süreler vermiştir. L3’te fark daralmış, L5’te iki platform birbirine yaklaşmıştır.

Araştırmacılar bunu küçük iş yüklerinde çekirdek saat hızının, daha büyük L5 yüklerinde ise önbellek ve bellek bant genişliğinin önem kazanmasıyla açıklamaktadır. Bu yorum deney eğilimleriyle uyumludur; ancak iki kart yalnızca saat hızı bakımından farklı değildir. Mikro mimari, önbellek, bellek türü, işletim sistemi, kablosuz donanım ve derleyici etkileri aynı anda değişmektedir.

Bu nedenle çalışma, farkın tam olarak ne kadarının saat hızından veya bellek bant genişliğinden kaynaklandığını nicel olarak kanıtlamamaktadır.

Bellek tüketimi dağıtımı engelleyecek kadar yüksek midir?

Sunucu tarafındaki ortalama süreç belleği beş istemcide yaklaşık 12 MB, 50 istemcide yaklaşık 19–20 MB olmuştur. En yüksek tepe değer L5 ve 50 istemci altında 26,2 MB’dir.

İstemci tarafında 50 bağlantı iş parçacığında Jetson Orin Nano yaklaşık 36,8–38,2 MB, Raspberry Pi 4B yaklaşık 27,9–30,4 MB ortalama süreç belleği kullanmıştır. Her iki cihazda da 8 GB sistem belleği bulunduğu için bu değerler toplam kapasitenin küçük bir bölümüdür.

Sunucu belleğindeki artış bağlantı başına yaklaşık 150–200 kB olarak yorumlanmıştır. Güvenlik kategorisinin etkisi, eşzamanlı istemci sayısının etkisine göre daha küçüktür.

CPU kullanımı neden yüzde 100’ün üzerine çıkmıştır?

İstemci CPU değerleri bütün çekirdeklerin toplamıdır. Jetson Orin Nano altı çekirdeğe sahip olduğu için teorik üst sınır %600, Raspberry Pi 4B dört çekirdeğe sahip olduğu için %400’dür.

Elli istemcide Jetson’ın en yüksek ortalama değeri %298, Raspberry Pi 4B’nin en yüksek değeri %211’dir. Bu değerler yaklaşık toplam kapasitenin yarısına karşılık gelmektedir.

Sunucu tek sanal CPU ile sınırlandırılmıştır ve teorik üst sınırı %100’dür. En yüksek ortalama sunucu kullanımı %43 olarak ölçülmüştür. Düşük CPU kullanımı, beklemenin bulunmadığı anlamına gelmez. Disk yazma, kilit, ağ ve zamanlama beklemeleri süreç CPU tüketmeden gecikmeyi büyütebilir.

Çalışmada klasik TLS karşılaştırması neden önemlidir?

Aynı donanım ve ağ koşullarında yalnızca ECDH/ECDSA kullanan klasik TLS 1.3 yapılandırması sınanmamıştır. Bu nedenle çalışmadan aşağıdaki değerler çıkarılamaz:

• Hibrit TLS’nin klasik TLS’ye göre yüzde kaç daha yavaş olduğu,
• Hibrit yapı nedeniyle kaç ek bayt gönderildiği,
• Klasik TLS’nin eşzamanlı istemci ölçeklenmesinin nasıl olduğu,
• 20 istemciden sonraki bozulmanın ne kadarının PQC’ye özgü olduğu.

Çalışma üç hibrit güvenlik kategorisini birbirleriyle karşılaştırmaktadır; klasik ve hibrit TLS arasında doğrudan deneysel fark sunmamaktadır.

Çalışmanın desteklediği sonuçlar nelerdir?

• ML-KEM ve ML-DSA içeren üç hibrit TLS 1.3 yapılandırması Jetson Orin Nano ve Raspberry Pi 4B istemcilerinde başarıyla çalıştırılmıştır.
• Ortalama el sıkışma süresi sınanan bütün koşullarda bir saniyenin altında kalmıştır.
• Güvenlik kategorisi yükseldikçe el sıkışma süresi ve ölçülen kuantum sonrası işlem süresi artmıştır.
• Ölçülen ML-KEM ve ML-DSA işlemleri toplam el sıkışma süresinin küçük bir bölümünü oluşturmuştur.
• Yüksek eşzamanlılıkta ortalama ve yüzde 95’lik gecikme doğrusalın üzerinde büyümüştür.
• Sunucu ve istemci süreçleri sınanan yüklerde toplam CPU ve bellek kapasitesini tüketmemiştir.
• Tek oturumlu sıralı bir iş yükünde yüksek çekirdek sayısı veya GPU bulunması otomatik olarak daha kısa el sıkışma sağlamamıştır.

Çalışma neyi kanıtlamamaktadır?

• Uç kartların TLS sunucusu olarak 50 bağımsız fiziksel istemciyi kabul edebildiğini göstermemektedir.
• Kuantum sonrası TLS’nin klasik TLS’ye göre ek maliyetini ölçmemektedir.
• Bütün kriptografik işlemlerin yalnızca %2–5 maliyet oluşturduğunu kanıtlamamaktadır.
• Kalan gecikmenin tam olarak hangi bölümünün ağ, işletim sistemi, kopyalama veya günlükleme olduğunu göstermemektedir.
• Yaklaşık 20 istemcilik ölçeklenme eşiğinin başka sunucu mimarilerinde de geçerli olduğunu göstermemektedir.
• Enerji tüketimini ölçmemektedir.
• Karşılıklı TLS kimlik doğrulamasını, oturum sürdürmeyi veya sıfır gidiş-dönüş bağlantı kurulumunu değerlendirmemektedir.
• Mobil ağ, gerçek endüstriyel trafik veya internet üzerinden uzun mesafeli bağlantı koşullarını temsil etmemektedir.
• Bütün uç IoT kartlarında Raspberry Pi 4B’nin Jetson Orin Nano’dan daha hızlı olacağını göstermemektedir.

Çalışmanın Yöntemi ve Bulguları

Donanım düzeni

Yazılım yığını

Deney matrisi

Toplam deney sayısı şu çarpımdan oluşmaktadır:

2 istemci platformu × 3 güvenlik yapılandırması × 5 eşzamanlı bağlantı düzeyi = 30 deney

Her deney bir dakika sürmüştür. Tamamlanan el sıkışma sayısı koşula göre 2.268 ile 10.641 arasında değişmiştir.

Araştırmacılar 99 kayıtlık farkı bir dakikalık sürenin sonunda istemci sürecinin kapatılması sırasında sunucuda tamamlanan fakat istemci tarafına yazılamayan bağlantılarla açıklamıştır.

Ölçüm araçları

TLS el sıkışma süresi, istemci ve sunucudaki stream.handshake() çağrısının duvar saati süresi olarak ölçülmüştür. TCP bağlantı kurulumu ve HTTP veri aktarımı bu sürenin dışında tutulmuştur.

ML-KEM ve ML-DSA aşamaları yamalanmış liboqs ile ayrı zamanlanmıştır:

• OQS_KEM_keypair: Anahtar çifti üretimi,
• OQS_KEM_encaps: Kapsülleme,
• OQS_KEM_decaps: Kapsül açma,
• OQS_SIG_sign: İmza üretimi,
• OQS_SIG_verify: İmza doğrulaması.

Bellek ve CPU kullanımı pidstat ile beş saniyede bir örneklenmiştir. Bir dakikalık deneyde az sayıda sistem örneği alınması, özellikle ara yük düzeylerindeki dalgalanmaların yorumunu sınırlamaktadır.

Ölçüm sisteminin kendi oluşturduğu ek yük

Her el sıkışma ve kriptografik işlem kaydı ortak bir mutex üzerinden dosyaya yazılmış ve her satırdan sonra flush() veya fflush() çağrılmıştır. Böylece kayıt kaybı azaltılmış fakat çok sayıda iş parçacığı aynı dosya kilidi ve disk yazma yolu için beklemek zorunda kalmıştır.

Bu etki bütün deneylerde aynı kod kullanıldığı için karşılaştırmaların tutarlılığını tamamen ortadan kaldırmaz. Ancak eşzamanlılık arttıkça ölçüm sisteminin kendi gecikmesi de büyüdüğünden yüksek yük sonuçları üretim ortamındaki yalın TLS sunucusunu doğrudan temsil etmez.

İstemci tarafındaki kuantum sonrası işlem süreleri

İstemcide en yüksek tek işlem imza doğrulamasıdır. Güvenlik kategorisi yükseldikçe bütün aşamalardaki süre artmış, ancak toplam OQS süresi on istemcide yaklaşık 1,2 ms’nin altında kalmıştır.

Yüzde 95’lik gecikmenin önemi

Beş istemcide yüzde 95’lik değerin ortalamaya oranı çoğu koşulda yaklaşık 1,4–1,5’tir. On istemcide oran yaklaşık 1,5–1,7’ye çıkmıştır. Elli istemcide oran yaklaşık 2,0–2,2’ye yükselmiştir.

Bu genişleme, yüksek yükte yalnızca ortalamanın artmadığını, bağlantılar arasındaki performans değişkenliğinin de büyüdüğünü göstermektedir. Kuyruk oluşumu bazı el sıkışmalarını diğerlerinden çok daha uzun hâle getirmiştir.

Sunucu belleği ve CPU değerleri

Sunucu verileri Jetson istemcisiyle yapılan deneyler sırasında eksiksiz kaydedilmiştir. Raspberry Pi deneylerindeki paralel sunucu kayıtları eksik olduğu için ana tabloda kullanılmamıştır. Sunucu yazılımı ve donanımı aynı olsa da bu eksiklik iki deney grubunun sunucu kaynak tüketimini doğrudan karşılaştırmayı engellemektedir.

Uygulama mesaj boyutları neyi göstermektedir?

Sunucu her deneyde uygulama katmanında 237 bayt almış ve 219 bayt göndermiştir. Bu değerlerin güvenlik kategorisine göre değişmemesi beklenen bir sonuçtur; çünkü ölçülen bölüm el sıkışmadan sonra gönderilen sabit HTTP isteği ve yanıtıdır.

Bu sayılar hibrit TLS sertifikalarının, anahtar paylarının veya el sıkışma imzalarının ağdaki boyutunu göstermemektedir. Gerçek el sıkışma trafiği paket yakalama yöntemiyle ölçülmemiştir.

Sonuçların güvenilirliğini artırmak için gereken deneyler

• Aynı donanım ve yazılımla yalnız klasik TLS 1.3 temel çizgisinin eklenmesi,
• Jetson Orin Nano ve Raspberry Pi 4B’nin TLS sunucusu rolünde ayrıca sınanması,
• Bağımsız fiziksel istemcilerle dağıtık yük oluşturulması,
• Kapalı döngü yerine denetlenebilir açık döngülü istek hızlarının kullanılması,
• Tek iş parçacığı–bağlantı modeli yerine olay güdümlü sunucu ve sabit işçi havuzu karşılaştırması,
• Ölçüm kayıtlarının bellekte tamponlanarak deney sonrasında yazılması,
• Birden fazla sanal CPU ve farklı sunucu çekirdek sayılarının sınanması,
• TLS el sıkışmasının paket yakalama yöntemiyle gerçek bayt boyutunun ölçülmesi,
• RTT, RSSI, Wi-Fi hızı, kanal genişliği ve paket yeniden iletimlerinin kaydedilmesi,
• Her koşulun farklı zamanlarda en az birkaç bağımsız deney olarak tekrarlanması,
• Enerji tüketiminin haricî güç ölçerle doğrudan ölçülmesi,
• Karşılıklı TLS, oturum sürdürme ve uzun ömürlü bağlantı senaryolarının incelenmesi,
• Raspberry Pi 5, farklı ARM kartları, endüstriyel geçitler ve mikrodenetleyicilerle dış doğrulama,
• ML-KEM dışında HQC gibi farklı kuantum sonrası algoritmaların karşılaştırılması.

Kaynak ve Yöntem Notu

Çalışmanın tam özgün adı: Performance and Scalability of Hybrid Post-Quantum TLS 1.3 on Edge IoT Platforms under Concurrent-Client Load

Yazarlar: Togu Novriansyah Turnip, Birger Andersen ve César Vargas-Rosales

Yazar sıralaması: Togu Novriansyah Turnip; Birger Andersen; César Vargas-Rosales

Eş katkı bilgisi: Çalışmada eşit katkı veya eş birinci yazarlık beyanı bulunmamaktadır.

Sorumlu yazar: Togu Novriansyah Turnip

Kurumlar:

• Department of Engineering Technology, Technical University of Denmark, Ballerup, Denmark
• School of Engineering and Sciences, Tecnológico de Monterrey, Monterrey, Mexico
• Faculty of Vocational Studies, Institut Teknologi Del, Laguboti, North Sumatera, Indonesia

DOI:10.2139/ssrn.6991673

Dergi: Çalışma bir dergide yayımlanmamıştır.

Özgün dergi yayınevi: Bulunmamaktadır.

Yayın platformu: SSRN

Yüklenme tarihi: 24 Haziran 2026

Yayın yılı: 2026

Sayfa sayısı: 19

Kaynak türü: Kontrollü deneysel ağ ve sistem performansı preprinti

Hakemlik durumu: Çalışma hakem değerlendirmesinden geçmemiştir. Her sayfada “Preprint not peer reviewed” uyarısı bulunmaktadır.

Resmî bağlantı:SSRN çalışma sayfası

Kaynak kodu: Araştırmacılar deneylerde kullanılan lily-pqc uygulamasının açık kaynak kodunu GitHub deposunda paylaştıklarını bildirmiştir.

Finansman: Çalışma Technical University of Denmark bursuyla desteklenmiştir. Togu Novriansyah Turnip ayrıca Otto Mønsted Foundation’dan seyahat desteği aldığını bildirmiştir.

Çıkar ilişkisi beyanı: Togu Novriansyah Turnip, DTU finansmanını ve Otto Mønsted Foundation ile seyahat geri ödemesi ilişkisini beyan etmiştir. Diğer araştırmacılar çalışmayı etkileyebilecek bilinen bir mali veya kişisel ilişki bildirmemiştir.

Bu Türkçe makale, yüklenen 19 sayfalık çalışmanın metni, tabloları, grafik ve şemaları baştan sona incelenerek hazırlanmıştır. Bilimsel yöntem, donanım özellikleri, bağlantı sayıları, gecikmeler, bellek değerleri ve kriptografik işlem süreleri yalnızca çalışmada sunulan verilere dayanmaktadır. Dış kaynaklar yalnızca başlık, yazarlar, kurumlar, DOI, platform, yüklenme tarihi ve yayın durumunun bibliyografik doğrulaması amacıyla kullanılmıştır.

Çalışmanın sistem rolü açıklamalarında dikkat gerektiren bir tutarsızlık bulunmaktadır. Yöntem ve deney şemasında Jetson Orin Nano ile Raspberry Pi 4B istemci, PC ise sunucudur; bazı sonraki ifadeler kartlardan sunucu rolündeymiş gibi söz etmektedir. Bu makalede görsel deney düzeneği ve ayrıntılı yöntem açıklaması esas alınmıştır.

Tartışma bölümündeki KEMTLS değerlendirmesinde Raspberry Pi 4B L5 imza üretim süresi yaklaşık 0,64 ms olarak yazılmıştır. Ana sonuç tablosuna göre imza üretimi 3,193 ms, 0,637 ms ise kapsülleme süresidir. Bu nedenle Türkçe metinde ana sonuç tablosundaki değer kullanılmıştır.

Çalışmanın %2–5 oranı yalnızca yamalanmış liboqs tarafından zamanlanan kuantum sonrası işlemleri kapsamaktadır. Klasik eliptik eğri işlemleri ve TLS yığınının kalan bölümleri ayrı ölçülmediğinden bu oran “toplam kriptografi maliyeti” olarak sunulmamıştır.

Sonuçlar, tek sanal CPU’lu sunucu, bağlantı başına iş parçacığı, eşzamanlı kilitli günlükleme, sabit kablosuz test ortamı ve bir dakikalık deney pencereleri için geçerlidir. Gerçek üretim sistemlerindeki kapasite, gecikme ve enerji tüketimi ayrıca doğrulanmalıdır.