Ин таҳқиқот performance-и hybrid TLS 1.3 configuration-ҳоро дар edge IoT hardware-и қобили иҷрои Linux омӯхтааст, ки classical elliptic-curve cryptography-ро бо post-quantum ML-KEM ва ML-DSA algorithm-ҳои аз ҷониби NIST standardized якҷоя мекунанд. NVIDIA Jetson Orin Nano ва Raspberry Pi 4B client-ҳо дар security category-ҳои L1/L2, L3 ва L5 бо 5, 10, 15, 20 ва 50 concurrent connection thread санҷида шуданд. Дар total 30 experiment, 160.584 server-side ва 160.485 client-side handshake record сохта шуд; handshake latency, ML-KEM ва ML-DSA processing time, memory consumption, CPU utilization ва 95th-percentile queue latency чен шуданд.

Average TLS handshake time дар ҳамаи experimental conditions зери як сония монд. Аз five client ба 50 client гузаштан average latency-ро вобаста ба configuration ва platform тақрибан 7,5–10,8 маротиба зиёд кард. Scaling то тақрибан 20 concurrent connection нисбатан мунтазам буд, вале байни 20 ва 50 connection growth аз linear зиёд шуд. Дар fifty client, L5 average барои connection-ҳои аз Jetson Orin Nano оғозшуда 848,8 ms ва барои connection-ҳои аз Raspberry Pi 4B оғозшуда 870,0 ms буд. 95th-percentile value дар ҳамон conditions тақрибан ба 1,79 сония расид.

Дар таҳқиқот separately timed post-quantum ML-KEM ва ML-DSA operation-ҳо тақрибан %2–5-и total handshake time-ро ташкил карданд. Дар server, most expensive post-quantum operation hybrid signature generation бар пояи ML-DSA ва дар client signature verification буд. Бо вуҷуди ин, ин ratio cost-и ҳамаи cryptographic operation-ҳо нест; classical ECDH ва ECDSA stage-ҳо separate timing надоштанд. Илова бар ин, actual byte size-и handshake дар network ва wireless-link latency сабт нашудааст, аз ин рӯ direct determination-и он ки қисми боқимондаи time чӣ қадар аз certificate transfer, TLS record processing, operating system, network ё measurement logging меояд, имконнопазир аст.

Аз нигоҳи Туркия: Findings барои team-ҳое, ки smart-factory network, industrial IoT gateway, energy ва transportation system, local AI node ва long-lived secure communication infrastructure дар Туркия таҳия мекунанд, аҳамият доранд. Таҳқиқот нишон медиҳад, ки post-quantum TLS дар Raspberry Pi ва Jetson-class device-ҳо иҷро мешавад, аммо concurrent-connection architecture бояд боэҳтиёт design шавад. Пеш аз implementation decision дар Туркия бояд new tests бо local hardware models, real operator ва institutional networks, wired ва wireless links, classical TLS comparison, mutual authentication, long-duration load, electrical energy consumption ва real certificate chains анҷом шаванд. Аз ин таҳқиқот наметавон хулоса кард, ки дар ҳамаи edge system-ҳои Туркия ҳамон latency дида мешавад, 50 physical device бе мушкил support мешаванд ё post-quantum transition танҳо бо software update анҷом меёбад.

Саволи асосии таҳқиқот чист?

TLS 1.3 яке аз security protocol-ҳои асосӣ мебошад, ки confidentiality ва authentication-и client–server connection-ҳоро дар internet ва private networks таъмин мекунад. Аммо classic public-key method-ҳое, ки TLS 1.3 имрӯз истифода мебарад, метавонад ҳангоми пайдо шудани quantum computer-ҳои ба қадри кофӣ пурқувват шикаста шаванд.

Ин risk танҳо future connection-ҳоро дар бар намегирад. Encrypted traffic метавонад имрӯз recorded шуда, баъдтар бо quantum computer decrypted шавад. Барои industrial, healthcare, public-sector ё critical-infrastructure data, ки бояд long-term confidential бимонад, ин ҳолат threat-и “harvest now, decrypt later” эҷод мекунад.

Яке аз approach-ҳои пешниҳодшуда барои transition period истифодаи classical ва post-quantum methods дар як TLS handshake мебошад. Ҳадаф ин аст, ки агар яке аз ду component дар future weak шавад, component-и дигар connection-ро муҳофизат кунад. Cost-и ин approach larger keys, certificates, encrypted capsules ва digital signatures мебошад.

Саволи асосии таҳқиқот чунин аст: Ин heavier hybrid TLS 1.3 handshakes дар Linux-class edge IoT devices, ки аз data center маҳдудтар, аммо аз microcontroller пурқувваттаранд, то чанд concurrent connection acceptable performance медиҳанд?

Hybrid post-quantum TLS 1.3 чӣ маъно дорад?

Hybrid structure classical ва post-quantum algorithm-ҳоро дар key agreement ва authentication якҷоя истифода мебарад. Дар таҳқиқот classical ECDH бо ML-KEM дар key encapsulation ва classical ECDSA бо ML-DSA дар digital signature pair шудаанд.

• ML-KEM: Module-lattice-based key encapsulation mechanism, ки дар сохтани TLS session key саҳм мегирад. Дар таҳқиқот old implementation names Kyber-512, Kyber-768 ва Kyber-1024 истифода шудаанд.
• ML-DSA: Module-lattice-based digital signature standard, ки server identity ва handshake transcript-ро имзо мекунад. Дар таҳқиқот ML-DSA-44, ML-DSA-65 ва ML-DSA-87 истифода шудаанд.
• ECDH: Classical elliptic-curve-based shared-key generation method.
• ECDSA: Classical elliptic-curve-based digital-signature method.

Hybrid structure ҳадаф дорад, ки connection то вақте protected бошад, ки ҳадди ақал яке аз classical ё post-quantum component secure мемонад. Аммо таҳқиқот cryptographic security proof-и ин combination-ро evaluate намекунад; performance-и implemented configurations-ро чен мекунад.

Кадом security category-ҳо санҷида шуданд?

Category-ҳои L1/L2, L3 ва L5 тақрибан security level-ҳои progressively higher-ро ифода мекунанд. Бо баланд шудани security category, public key, private key, capsule ва signature size зиёд мешаванд.

Signature size-и дар hybrid certificate истифодашуда дар Ҳолат 1 2.495 byte, дар Ҳолат 2 3.418 byte ва дар Ҳолат 3 4.771 byte мебошад. Ин growth на танҳо mathematical processing time, балки cost-и интиқоли certificate аз TLS record layer ва network-ро низ зиёд карда метавонад.

Дар TLS 1.3 handshake кадом operation-ҳо иҷро мешаванд?

Flow diagram дар саҳифаи 4 sequence-и асосии hybrid TLS 1.3 session-ро нишон медиҳад:

1. Client TCP connection месозад.
2. Client ClientHello message-ро бо supported hybrid key groups ва signature algorithms мефиристад.
3. Server shared secret-ро бо hybrid ML-KEM ва ECDH component месозад.
4. Server hybrid certificate ва handshake signature-ро мефиристад.
5. Client ML-KEM capsule-ро decapsulate ва hybrid signature-ро verify мекунад.
6. Пас аз verify кардани Finished message-ҳо encrypted application data интиқол меёбад.

Timing measurement дар таҳқиқот TCP three-way connection setup-ро дар бар намегирад. HTTP request ва response низ пас аз анҷоми TLS handshake separate measurement дошт.

Ролҳои воқеии device-ҳо дар experimental setup чӣ буданд?

Мувофиқи setup дар саҳифаи 6, Jetson Orin Nano ва Raspberry Pi 4B client device мебошанд. TLS server дар virtual machine бо single virtual CPU дар desktop Dell Precision 5820 бо Xeon W-2155 processor кор мекунад.

Ҳар ду edge device ба dedicated IEEE 802.11 access point wireless пайваст шуда, server дар wired side-и ҳамон network ҷойгир буд. Ин setup comparison-и ду edge device-ро бо same software stack имкон дод.

Бо вуҷуди ин, баъзе қисмҳои таҳқиқот аз “server roles”-и Jetson ва Raspberry Pi сухан мегӯянд. Ин statement бо system model дар Figure 2 ва detailed method explanation мувофиқ нест. “Server-side time” дар result table time-и recorded аз common PC server-ро нишон медиҳад; platform name бошад edge client-еро, ки connection-ро оғоз кардааст.

Аз ин рӯ, experiment набояд ҳамчун “50 physical device ба TLS server running on Jetson ё Raspberry Pi мепайвандад” тафсир шавад.

Concurrent client load чӣ гуна тавлид шуд?

Дар ҳар edge device ҳамон қадар C++ thread сохта шуд, ки selected concurrent user count буд. Ҳар thread дар тӯли як дақиқа closed loop-и зеринро continuous такрор кард:

1. TCP connection establish,
2. TLS 1.3 handshake,
3. Single HTTP POST request бо 100-byte body,
4. Receive echo response аз server,
5. Close connection,
6. Start new connection.

HTTP persistent connection disabled буд. Аз ин рӯ, барои ҳар application request new TCP connection ва new TLS handshake иҷро шуд.

Level-ҳои five, 10, 15, 20 ва 50 number of independent physical devices-ро не, number of concurrent connection threads дар same device нишон медиҳанд. Илова бар ин, байни threads think time ё fixed request rate вуҷуд надорад. Experiment closed-loop stress test аст, ки continuous maximum load тавлид мекунад, на open-loop real-user arrival model.

Average handshake time-ҳо чиро нишон медиҳанд?

Бо баланд шудани security category, latency дар ҳамаи load level-ҳо зиёд шуд. Дар ten client, L3 time дар Jetson 2,20 маротиба L1/L2 ва L5 time 3,85 маротиба аст. Дар Raspberry Pi 4B ratio-ҳои corresponding 2,61 ва 5,38 мебошанд.

Ин findings нишон медиҳанд, ки гузариш ба larger key ва signature structure дар higher security category fixed extra delay намедиҳад; cost аз platform ва concurrent load вобаста аст.

Натиҷаи “ҳамаи handshake-ҳо зери як сония” чӣ гуна хонда шавад?

Ин statement танҳо барои arithmetic mean дуруст аст. Дар L5 experiments бо fifty client average тақрибан 0,85–0,87 сония буд. Аммо 95th-percentile latency бо Jetson client ба 1.792,5 ms ва бо Raspberry Pi client ба 1.780,9 ms расид.

Ба ибораи дигар, дар high load қисми муҳими connection-ҳо аз average хеле дарозтар буданд. Дар real-time system ё system бо strict latency bound танҳо average value кофӣ нест.

Чаро scaling пас аз тақрибан 20 client бад шуд?

Аз five client ба 50 client average latency дар connection-ҳои аз Jetson Orin Nano оғозшуда вобаста ба configuration тақрибан 7,5–9,6 маротиба ва дар Raspberry Pi 4B тақрибан 9,5–10,8 маротиба зиёд шуд. Дар ҳоле ки client count 10 маротиба зиёд шуд, latency дар баъзе conditions зиёда аз 10 маротиба афзуд, ки superlinear scaling-ро нишон медиҳад.

Таҳқиқот ин growth-ро пеш аз ҳама ба request-processing contention дар server side нисбат медиҳад. Server:

• Дар single virtual CPU кор мекунад.
• Барои ҳар new connection separate detached thread месозад.
• Дар ҳар measurement event shared lock истифода мебарад.
• Пас аз ҳар log row file-ро synchronously ба disk flush мекунад.

Scheduling-и fifty active connection thread дар single virtual CPU ва гузаронидани ҳамаи log record-ҳо аз як lock метавонад ҳатто пеш аз расидани CPU ба %100 queueing delay эҷод кунад.

Аз ин рӯ, result нишон намедиҳад, ки post-quantum TLS табиатан дар 20 client scaling limit дорад. Бештар нишон медиҳад, ки threading ва logging architecture-и ин study тақрибан дар ҳамин point latency тавлид мекунад.

Оё post-quantum mathematics воқеан bottleneck нест?

Таҳқиқот ML-KEM ва ML-DSA entry point-ҳоро дар liboqs бо microsecond resolution separate timing кардааст. Server-side result дар ten-client experiment чунин аст:

Дар client side total key generation, signature verification ва decapsulation зери L5 дар Jetson тақрибан 1,14 ms ва Raspberry Pi 4B 1,22 ms аст. Вақте measured OQS time-и server ва client якҷоя гирифта мешавад, дар ten-client experiments тақрибан %3,5–4,8-и total handshake time ҳосил мешавад.

Ин strongly нишон медиҳад, ки measured ML-KEM ва ML-DSA core-ҳо қисми хурди total time мебошанд. Аммо набояд ба statement-и “ҳамаи cryptography танҳо %2–5 cost дорад” васеъ карда шавад. Таҳқиқот:

• ECDH computation-ро separate timing накардааст.
• ECDSA signing ва verification-ро separate timing накардааст.
• OpenSSL key derivation ва record-encryption operation-ҳоро ҷудо накардааст.
• Certificate parsing ва ASN.1 operation-ҳоро separate measurement накардааст.

Аз ин рӯ, safe conclusion ин аст: “measured post-quantum OQS operations main latency component нестанд.”

Оё исбот шудааст, ки remaining latency аз large hybrid messages меояд?

Таҳқиқот large difference байни post-quantum processing time ва total handshake-ро ба интиқоли hybrid certificate, key-share ва signature messages; TLS state machine; operating-system network stack; wireless link; thread scheduling ва logging нисбат медиҳад.

Ин interpretation бо growing key ва signature size мувофиқ аст. Аммо direct decomposition анҷом нашудааст. Дар experiment:

• Actual network bytes-и TLS handshake capture нашудаанд.
• Connection RTT чен нашудааст.
• Wi-Fi link speed ва channel width сабт нашудаанд.
• RSSI ва packet retransmission report нашудаанд.
• Kernel-internal copy ё system-call times чен нашудаанд.

Аз ин рӯ, “data transport main bottleneck аст” conclusion ба interpretation-и қисми боқимонда баъд аз measured post-quantum processing time такя мекунад. Ин reasonable, аммо directly measured нест.

Чаро Raspberry Pi 4B дар баъзе tests тезтар намудор шуд?

Raspberry Pi 4B чор Cortex-A72 core-ро дар 1,8 GHz ва Jetson Orin Nano шаш Cortex-A78AE core-ро дар 1,5 GHz кор медарорад. Азбаски single TLS handshake асосан sequential аст, extra core ва GPU-и Jetson time-и single session-ро мустақим кам накардааст.

Дар L1/L2 configuration Raspberry Pi 4B average %5–25 shorter times дод. Дар L3 gap танг шуд ва дар L5 two platform ба ҳам наздик шуданд.

Researchers инро бо аҳамияти core clock rate дар small workload ва cache ва memory bandwidth дар larger L5 workload шарҳ медиҳанд. Ин explanation бо experimental trends мувофиқ аст; аммо boards танҳо дар clock rate фарқ намекунанд. Microarchitecture, cache, memory type, operating system, wireless hardware ва compiler effects ҳамзамон тағйир меёбанд.

Аз ин рӯ, study quantitative proof намедиҳад, ки exactly чӣ қисми difference аз clock rate ё memory bandwidth омадааст.

Оё memory consumption барои deployment хеле баланд аст?

Average server process memory тақрибан 12 MB дар five client ва тақрибан 19–20 MB дар 50 client буд. Highest peak value зери L5 ва 50 client 26,2 MB аст.

Дар client side бо 50 connection threads Jetson Orin Nano тақрибан 36,8–38,2 MB ва Raspberry Pi 4B тақрибан 27,9–30,4 MB average process memory истифода кард. Азбаски ҳар ду device 8 GB system memory доранд, ин values қисми хурди total capacity мебошанд.

Increase дар server memory ҳамчун тақрибан 150–200 kB per connection interpretation шудааст. Таъсири security category нисбат ба concurrent-client count хурдтар аст.

Чаро CPU utilization аз 100 percent боло рафт?

Client CPU values aggregate across all cores мебошанд. Jetson Orin Nano six core дорад, аз ин рӯ theoretical upper bound %600; Raspberry Pi 4B four core дорад, аз ин рӯ %400.

Дар fifty client highest average value-и Jetson %298 ва highest value-и Raspberry Pi 4B %211 аст. Ин values тақрибан ба half of total capacity мувофиқанд.

Server ба single virtual CPU маҳдуд аст ва theoretical upper bound %100. Highest average server utilization %43 чен шудааст. Low CPU utilization маънои absence of waiting-ро надорад. Disk write, lock, network ва scheduler wait метавонанд latency-ро бе CPU consumption зиёд кунанд.

Чаро classical TLS comparison муҳим аст?

Дар same hardware ва network conditions classical TLS 1.3 configuration, ки танҳо ECDH/ECDSA истифода мекунад, санҷида нашудааст. Аз ин рӯ, study values-и зеринро намедиҳад:

• Hybrid TLS чанд percent slower аз classical TLS аст,
• Чанд additional byte аз hybrid structure фиристода шудааст,
• Concurrent-client scaling-и classical TLS чӣ гуна аст,
• Чӣ қисми degradation пас аз 20 client PQC-specific аст.

Таҳқиқот се hybrid security category-ро бо ҳам comparison мекунад; direct experimental difference байни classical ва hybrid TLS пешниҳод намекунад.

Кадом conclusions аз study supported мебошанд?

• Се hybrid TLS 1.3 configuration бо ML-KEM ва ML-DSA дар Jetson Orin Nano ва Raspberry Pi 4B clients successfully run шуданд.
• Average handshake time дар ҳамаи tested conditions зери як сония монд.
• Бо баланд шудани security category handshake time ва measured post-quantum processing time зиёд шуданд.
• Measured ML-KEM ва ML-DSA operations қисми хурди total handshake time буданд.
• Дар high concurrency average ва 95th-percentile latency superlinear growth нишон доданд.
• Server ва client processes дар tested loads total CPU ва memory capacity-ро exhaust накарданд.
• Дар single-session sequential workload high core count ё GPU presence automatically shorter handshake надод.

Таҳқиқот чиро исбот намекунад?

• Нишон намедиҳад, ки edge boards ҳамчун TLS server 50 independent physical client-ро қабул карда метавонанд.
• Additional cost-и post-quantum TLS нисбат ба classical TLS-ро чен намекунад.
• Исбот намекунад, ки ҳамаи cryptographic operations танҳо %2–5 cost доранд.
• Нишон намедиҳад, ки exactly кадом қисми remaining latency аз network, operating system, copying ё logging меояд.
• Нишон намедиҳад, ки scaling threshold-и тақрибан 20 client дар other server architectures низ амал мекунад.
• Energy consumption-ро чен намекунад.
• Mutual TLS authentication, session resumption ё zero-round-trip connection setup-ро evaluate намекунад.
• Mobile network, real industrial traffic ё long-distance internet connection conditions-ро represent намекунад.
• Нишон намедиҳад, ки Raspberry Pi 4B дар ҳамаи edge IoT boards аз Jetson Orin Nano тезтар мешавад.

Усул ва бозёфтҳои таҳқиқот

Hardware setup

Software stack

Experimental matrix

Total number of experiments аз multiplication-и зерин аст:

2 client platform × 3 security configuration × 5 concurrent connection level = 30 experiment

Ҳар experiment як дақиқа давом кард. Number of completed handshakes вобаста ба condition байни 2.268 ва 10.641 буд.

Researchers фарқи 99 record-ро бо connection-ҳое шарҳ медиҳанд, ки server онҳоро дар охири one-minute window completed кардааст, аммо ҳангоми shutdown-и client process ба client log навишта нашудаанд.

Measurement tools

TLS handshake time ҳамчун wall-clock duration-и stream.handshake() call дар client ва server чен шуд. TCP connection establishment ва HTTP data transfer аз ин timing хориҷ буданд.

ML-KEM ва ML-DSA stages бо patched liboqs separately timed шуданд:

• 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 ва CPU utilization бо pidstat ҳар five seconds sample шуданд. Few system samples дар one-minute experiment interpretation-и fluctuations, махсусан дар intermediate load levels, маҳдуд мекунад.

Overhead-и худи measurement system

Ҳар handshake ва cryptographic-operation record тавассути shared mutex ба file навишта шуда, пас аз ҳар row flush() ё fflush() call шудааст. Ин data loss-ро кам кард, вале multiple threads маҷбур шуданд барои same file lock ва disk-write path интизор шаванд.

Азбаски same code дар ҳамаи experiments истифода шудааст, ин effect consistency-и comparison-ҳоро пурра нест намекунад. Аммо measurement system delay бо concurrency зиёд мешавад, аз ин рӯ high-load result-ҳо direct representation-и bare TLS server дар production environment нестанд.

Client-side post-quantum processing times

Highest single operation дар client signature verification буд. Бо баланд шудани security category time дар ҳамаи stages зиёд шуд, аммо total OQS time дар ten-client condition зери тақрибан 1,2 ms монд.

Аҳамияти 95th-percentile latency

Дар five client ratio-и 95th-percentile value ба mean дар аксари conditions тақрибан 1,4–1,5 буд. Дар ten client ratio тақрибан 1,5–1,7 ва дар fifty client тақрибан 2,0–2,2 шуд.

Ин widening нишон медиҳад, ки дар high load на танҳо mean зиёд мешавад, балки performance variability байни connections низ меафзояд. Queue formation баъзе handshake-ҳоро аз дигарон хеле дарозтар кардааст.

Server memory ва CPU values

Server data ҳангоми experiments бо Jetson client complete recorded шуд. Parallel server record-ҳо дар Raspberry Pi experiments incomplete буданд ва дар main table истифода нашуданд. Гарчанде server software ва hardware same буданд, ин missing data direct comparison-и server resource consumption байни experiment groups-ро маҳдуд мекунад.

Application message sizes чиро нишон медиҳанд?

Server дар ҳар experiment дар application layer 237 byte received ва 219 byte sent кардааст. Expected аст, ки ин values бо security category тағйир намекунанд, зеро measured section fixed HTTP request ва response пас аз handshake мебошад.

Ин numbers network size-и hybrid TLS certificate, key share ё handshake signature-ро нишон намедиҳанд. Actual handshake traffic бо packet capture чен нашудааст.

Experiments-и зарурӣ барои баланд кардани reliability

• Илова кардани classical-only TLS 1.3 baseline бо same hardware ва software,
• Separate testing-и Jetson Orin Nano ва Raspberry Pi 4B дар TLS server role,
• Тавлиди distributed load бо independent physical clients,
• Истифодаи controlled open-loop request rates ба ҷои closed loop,
• Comparison-и event-driven server ва fixed worker pool бо thread-per-connection model,
• Buffer кардани measurement logs дар memory ва writing пас аз experiment,
• Testing-и multiple virtual CPU ва different server-core counts,
• Measurement-и actual byte size-и TLS handshake бо packet capture,
• Recording-и RTT, RSSI, Wi-Fi speed, channel width ва packet retransmission,
• Repeat кардани ҳар condition ҳамчун multiple independent experiments дар different times,
• Direct measurement-и energy consumption бо external power meter,
• Evaluation-и mutual TLS, session resumption ва long-lived connection scenarios,
• External validation бо Raspberry Pi 5, other ARM boards, industrial gateways ва microcontrollers,
• Comparison-и other post-quantum algorithms мисли HQC ғайр аз ML-KEM.

Ёддошти манбаъ ва усул

Номи пурраи аслии таҳқиқот: Performance and Scalability of Hybrid Post-Quantum TLS 1.3 on Edge IoT Platforms under Concurrent-Client Load

Муаллифон: Togu Novriansyah Turnip, Birger Andersen ва César Vargas-Rosales

Тартиби муаллифон: Togu Novriansyah Turnip; Birger Andersen; César Vargas-Rosales

Equal contribution: Equal contribution ё co-first-authorship statement вуҷуд надорад.

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: Таҳқиқот дар journal нашр нашудааст.

Original journal publisher: Нест.

Publication platform: SSRN

Upload date: 24 июни 2026

Publication year: 2026

Page count: 19

Source type: Controlled experimental network ва system-performance preprint

Peer-review status: Таҳқиқот аз peer review нагузаштааст. Дар ҳар page warning-и “Preprint not peer reviewed” ҳаст.

Official link:SSRN study page

Source code: Researchers гуфтаанд, ки open-source code-и lily-pqc application-и дар experiments истифодашуда дар GitHub repository shared шудааст.

Funding: Таҳқиқот бо scholarship-и Technical University of Denmark supported шудааст. Togu Novriansyah Turnip инчунин travel support аз Otto Mønsted Foundation гирифтааст.

Conflict disclosure: Togu Novriansyah Turnip DTU funding ва travel-reimbursement relationship бо Otto Mønsted Foundation-ро disclosed кардааст. Other researchers known financial ё personal relationship-и таъсиррасон ба study report накардаанд.

Ин мақолаи тоҷикӣ бо review-и full text, tables, graphs ва diagrams-и uploaded 19-page study омода шудааст. Scientific method, hardware specifications, connection counts, latencies, memory values ва cryptographic processing times танҳо ба data-и дар study пешниҳодшуда такя мекунанд. External sources танҳо барои bibliographic verification-и title, authors, institutions, DOI, platform, upload date ва publication status истифода шудаанд.

Дар explanation-и system roles як inconsistency вуҷуд дорад. Дар method ва experimental diagram Jetson Orin Nano ва Raspberry Pi 4B client ва PC server мебошанд; баъзе later statements boards-ро мисли server role тавсиф мекунанд. Дар ин article visual experimental setup ва detailed method explanation basis гирифта шудаанд.

Дар KEMTLS discussion Raspberry Pi 4B L5 signature-generation time тақрибан 0,64 ms навишта шудааст. Мувофиқи main result table signature generation 3,193 ms ва 0,637 ms encapsulation time мебошад. Аз ин рӯ, дар тоҷикӣ main result table value истифода шудааст.

Ratio-и %2–5 танҳо post-quantum operations-ро дар бар мегирад, ки patched liboqs timing кардааст. Classical elliptic-curve operations ва remaining TLS stack separate measurement надоштанд, аз ин рӯ ratio ҳамчун “total cryptography cost” пешниҳод нашудааст.

Натиҷаҳо барои server бо single virtual CPU, thread-per-connection, synchronous locked logging, fixed wireless test environment ва one-minute experimental windows амал мекунанд. Capacity, latency ва energy consumption дар real production systems бояд separately validate шаванд.