Utafiti huu umechunguza performance ya hybrid TLS 1.3 configurations kwenye edge IoT hardware inayoweza kuendesha Linux, configurations ambazo zinaunganisha classical elliptic-curve cryptography na post-quantum ML-KEM na ML-DSA algorithms zilizostandardishwa na NIST. NVIDIA Jetson Orin Nano na Raspberry Pi 4B clients zilijaribiwa katika L1/L2, L3 na L5 security categories kwa 5, 10, 15, 20 na 50 concurrent connection threads. Katika total experiments 30, server-side handshake records 160.584 na client-side handshake records 160.485 ziliundwa; handshake latency, ML-KEM na ML-DSA processing times, memory consumption, CPU utilization na 95th-percentile queue latency zilipimwa.

Average TLS handshake time ilibaki chini ya sekunde moja katika experimental conditions zote. Kutoka clients five hadi 50, average latency iliongezeka takriban mara 7,5–10,8 kutegemea configuration na platform. Scaling iliendelea kwa utaratibu wa kiasi hadi takriban concurrent connections 20, lakini kati ya connections 20 na 50 ilikua zaidi ya linear. Kwa fifty clients, L5 average ilikuwa 848,8 ms kwa connections zilizoanzishwa na Jetson Orin Nano na 870,0 ms kwa connections zilizoanzishwa na Raspberry Pi 4B. 95th-percentile values katika conditions hizo hizo zilifikia takriban sekunde 1,79.

Katika utafiti, separately timed post-quantum ML-KEM na ML-DSA operations ziliunda takriban %2–5 ya total handshake time. Kwenye server, most expensive post-quantum operation ilikuwa ML-DSA-based hybrid signature generation, na kwenye client ilikuwa signature verification. Hata hivyo, ratio hii si gharama ya cryptographic operations zote; classical ECDH na ECDSA stages hazikutimiwa separately. Pia actual byte size ya handshake kwenye network na wireless-link latency hazikurekodiwa, hivyo haiwezekani kubaini moja kwa moja ni kiasi gani cha remaining time kinatokana na certificate transfer, TLS record processing, operating system, network au measurement logging.

Kwa mtazamo wa Uturuki: Findings ni muhimu kwa teams nchini Uturuki zinazotengeneza smart-factory networks, industrial IoT gateways, energy na transportation systems, local AI nodes na long-lived secure communication infrastructures. Utafiti unaonyesha kwamba post-quantum TLS inaweza kuendeshwa kwenye Raspberry Pi na Jetson-class devices, lakini concurrent-connection architecture lazima idesigniwe kwa uangalifu. Kabla ya implementation decision nchini Uturuki, new tests zinapaswa kufanywa kwa local hardware models, real operator na institutional networks, wired na wireless links, classical TLS comparison, mutual authentication, long-duration load, electrical energy consumption na real certificate chains. Kutokana na utafiti huu haiwezi kuhitimishwa kwamba edge systems zote nchini Uturuki zitaonyesha latency hiyo hiyo, kwamba physical devices 50 zitasupportiwa bila tatizo au kwamba post-quantum migration itakamilika kwa software update pekee.

Swali kuu la utafiti ni nini?

TLS 1.3 ni mojawapo ya basic security protocols zinazotoa confidentiality na authentication kwa client–server connections kwenye internet na private networks. Hata hivyo, classical public-key methods zinazotumiwa na TLS 1.3 leo zinatarajiwa kuwa vulnerable endapo sufficiently powerful quantum computers zitapatikana.

Risk hii haihusu future connections pekee. Encrypted traffic inaweza kurekodiwa leo na kuja kudecodeiwa baadaye kwa quantum computer. Kwa industrial, healthcare, public-sector au critical-infrastructure data inayotakiwa kubaki confidential kwa muda mrefu, hali hii huunda threat ya “harvest now, decrypt later”.

Approach mojawapo inayopendekezwa katika transition period ni kutumia classical na post-quantum methods pamoja ndani ya TLS handshake hiyo hiyo. Lengo ni kwamba hata component moja ikidhoofika siku zijazo, nyingine iendelee kulinda connection. Gharama yake ni keys, certificates, encrypted capsules na digital signatures kubwa zaidi.

Swali kuu la utafiti ni hili: Hybrid TLS 1.3 handshakes hizi nzito zaidi zinaweza kutoa acceptable performance hadi concurrent connections ngapi kwenye Linux-class edge IoT devices ambazo zina limitations zaidi kuliko data center lakini zina nguvu zaidi kuliko microcontrollers?

Hybrid post-quantum TLS 1.3 ina maana gani?

Hybrid structure hutumia classical na post-quantum algorithms pamoja katika key agreement na authentication. Katika utafiti, classical ECDH iliunganishwa na ML-KEM upande wa key encapsulation, na classical ECDSA ikaunganishwa na ML-DSA upande wa digital signature.

• ML-KEM: Module-lattice-based key encapsulation mechanism inayochangia kuunda TLS session key. Utafiti umetumia old implementation names Kyber-512, Kyber-768 na Kyber-1024.
• ML-DSA: Module-lattice-based digital signature standard inayosign server identity na handshake transcript. Utafiti umetumia ML-DSA-44, ML-DSA-65 na ML-DSA-87.
• ECDH: Classical elliptic-curve-based shared-key generation method.
• ECDSA: Classical elliptic-curve-based digital-signature method.

Hybrid structure inalenga connection kubaki protected mradi angalau classical au post-quantum component moja ibaki secure. Hata hivyo, utafiti hautathmini cryptographic security proof ya combination hii; unapima performance ya implemented configurations.

Ni security categories zipi zilijaribiwa?

L1/L2, L3 na L5 categories zinawakilisha takriban security levels zinazoongezeka. Security category inapoongezeka, public-key, private-key, capsule na signature sizes huongezeka.

Signature size iliyotumika katika hybrid certificate ni 2.495 bytes katika Hali 1, 3.418 bytes katika Hali 2 na 4.771 bytes katika Hali 3. Growth hii inaweza kuongeza si mathematical processing time pekee, bali pia gharama ya kusafirisha certificate kupitia TLS record layer na network.

Ni operations zipi hufanywa katika TLS 1.3 handshake?

Flow diagram kwenye ukurasa wa 4 inaonyesha basic sequence ya hybrid TLS 1.3 session:

1. Client huanzisha TCP connection.
2. Client hutuma ClientHello message yenye supported hybrid key groups na signature algorithms.
3. Server huunda shared secret kwa hybrid ML-KEM na ECDH components.
4. Server hutuma hybrid certificate na handshake signature.
5. Client hudecapsulate ML-KEM capsule na kuverify hybrid signature.
6. Baada ya pande zote kuverify Finished messages, encrypted application data husafirishwa.

Timing measurement katika utafiti haijumuishi TCP three-way connection setup. HTTP request na response pia zilipimwa separately baada ya TLS handshake kukamilika.

Ni roles gani halisi za devices katika experimental setup?

Kulingana na experimental setup kwenye ukurasa wa 6, Jetson Orin Nano na Raspberry Pi 4B ni client devices. TLS server inaendeshwa kwenye virtual machine yenye single virtual CPU ndani ya Dell Precision 5820 desktop yenye Xeon W-2155 processor.

Edge devices zote mbili ziliunganishwa wirelessly kwenye dedicated IEEE 802.11 access point, huku server ikiwa kwenye wired side ya network hiyo hiyo. Setup hii iliwezesha comparison ya edge devices mbili kwa software stack ile ile.

Hata hivyo, baadhi ya sehemu za utafiti zinataja “server roles” za Jetson na Raspberry Pi. Statement hii haioani na system model katika Figure 2 na detailed methods description. “Server-side time” katika result tables ni time iliyorekodiwa na common PC server; platform name inaonyesha edge client iliyoanzisha connection.

Kwa hiyo experiment haipaswi kutafsiriwa kama “physical devices 50 zinaunganishwa kwenye TLS server inayoendeshwa kwenye Jetson au Raspberry Pi”.

Concurrent client load ilitolewaje?

Kwenye kila edge device, C++ threads ziliundwa kwa idadi sawa na selected concurrent-user count. Kila thread ilirudia closed loop ifuatayo bila kusimama kwa dakika moja:

1. Kuanzisha TCP connection,
2. TLS 1.3 handshake,
3. Single HTTP POST request yenye body ya bytes 100,
4. Kupokea echo response kutoka server,
5. Kufunga connection,
6. Kuanza new connection.

HTTP persistent connection ilikuwa disabled. Kwa hiyo kila application request ilifanya new TCP connection na new TLS handshake.

Levels five, 10, 15, 20 na 50 hazionyeshi number of independent physical devices, bali number of concurrent connection threads zinazoendeshwa kwenye device ile ile. Pia hakuna think time au fixed request rate kati ya threads. Experiment ni closed-loop stress test inayozalisha continuous maximum load kuliko open-loop real-user arrival model.

Average handshake times zinaonyesha nini?

Security category ilipoongezeka, latency iliongezeka katika load levels zote. Kwa ten clients, L3 time upande wa Jetson ilikuwa mara 2,20 ya L1/L2, na L5 time mara 3,85. Kwa Raspberry Pi 4B, ratios hizo zilikuwa 2,61 na 5,38 mtawalia.

Results hizi zinaonyesha kwamba kuhamia kwenye larger key na signature structures za higher security categories hakuletei fixed extra delay, bali gharama inayotegemea platform na concurrent load.

Kauli ya “handshakes zote chini ya sekunde moja” inapaswa kusomwaje?

Kauli hii ni sahihi kwa arithmetic averages pekee. Katika L5 experiments zenye fifty clients, averages ni takriban sekunde 0,85–0,87. Hata hivyo, 95th-percentile latency ilifikia 1.792,5 ms kwa Jetson client na 1.780,9 ms kwa Raspberry Pi client.

Kwa maneno mengine, sehemu muhimu ya connections katika high load ilichukua muda mrefu zaidi kuliko average. Katika real-time systems au systems zenye strict latency limits, kuangalia average value pekee haitoshi.

Kwa nini scaling iliharibika baada ya takriban clients 20?

Kutoka five clients hadi 50 clients, average latency katika connections zilizoanzishwa na Jetson Orin Nano iliongezeka takriban mara 7,5–9,6 kutegemea configuration, na Raspberry Pi 4B takriban mara 9,5–10,8. Wakati client count iliongezeka mara 10, latency iliongezeka zaidi ya mara 10 katika baadhi ya conditions, jambo linaloonyesha superlinear scaling.

Utafiti unaunganisha growth hii hasa na request-processing contention upande wa server. Server:

• Inaendeshwa kwenye single virtual CPU.
• Huunda separate detached thread kwa kila new connection.
• Hutumia shared lock katika kila measurement event.
• Huflush file synchronously kwenda disk baada ya kila log row.

Scheduling ya fifty active connection threads kwenye single virtual CPU na kupitisha log records zote kupitia lock moja kunaweza kuunda queueing delay hata kabla CPU percentage haijafika %100.

Kwa hiyo result haionyeshi kwamba post-quantum TLS kiasili hufikia scaling limit katika clients 20. Inaonyesha zaidi kwamba threading na logging architecture iliyotumika kwenye utafiti ilianza kuunda latency karibu na point hii.

Je, post-quantum mathematics kweli si bottleneck?

Utafiti uliweka separate timing kwenye ML-KEM na ML-DSA entry points ndani ya liboqs kwa microsecond resolution. Server-side results katika ten-client experiment ni hizi:

Upande wa client, total key generation, signature verification na decapsulation chini ya L5 ni takriban 1,14 ms kwenye Jetson na 1,22 ms kwenye Raspberry Pi 4B. Measured OQS times za server na client zikiwekwa pamoja, zinatoa takriban %3,5–4,8 ya total handshake time katika ten-client experiments.

Hii inaonyesha kwa nguvu kwamba measured ML-KEM na ML-DSA cores zinaunda sehemu ndogo ya total time. Lakini haipaswi kupanuliwa kuwa “cryptography yote ina gharama ya %2–5”. Utafiti:

• Haukutime ECDH computation separately.
• Haukutime ECDSA signing na verification separately.
• Haujatenganisha OpenSSL key derivation na record-encryption operations.
• Haujapima certificate parsing na ASN.1 operations separately.

Kwa hiyo safe conclusion ni kwamba “measured post-quantum OQS operations si main latency component”.

Je, remaining latency imethibitishwa kutoka large hybrid messages?

Utafiti unaeleza large difference kati ya post-quantum processing time na total handshake kwa gharama za kusafirisha hybrid certificate, key-share na signature messages; TLS state machine; operating-system network stack; wireless link; thread scheduling na logging.

Interpretation hii inaendana na key na signature sizes zinazoongezeka. Hata hivyo, direct decomposition haikufanywa. Wakati wa experiment:

• Actual network bytes za TLS handshake hazikucaptureiwa.
• Connection RTT haikupimwa.
• Wi-Fi link speed na channel width hazikurekodiwa.
• RSSI na packet retransmissions hazijaripotiwa.
• Kernel-internal copying au system-call times hazikupimwa.

Kwa hiyo conclusion kwamba “data transport ndiyo main bottleneck” inategemea interpretation ya sehemu iliyobaki baada ya measured post-quantum processing time. Ni inference inayofaa lakini haijapimwa moja kwa moja.

Kwa nini Raspberry Pi 4B ilionekana haraka zaidi katika baadhi ya tests?

Raspberry Pi 4B iliendesha Cortex-A72 cores nne katika 1,8 GHz, huku Jetson Orin Nano ikiendesha Cortex-A78AE cores sita katika 1,5 GHz. Kwa kuwa single TLS handshake ni largely sequential, extra cores na GPU ya Jetson hazikupunguza moja kwa moja duration ya single session.

Katika L1/L2 configuration, Raspberry Pi 4B ilitoa average times fupi kwa %5–25. Katika L3 difference ilipungua, na katika L5 platforms mbili zilikaribiana.

Watafiti wanaeleza hii kwa umuhimu wa core clock speed katika small workloads na umuhimu wa cache na memory bandwidth katika larger L5 workloads. Interpretation hii inaendana na experimental trends; lakini boards mbili hazitofautiani kwa clock speed pekee. Microarchitecture, cache, memory type, operating system, wireless hardware na compiler effects pia hubadilika kwa pamoja.

Kwa hiyo utafiti haujathibitisha quantitatively ni sehemu gani hasa ya difference inatokana na clock speed au memory bandwidth.

Je, memory consumption ni kubwa kiasi cha kuzuia deployment?

Average server process memory ilikuwa takriban 12 MB kwa five clients na takriban 19–20 MB kwa 50 clients. Highest peak value ilikuwa 26,2 MB chini ya L5 na 50 clients.

Upande wa client kwa 50 connection threads, Jetson Orin Nano ilitumia average process memory ya takriban 36,8–38,2 MB, na Raspberry Pi 4B takriban 27,9–30,4 MB. Kwa kuwa devices zote mbili zina 8 GB system memory, values hizi ni sehemu ndogo ya total capacity.

Increase ya server memory imetafsiriwa kuwa takriban 150–200 kB per connection. Athari ya security category ni ndogo kuliko athari ya concurrent-client count.

Kwa nini CPU utilization ilipita asilimia 100?

Client CPU values ni aggregate ya cores zote. Jetson Orin Nano ina six cores, hivyo theoretical upper bound ni %600; Raspberry Pi 4B ina four cores, hivyo ni %400.

Kwa fifty clients, highest average value ya Jetson ilikuwa %298 na highest value ya Raspberry Pi 4B ilikuwa %211. Values hizi ni takriban nusu ya total capacity.

Server imewekewa single virtual CPU na theoretical upper bound ni %100. Highest average server utilization ilipimwa kuwa %43. Low CPU utilization haimaanishi hakuna waiting. Disk writes, locks, network na scheduler waits zinaweza kuongeza latency bila kutumia CPU.

Kwa nini classical TLS comparison ni muhimu?

Classical TLS 1.3 configuration inayotumia ECDH/ECDSA pekee haikujaribiwa katika same hardware na network conditions. Kwa hiyo values zifuatazo haziwezi kutolewa kutoka utafiti:

• Hybrid TLS ni slower kwa asilimia ngapi kuliko classical TLS,
• Ni additional bytes ngapi zilitumwa kwa sababu ya hybrid structure,
• Concurrent-client scaling ya classical TLS ikoje,
• Ni sehemu gani ya degradation baada ya clients 20 ni PQC-specific.

Utafiti unalinganisha hybrid security categories tatu na kila mmoja; hautoi direct experimental difference kati ya classical na hybrid TLS.

Ni conclusions zipi zinaungwa mkono na utafiti?

• Hybrid TLS 1.3 configurations tatu zenye ML-KEM na ML-DSA ziliendeshwa kwa mafanikio kwenye Jetson Orin Nano na Raspberry Pi 4B clients.
• Average handshake time ilibaki chini ya sekunde moja katika tested conditions zote.
• Security category ilipoongezeka, handshake time na measured post-quantum processing time ziliongezeka.
• Measured ML-KEM na ML-DSA operations ziliunda sehemu ndogo ya total handshake time.
• Katika high concurrency, average na 95th-percentile latency zilikua zaidi ya linear.
• Server na client processes hazikutumia total CPU na memory capacity yote katika tested loads.
• Katika single-session sequential workload, high core count au uwepo wa GPU haukutoa automatically shorter handshake.

Utafiti hauthibitishi nini?

• Hauonyeshi kwamba edge boards kama TLS server zinaweza kupokea 50 independent physical clients.
• Haupimi additional cost ya post-quantum TLS dhidi ya classical TLS.
• Hauthibitishi kwamba cryptographic operations zote zina gharama ya %2–5 pekee.
• Haionyeshi exactly ni sehemu gani ya remaining latency inatokana na network, operating system, copying au logging.
• Haionyeshi kwamba scaling threshold ya takriban clients 20 inatumika pia katika server architectures nyingine.
• Haupimi energy consumption.
• Hautathmini mutual TLS authentication, session resumption au zero-round-trip connection setup.
• Hauwakilishi mobile network, real industrial traffic au long-distance internet connection conditions.
• Haionyeshi kwamba Raspberry Pi 4B itakuwa faster kuliko Jetson Orin Nano kwenye edge IoT boards zote.

Mbinu na Matokeo ya Utafiti

Hardware setup

Software stack

Experimental matrix

Total number of experiments inatokana na multiplication hii:

2 client platforms × 3 security configurations × 5 concurrent connection levels = 30 experiments

Kila experiment ilidumu dakika moja. Number of completed handshakes ilibadilika kutoka 2.268 hadi 10.641 kulingana na condition.

Watafiti wameeleza difference ya records 99 kuwa connections zilizokamilika kwenye server mwishoni mwa one-minute window lakini hazikuandikwa upande wa client wakati client process ilipofungwa.

Measurement tools

TLS handshake time ilipimwa kama wall-clock duration ya stream.handshake() call kwenye client na server. TCP connection establishment na HTTP data transfer hazikujumuishwa katika duration hii.

ML-KEM na ML-DSA stages zilitimiwa separately kwa patched liboqs:

• OQS_KEM_keypair: Key-pair generation,
• OQS_KEM_encaps: Encapsulation,
• OQS_KEM_decaps: Decapsulation,
• OQS_SIG_sign: Signature generation,
• OQS_SIG_verify: Signature verification.

Memory na CPU utilization zilisampleiwa kwa pidstat kila sekunde five. Idadi ndogo ya system samples katika one-minute experiment inapunguza uwezo wa kutafsiri fluctuations, hasa katika intermediate load levels.

Additional overhead iliyoundwa na measurement system yenyewe

Kila handshake na cryptographic-operation record iliandikwa kwenye file kupitia shared mutex, na baada ya kila row flush() au fflush() iliitwa. Hii ilipunguza data loss lakini multiple threads zililazimika kusubiri same file lock na disk-write path.

Kwa kuwa code ile ile ilitumiwa katika experiments zote, effect hii haiondoi kabisa consistency ya comparisons. Hata hivyo, measurement-system latency yenyewe huongezeka concurrency inapoongezeka, hivyo high-load results haziwakilishi moja kwa moja bare TLS server katika production environment.

Client-side post-quantum processing times

Highest single operation upande wa client ni signature verification. Security category ilipoongezeka, time katika stages zote iliongezeka, lakini total OQS time ilibaki chini ya takriban 1,2 ms katika ten-client condition.

Umuhimu wa 95th-percentile latency

Kwa five clients, ratio ya 95th-percentile value kwa average ilikuwa takriban 1,4–1,5 katika conditions nyingi. Kwa ten clients, ratio iliongezeka hadi takriban 1,5–1,7. Kwa fifty clients iliongezeka hadi takriban 2,0–2,2.

Widening hii inaonyesha kwamba katika high load si average tu iliyoongezeka, bali performance variability kati ya connections pia iliongezeka. Queue formation ilifanya baadhi ya handshakes kuchukua muda mrefu zaidi kuliko nyingine.

Server memory na CPU values

Server data ilirekodiwa kikamilifu wakati wa experiments za Jetson client. Parallel server records katika Raspberry Pi experiments zilikuwa incomplete, hivyo hazikutumiwa katika main table. Ingawa server software na hardware zilikuwa zile zile, missing data hii inazuia direct comparison ya server resource consumption kati ya experiment groups mbili.

Application message sizes zinaonyesha nini?

Server ilipokea bytes 237 na kutuma bytes 219 katika application layer kwa kila experiment. Ni expected kwamba values hizi hazibadiliki kwa security category, kwa sababu measured section ni fixed HTTP request na response zinazotumwa baada ya handshake.

Numbers hizi hazionyeshi network size ya hybrid TLS certificates, key shares au handshake signatures. Actual handshake traffic haikupimwa kwa packet capture.

Experiments zinazohitajika kuongeza reliability ya results

• Kuongeza classical-only TLS 1.3 baseline kwa same hardware na software,
• Kujaribu Jetson Orin Nano na Raspberry Pi 4B separately katika TLS server role,
• Kuzalisha distributed load kwa independent physical clients,
• Kutumia controlled open-loop request rates badala ya closed loop,
• Kulinganisha event-driven server na fixed worker pool dhidi ya thread-per-connection model,
• Kubuffer measurement logs kwenye memory na kuziandika baada ya experiment,
• Kujaribu multiple virtual CPUs na different server-core counts,
• Kupima actual byte size ya TLS handshake kwa packet capture,
• Kurekodi RTT, RSSI, Wi-Fi speed, channel width na packet retransmissions,
• Kurudia kila condition kama multiple independent experiments katika different times,
• Kupima energy consumption moja kwa moja kwa external power meter,
• Kuchunguza mutual TLS, session resumption na long-lived connection scenarios,
• Kufanya external validation kwa Raspberry Pi 5, different ARM boards, industrial gateways na microcontrollers,
• Kulinganisha other post-quantum algorithms kama HQC pamoja na ML-KEM.

Dokezo la Chanzo na Mbinu

Jina kamili la awali la utafiti: Performance and Scalability of Hybrid Post-Quantum TLS 1.3 on Edge IoT Platforms under Concurrent-Client Load

Waandishi: Togu Novriansyah Turnip, Birger Andersen na César Vargas-Rosales

Mpangilio wa waandishi: Togu Novriansyah Turnip; Birger Andersen; César Vargas-Rosales

Equal-contribution information: Hakuna equal-contribution au co-first-authorship statement katika utafiti.

Corresponding author: Togu Novriansyah Turnip

Institutions:

• 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

Journal: Utafiti haujachapishwa katika journal.

Original journal publisher: Hakuna.

Publication platform: SSRN

Upload date: 24 Juni 2026

Publication year: 2026

Page count: 19

Source type: Controlled experimental network na system-performance preprint

Peer-review status: Utafiti haujapitia peer review. Kila page ina warning ya “Preprint not peer reviewed”.

Official link:SSRN study page

Source code: Watafiti wameripoti kwamba open-source code ya lily-pqc application iliyotumika katika experiments imeshirikiwa katika GitHub repository.

Funding: Utafiti uliungwa mkono na scholarship ya Technical University of Denmark. Togu Novriansyah Turnip pia ameripoti kupokea travel support kutoka Otto Mønsted Foundation.

Conflict disclosure: Togu Novriansyah Turnip ametangaza DTU funding na travel-reimbursement relationship na Otto Mønsted Foundation. Watafiti wengine hawakuripoti known financial au personal relationship inayoweza kuathiri utafiti.

Makala hii ya Kiswahili imeandaliwa kwa kupitia full text, tables, graphs na diagrams za uploaded study yenye kurasa 19. Scientific method, hardware specifications, connection counts, latencies, memory values na cryptographic processing times zinategemea tu data iliyowasilishwa katika utafiti. External sources zilitumika tu kwa bibliographic verification ya title, authors, institutions, DOI, platform, upload date na publication status.

Kuna inconsistency inayohitaji uangalifu katika system-role descriptions za utafiti. Katika methods na experimental diagram, Jetson Orin Nano na Raspberry Pi 4B ni clients na PC ndiyo server; baadhi ya later statements zinataja boards kana kwamba ziko katika server role. Makala hii imetumia visual experimental setup na detailed methods description kama msingi.

Katika KEMTLS evaluation ya discussion section, Raspberry Pi 4B L5 signature-generation time imeandikwa kuwa takriban 0,64 ms. Kulingana na main result table, signature generation ni 3,193 ms, huku 0,637 ms ikiwa encapsulation time. Kwa hiyo Kiswahili kimetumia value ya main result table.

Ratio ya %2–5 katika utafiti inajumuisha tu post-quantum operations zilizotimiwa na patched liboqs. Classical elliptic-curve operations na sehemu nyingine ya TLS stack hazikupimwa separately, hivyo ratio hii haijawasilishwa kama “total cryptography cost”.

Results zinatumika kwa server yenye single virtual CPU, thread-per-connection, synchronous locked logging, fixed wireless test environment na one-minute experimental windows. Capacity, latency na energy consumption katika real production systems lazima zivalidateiwe separately.