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.