Traduit de English par IA ·
Je suis étudiant de licence, ma thèse porte sur les chiffrements par blocs légers. Chaque article que je lis affirme que SPECK et SIMON sont « bien adaptés aux appareils IoT », mais ils n’expliquent jamais vraiment pourquoi, au-delà de « petits ». Je comprends qu’ils sont petits. Qu’est-ce qui les rend exactement petits par rapport à AES, et pourquoi en existe-t-il deux ?La seconde partie de mon projet est pratique : notre laboratoire possède quelques cartes ATmega328P et quelques ESP32 qui envoient des relevés à une organisation Hermetry mise en place par le département. Mon directeur de recherche a plaisanté en me suggérant de chiffrer les relevés avec SPECK et de les envoyer « au lieu de tout ce surcoût TLS ». Est-ce seulement possible, ou la plateforme exige-t-elle TLS ? J’ai essayé de connecter un ESP32 au port 1883 pour un test, et la connexion a été refusée, ce qui est sans doute une partie de la réponse.
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.
Traduit de English par IA ·
Je suis ce fil. On nous a dit que chaque capteur de notre usine doit utiliser TLS, et je me suis toujours demandé si cela ralentit les petites cartes.
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.
Traduit de English par IA ·
Deux questions différentes, donc deux réponses.Pourquoi SPECK et SIMON sont petits : ce sont tous deux des conceptions ARX (addition, rotation, XOR) sans S-boxes. AES nécessite des tables de correspondance ou une substitution d’octets assez complexe, ce qui coûte de la mémoire flash et de la RAM sur un composant 8 bits et laisse fuiter des informations de temps s’il est implémenté avec des tables. Le tour de SPECK se résume à quelques additions, rotations et XOR sur 16/32/64 bits, si bien qu’une implémentation complète tient en quelques centaines d’octets. Il en existe deux parce qu’ils ont été optimisés pour des cibles différentes : SIMON pour le matériel (très peu de portes), SPECK pour le logiciel sur microcontrôleurs. Ils existent aussi en de nombreuses tailles de bloc et de clé (de 32/64 à 128/256), ce qui est pratique pour de très petits paquets. Pour votre thèse, la controverse autour de la standardisation ISO et l’absence de justification de conception méritent aussi un chapitre.Pourquoi vous ne pouvez pas remplacer TLS par SPECK : un chiffrement par blocs n’est qu’une brique. TLS assure l’échange de clés, l’authentification du serveur et l’intégrité des messages, et la plateforme vérifie votre identifiant à l’intérieur de cette session. Si vous chiffrez une charge utile avec SPECK et l’envoyez, quelqu’un doit tout de même convenir d’une clé avec vous, et le broker ne verrait qu’un bloc opaque. Sur Hermetry, côté appareil, le minimum est TLS 1.2 (1.3 recommandé) avec des suites à confidentialité persistante : AES-GCM ou ChaCha20-Poly1305, sans échange de clés RSA ni CBC. Le MQTT non chiffré sur le port 1883 ne fonctionne que si un administrateur active MQTT en clair pour le profil ; la documentation traite cela comme une exception pour les appareils qui ne peuvent pas utiliser TLS sur un réseau privé ou un VPN. C’est pourquoi votre test sur 1883 a été refusé. Tout est détaillé sur la page de sécurité du transport des appareils.Côté pratique : l’ESP32 dispose d’un matériel AES, TLS coûte un peu de RAM et environ une seconde de négociation par connexion, puis cela ne se remarque pas aux débits des capteurs. L’ATmega est le vrai problème. Soit vous utilisez ChaCha20-Poly1305 (il est aussi ARX et rapide sans matériel dédié), soit vous laissez l’ATmega communiquer avec une passerelle qui conserve la session TLS.
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.
Traduit de English par IA ·
Cela m’aide beaucoup. Je crois que je confondais « chiffrement » et « protocole ». Nouveau plan pour le chapitre pratique : comparer SPECK64/128 à ChaCha20 sur l’ATmega328P (cycles par octet, flash, RAM), et garder les ESP32 en TLS classique vers le broker. Mon directeur a ri quand je lui ai expliqué la partie échange de clés à propos de « à la place de TLS », donc je pense qu’il plaisantait de toute façon.
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.
Traduit de English par IA ·
Bon à savoir que les ESP32 ne sont pas vraiment ralentis. C’est l’argument que notre prestataire utilisait pour réclamer du MQTT en clair.
Good to know the ESP32s aren’t really slowed down. That was the argument our contractor used to ask for plain MQTT.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.