🔐 ¿Cuál es el riesgo real de usar SHA-1 en una factura electrónica?

Muy bajo. Te explico por qué:

---

✅ 1. El contexto es distinto al de un sistema bancario o confidencial

La factura electrónica:

• No contiene secretos militares ni credenciales bancarias.

• Va firmada principalmente para garantizar integridad, autenticidad y no repudio.

• Su uso está regulado y supervisado por el SII, que valida y almacena los documentos.

---

✅ 2. Ya hay múltiples capas de validación:

• Firma del emisor (firma del XML).

• Validaciones cruzadas vía trackid y timbre electrónico.

---

✅ 3. SHA-1 es usado solo porque el validador lo exige

• No estás implementando SHA-1 por elección ni como práctica insegura.

• Lo usas porque el validador del SII lo requiere explícitamente en su especificación.

• Ruby y Python modernos lo bloquean por defecto. Pero Java, bien configurado, puede seguir cumpliendo con esta exigencia sin comprometer todo el sistema.

---

✅ 4. El interés de “hackear” facturas es mínimo

• ¿Quién querría falsificar una factura electrónica si la verificación es pública, regulada y va firmada por más de una entidad?

• El documento pasa por un proceso fiscal que no depende solo de la firma digital, sino de folios autorizados, libros, trackid, respuestas del SII, etc.

💡 Conclusión: 

Aunque SHA-1 esté deprecated, en el mundo real, los sistemas deben adaptarse a las especificaciones de los organismos fiscales. En este caso, implementé un microservicio de firma electrónica en Java para cumplir con los requisitos del SII, donde la modernidad debía ceder ante la compatibilidad.

---