Yapay zekâ tarafından English dilinden çevrildi ·
Lisans öğrencisiyim, tezim hafif blok şifreleri üzerine. Okuduğum her makale SPECK ve SIMON’un “IoT cihazlar için çok uygun” olduğunu söylüyor, ama “küçük” olmanın ötesinde nedenini pek açıklamıyorlar. Küçük olduklarını anlıyorum. Peki AES’e kıyasla onları tam olarak ne küçük yapıyor ve neden iki tane var?Projemin ikinci yarısı uygulamalı: laboratuvarımızda birkaç ATmega328P kartı ve bölümün kurduğu Hermetry organizasyonuna okumaları gönderen birkaç ESP32 var. Danışmanım şaka yollu, okumaları SPECK ile şifreleyip “bütün o TLS yükü yerine” göndermemi önerdi. Bu mümkün mü, yoksa platform TLS gerektiriyor mu? Bir test için bir ESP32’yi 1883 numaralı porta bağlanmayı denedim ve reddedildi; sanırım bu, sorunun bir kısmına verilmiş cevap.
Undergrad here, my thesis is on lightweight block ciphers. Every paper I read says SPECK and SIMON are “well suited to IoT devices” but they never really say why beyond “small”. I get that they’re small. What exactly makes them small compared to AES, and why are there two of them?
The second half of my project is practical: our lab has a few ATmega328P boards and some ESP32s that send readings to a Hermetry org the department set up. My supervisor joked that I should encrypt the readings with SPECK and send them “instead of all that TLS overhead”. Is that even possible, or does the platform require TLS? I tried to connect an ESP32 on port 1883 for a test and got refused, which I guess is my answer to part of it.
Yapay zekâ tarafından English dilinden çevrildi ·
Bunu takip ediyorum. Tesisimizdeki her sensörün TLS kullanmak zorunda olduğu söylendi ve bunun küçük kartları yavaşlatıp yavaşlatmadığını hep merak etmişimdir.
Following this. We’re told every sensor in our plant has to use TLS and I’ve always wondered if that slows the little boards down.
Yapay zekâ tarafından English dilinden çevrildi ·
İki farklı soru, bu yüzden iki cevap.SPECK ve SIMON neden küçük: ikisi de S-kutusu içermeyen ARX tasarımlarıdır (toplama, döndürme, XOR). AES, arama tabloları ya da oldukça karmaşık bayt yer değiştirmesi gerektirir; bu da 8 bitlik bir işlemcide flash ve RAM maliyeti getirir ve tablolarla yapılırsa zamanlama sızıntısına yol açar. SPECK’in turu birkaç 16/32/64 bitlik toplama, döndürme ve XOR işleminden ibarettir, bu yüzden tam bir uygulama birkaç yüz bayta sığar. İki tane olmasının nedeni farklı hedefler için ayarlanmış olmalarıdır: SIMON donanım için (çok az kapı), SPECK mikrodenetleyicilerde yazılım için. Ayrıca çok sayıda blok ve anahtar boyutunda gelirler (32/64’ten 128/256’ya kadar), bu da küçük paketler için kullanışlıdır. Teziniz için ISO standartlaştırma tartışması ve eksik tasarım gerekçesi de bir bölüm olmayı hak ediyor.TLS’in neden SPECK ile değiştirilemeyeceği: blok şifre tek bir yapı taşıdır. TLS anahtar değişimi, sunucu kimlik doğrulaması ve mesaj bütünlüğü sağlar; platform da kimlik bilginizi bu oturum içinde kontrol eder. Bir yükü SPECK ile şifreleyip gönderirseniz, yine biri sizinle bir anahtar üzerinde anlaşmak zorundadır ve broker opak bir veri yığını görür. Hermetry’de cihaz tarafı en az TLS 1.2 (tercihen 1.3) ile ileri gizlilik sağlayan paket takımlarını kullanır: AES-GCM veya ChaCha20-Poly1305; RSA anahtar değişimi yok, CBC yok. 1883 üzerinden düz MQTT yalnızca bir yönetici profil için Düz MQTT’yi açarsa çalışır ve dokümanlar bunu, özel ağda veya VPN üzerinde TLS yapamayan cihazlar için bir istisna olarak ele alır. 1883 testinizin reddedilmesinin nedeni budur. Tamamı cihaz taşıma güvenliği sayfasında yer alıyor.Pratik taraf: ESP32’nin AES donanımı vardır, TLS biraz RAM ve bağlantı başına bir saniye kadar el sıkışma süresi maliyeti getirir, sonrasında sensör hızlarında fark etmeyeceğiniz bir yük olmaz. ATmega ise dürüstçe bir sorundur. Ya ChaCha20-Poly1305 yaklaşımını kullanın (o da ARX’tir ve donanımsız da hızlıdır) ya da ATmega’nın TLS oturumunu tutan bir ağ geçidiyle konuşmasını sağlayın.
Two different questions, so two answers.
Why SPECK and SIMON are small: both are ARX designs (add, rotate, xor) with no S-boxes. AES needs lookup tables or a fairly involved byte substitution, which costs flash and RAM on an 8-bit part and leaks timing if you do it with tables. SPECK’s round is a handful of 16/32/64-bit adds, rotates and xors, so a full implementation fits in a few hundred bytes. There are two because they were tuned for different targets: SIMON for hardware (very few gates), SPECK for software on microcontrollers. They also come in many block and key sizes (32/64 up to 128/256), which is handy for tiny packets. For your thesis, the ISO standardisation fight and the missing design rationale are worth a chapter too.
Why you can’t swap TLS for SPECK: a block cipher is one building block. TLS gives you key exchange, server authentication and message integrity, and the platform checks your credential inside that session. If you encrypt a payload with SPECK and send it, someone still has to agree a key with you and the broker would see an opaque blob. On Hermetry the device side is TLS 1.2 minimum (1.3 preferred) with forward-secret suites: AES-GCM or ChaCha20-Poly1305, no RSA key exchange, no CBC. Plain MQTT on 1883 only works if an admin switches Plain MQTT on for the profile, and the docs treat that as an exception for devices that can’t do TLS on a private network or VPN. That’s why your 1883 test was refused. It’s all on the device transport security page.
Practical side: the ESP32 has AES hardware, TLS costs you a bit of RAM and a second or so of handshake per connection, and after that it’s nothing you’d notice at sensor rates. The ATmega is the honest problem. Either use ChaCha20-Poly1305 thinking (it’s ARX too and fast without hardware), or let the ATmega talk to a gateway that holds the TLS session.
Yapay zekâ tarafından English dilinden çevrildi ·
Bu çok yardımcı oldu. Kafamda “şifre” ve “protokol” kavramlarını karıştırmışım. Uygulamalı bölüm için yeni planım: SPECK64/128’i ChaCha20 ile ATmega328P üzerinde karşılaştırmalı olarak ölçmek (bayt başına çevrim sayısı, flash, RAM) ve ESP32’leri broker’a normal TLS ile bağlı tutmak. Anahtar değişimi kısmını anlattığımda danışmanım “TLS yerine” kısmına güldü, bu yüzden sanırım zaten şaka yapıyordu.
This helps a lot. I think I had “cipher” and “protocol” mixed up in my head. New plan for the practical chapter: benchmark SPECK64/128 against ChaCha20 on the ATmega328P (cycles per byte, flash, RAM), and keep the ESP32s on normal TLS to the broker. My supervisor laughed at the “instead of TLS” part when I explained the key exchange bit, so I think he was joking anyway.
Yapay zekâ tarafından English dilinden çevrildi ·
ESP32’lerin gerçekte yavaşlamadığını bilmek güzel. Yüklenicimizin düz MQTT istemesi için kullandığı argüman buydu.
Good to know the ESP32s aren’t really slowed down. That was the argument our contractor used to ask for plain MQTT.
- Bu konuyu yanıtlamak için giriş yapmış olmalısınız.
Sohbete katılın
Soru sormak ve yanıtlamak, yararlı gönderileri beğenmek ve sorununuzu çözen yanıtı işaretlemek için oturum açın. Her katkı puan ve seviye kazandırır.