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.