Hola a todos 
,
Estoy trabajando en una configuración de seguridad local para mi extensión de Chrome y flujo de trabajo de n8n, y me gustaría recibir retroalimentación antes de construir la siguiente versión y escribir el próximo tutorial.
Este es el artículo de referencia actual:
Recientemente, estaba leyendo el artículo de IBM sobre criptografía ágil:
Crypto-agility and quantum-safe readiness | IBM Quantum Computing Blog
Me hizo pensar en una pregunta simple:
¿Cómo puedo hacer que mi configuración segura actual sea más fácil de evolucionar más adelante, sin convertirla en un sistema de criptografía empresarial excesivamente ingenierizado?
Mi configuración actual
Mi proyecto es intencionalmente simple:
• una extensión de Chrome
• un host de mensajería nativa
• un flujo de trabajo local de n8n
• validación de solicitudes basada en HMAC
• protección contra repetición con controles de marca de tiempo / nonce
• límite de confianza local
• sin secretos expuestos en la extensión
Entonces esto no es una plataforma de múltiples flujos de trabajo. Es solo un flujo seguro local.
Por qué estoy pensando en criptografía ágil
Mi comprensión de la criptografía ágil no es “cambiar algoritmos por el simple hecho de hacerlo”.
Para mí, significa:
• hacer que las opciones criptográficas sean más fáciles de actualizar más adelante,
• evitar lógica de validación codificada en todas partes,
• mantener las opciones de migración futura abiertas,
• y poder cambiar claves o detalles de criptografía sin reescribir todo el flujo de trabajo.
Para un pequeño proyecto local, no creo que sea necesaria la criptografía ágil completa.
Lo que estoy considerando es criptografía ágil ligera.
Qué entiendo por “criptografía ágil ligera”
No una arquitectura empresarial completa.
No una sidecar.
No una puerta de enlace criptográfica.
No múltiples proveedores de algoritmos.
Solo una pequeña mejora para hacer que la configuración actual sea más fácil de mantener más adelante.
Eso significa:
• mantener la validación en un solo lugar
• dejar los secretos fuera del código
• opcionalmente agregar un campo kid o version más adelante
• hacer que los cambios futuros sean más fáciles
• evitar lógica criptográfica repetida
Esto parece un buen equilibrio para una pequeña empresa o proyecto local: una actualización útil, pero aún simple.
Mi dirección propuesta v2.0
Flujo actual
Flujo de criptografía ágil ligera
El objetivo no es crear complejidad extra.
El objetivo es hacer que la capa de seguridad sea más limpia y más fácil de evolucionar más adelante.
Sobre qué quiero retroalimentación
Mi pregunta principal es:
Para una configuración local de una extensión / un flujo de trabajo, ¿tiene sentido la criptografía ágil ligera, o ya es demasiado?
Creo que vale la pena hacerlo porque:
• da una mejora pequeña pero real,
• mantiene la arquitectura mantenible,
• y evita el exceso de ingeniería.
Pero me gustaría escuchar qué piensan otros antes de construir v2.0.
¿Te parece que este es el equilibrio correcto para una configuración segura local?