Von English mit KI übersetzt ·
Ich bin Bachelorstudent, meine Abschlussarbeit handelt von leichtgewichtigen Blockchiffren. Jede Arbeit, die ich lese, sagt, dass SPECK und SIMON „gut für IoT-Geräte geeignet“ sind, erklärt aber selten, warum, abgesehen von „klein“. Ich verstehe, dass sie klein sind. Was genau macht sie im Vergleich zu AES klein, und warum gibt es zwei davon?Der zweite Teil meines Projekts ist praktisch: Unser Labor hat einige ATmega328P-Boards und ein paar ESP32, die Messwerte an eine Hermetry-Organisation senden, die die Fakultät eingerichtet hat. Mein Betreuer scherzte, ich solle die Messwerte mit SPECK verschlüsseln und „statt des ganzen TLS-Overheads“ senden. Ist das überhaupt möglich, oder verlangt die Plattform TLS? Ich habe versucht, einen ESP32 für einen Test auf Port 1883 zu verbinden, und wurde abgewiesen, was wohl ein Teil der Antwort ist.
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.
Von English mit KI übersetzt ·
Ich verfolge das. Uns wurde gesagt, dass jeder Sensor in unserer Anlage TLS verwenden muss, und ich habe mich schon immer gefragt, ob das die kleinen Boards verlangsamt.
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.
Von English mit KI übersetzt ·
Zwei verschiedene Fragen, also zwei Antworten.Warum SPECK und SIMON klein sind: Beide sind ARX-Designs (Addition, Rotation, XOR) ohne S-Boxen. AES benötigt Lookup-Tabellen oder eine recht aufwendige Byte-Substitution, was auf einem 8-Bit-Controller Flash und RAM kostet und bei tabellenbasierter Umsetzung Timing-Informationen preisgibt. Die Runde von SPECK besteht aus einer Handvoll 16/32/64-Bit-Additionen, Rotationen und XORs, daher passt eine vollständige Implementierung in wenige hundert Bytes. Es gibt zwei, weil sie für unterschiedliche Ziele optimiert wurden: SIMON für Hardware (sehr wenige Gatter), SPECK für Software auf Mikrocontrollern. Außerdem gibt es sie in vielen Block- und Schlüsselgrößen (32/64 bis 128/256), was für winzige Pakete praktisch ist. Für Ihre Arbeit lohnt auch ein Kapitel zum ISO-Standardisierungsstreit und zur fehlenden Dokumentation der Designbegründung.Warum Sie TLS nicht durch SPECK ersetzen können: Eine Blockchiffre ist nur ein Baustein. TLS bietet Schlüsselaustausch, Serverauthentifizierung und Nachrichtenintegrität, und die Plattform prüft Ihre Zugangsdaten innerhalb dieser Sitzung. Wenn Sie eine Nutzlast mit SPECK verschlüsseln und senden, muss trotzdem jemand einen Schlüssel mit Ihnen vereinbaren, und der Broker sähe nur einen undurchsichtigen Datenblock. Auf Hermetry ist die Geräteseite mindestens TLS 1.2 (1.3 bevorzugt) mit Forward-Secrecy-Suiten: AES-GCM oder ChaCha20-Poly1305, kein RSA-Schlüsselaustausch, kein CBC. Unverschlüsseltes MQTT auf Port 1883 funktioniert nur, wenn ein Administrator Plain MQTT für das Profil aktiviert, und die Dokumentation behandelt das als Ausnahme für Geräte, die kein TLS in einem privaten Netz oder VPN können. Deshalb wurde Ihr 1883-Test abgelehnt. Alles steht auf der Seite zur Transportsicherheit der Geräte.Praktische Seite: Der ESP32 hat AES-Hardware, TLS kostet etwas RAM und etwa eine Sekunde Handshake pro Verbindung, danach ist es bei Sensorraten nicht spürbar. Der ATmega ist das ehrliche Problem. Entweder denken Sie in Richtung ChaCha20-Poly1305 (das ebenfalls ARX ist und ohne Hardwareunterstützung schnell läuft) oder Sie lassen den ATmega mit einem Gateway sprechen, das die TLS-Sitzung hält.
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.
Von English mit KI übersetzt ·
Das hilft mir sehr. Ich glaube, ich hatte „Chiffre“ und „Protokoll“ im Kopf durcheinandergebracht. Neuer Plan für das praktische Kapitel: SPECK64/128 gegen ChaCha20 auf dem ATmega328P benchmarken (Zyklen pro Byte, Flash, RAM), und die ESP32 weiterhin über normales TLS mit dem Broker verbinden. Mein Betreuer hat über den Teil „statt TLS“ gelacht, als ich ihm den Schlüsselaustausch erklärt habe, also hat er wohl sowieso gescherzt.
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.
Von English mit KI übersetzt ·
Gut zu wissen, dass die ESP32s nicht wirklich ausgebremst werden. Genau dieses Argument hat unser Auftragnehmer immer benutzt, um reines MQTT zu verlangen.
Good to know the ESP32s aren’t really slowed down. That was the argument our contractor used to ask for plain MQTT.
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
Mitdiskutieren
Melde dich an, um Fragen zu stellen und zu beantworten, hilfreiche Beiträge mit „Gefällt mir“ zu markieren und die Antwort zu kennzeichnen, die dein Problem gelöst hat. Jeder Beitrag bringt Punkte und Stufen.