Traducido del English por IA ·
Soy estudiante de grado, mi tesis trata sobre cifrados de bloque ligeros. Todos los artículos que leo dicen que SPECK y SIMON son «muy adecuados para dispositivos IoT», pero nunca explican realmente por qué, más allá de «pequeños». Entiendo que son pequeños. ¿Qué los hace exactamente pequeños en comparación con AES, y por qué hay dos?La segunda parte de mi proyecto es práctica: nuestro laboratorio tiene algunas placas ATmega328P y algunos ESP32 que envían lecturas a una organización de Hermetry que configuró el departamento. Mi supervisor bromeó diciendo que debería cifrar las lecturas con SPECK y enviarlas «en lugar de toda esa sobrecarga de TLS». ¿Es eso siquiera posible, o la plataforma requiere TLS? Intenté conectar un ESP32 al puerto 1883 para una prueba y me rechazó, lo que supongo que es parte de la respuesta.
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.
Traducido del English por IA ·
Siguiendo este hilo. Nos dicen que todos los sensores de nuestra planta deben usar TLS y siempre me he preguntado si eso ralentiza las pequeñas placas.
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.
Traducido del English por IA ·
Dos preguntas distintas, así que dos respuestas.Por qué SPECK y SIMON son pequeños: ambos son diseños ARX (suma, rotación, XOR) sin S-cajas. AES necesita tablas de búsqueda o una sustitución de bytes bastante compleja, lo que consume memoria flash y RAM en un microcontrolador de 8 bits y filtra información de tiempos si se implementa con tablas. La ronda de SPECK son unas pocas sumas, rotaciones y XOR de 16/32/64 bits, por lo que una implementación completa cabe en unos cientos de bytes. Hay dos porque se ajustaron para objetivos distintos: SIMON para hardware (muy pocas puertas) y SPECK para software en microcontroladores. También existen en muchos tamaños de bloque y de clave (de 32/64 hasta 128/256), lo cual resulta útil para paquetes muy pequeños. Para tu tesis, la disputa sobre la estandarización ISO y la falta de justificación del diseño también merecen un capítulo.Por qué no puedes cambiar TLS por SPECK: un cifrado de bloque es solo un componente. TLS ofrece intercambio de claves, autenticación del servidor e integridad de los mensajes, y la plataforma comprueba tu credencial dentro de esa sesión. Si cifras una carga útil con SPECK y la envías, alguien aún tiene que acordar una clave contigo, y el broker vería un bloque opaco. En Hermetry, el lado del dispositivo requiere TLS 1.2 como mínimo (preferiblemente 1.3) con suites de secreto hacia adelante: AES-GCM o ChaCha20-Poly1305, sin intercambio de claves RSA y sin CBC. MQTT sin cifrar en el puerto 1883 solo funciona si un administrador activa MQTT sin cifrar para el perfil, y la documentación lo trata como una excepción para dispositivos que no pueden usar TLS en una red privada o una VPN. Por eso se rechazó tu prueba en el 1883. Todo está en la página de seguridad del transporte de dispositivos.Lado práctico: el ESP32 tiene hardware AES, TLS cuesta un poco de RAM y alrededor de un segundo de negociación por conexión, y después no se nota a las velocidades de los sensores. El ATmega es el problema real. O bien usas el enfoque ChaCha20-Poly1305 (también es ARX y rápido sin hardware dedicado), o dejas que el ATmega hable con una pasarela que mantenga la sesión 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.
Traducido del English por IA ·
Esto me ayuda mucho. Creo que tenía mezclados los conceptos de «cifrado» y «protocolo». Nuevo plan para el capítulo práctico: comparar SPECK64/128 frente a ChaCha20 en el ATmega328P (ciclos por byte, flash, RAM), y mantener los ESP32 con TLS normal hacia el broker. Mi supervisor se rio de la parte de «en lugar de TLS» cuando le expliqué lo del intercambio de claves, así que supongo que de todos modos estaba bromeando.
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.
Traducido del English por IA ·
Está bien saberlo, los ESP32 no se ralentizan realmente. Ese era el argumento que nuestro contratista usaba para pedir MQTT sin cifrar.
Good to know the ESP32s aren’t really slowed down. That was the argument our contractor used to ask for plain MQTT.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.