Go barcos con un conjunto completo de paquetes de criptografía en la biblioteca estándar para ayudar a los desarrolladores a construir aplicaciones seguras. para completar una auditoría del conjunto principal de paquetes que también son validados como parte del La auditoría produjo un único hallazgo de baja gravedad, en el legado y no respaldado , y un puñado de hallazgos informativos.El texto completo del informe de auditoría se puede encontrar . El trayecto de Bits Nuevo módulo nativo FIPS 140-3 Go+BoringCrypto Integración Aquí El alcance de la auditoría incluyó nuestras implementaciones de intercambio de claves (ECDH y post-quantum ML-KEM), firma digital (ECDSA, RSA, y Ed25519), encriptación (AES-GCM, AES-CBC, y AES-CTR), hashing (SHA-1, SHA-2, y SHA-3), derivación de claves (HKDF y PBKDF2), y autenticación (HMAC), así como el generador de números aleatorios criptográficos. Se incluyeron implementaciones de curvas grandes y elípticas de bajo nivel, con sus delicados núcleos de montaje. Estamos orgullosos del registro de seguridad de los paquetes de criptografía de Go, y del resultado de esta auditoría, que es sólo una de las muchas maneras en que obtenemos la certeza de la corrección de los paquetes. que, por ejemplo, prioricen la seguridad sobre el rendimiento. Con una serie de técnicas diferentes. hacemos un punto de aprovechar las APIs seguras incluso para paquetes internos, y por supuesto podemos confiar en las propiedades del lenguaje Go para evitar problemas de gestión de memoria. Principios de la criptografía Prueba a fondo Un hallazgo de baja gravedad El único problema potencialmente explotable, TOB-GOCL-3, ha , lo que significa que tuvo un impacto menor y fue difícil de desencadenar. Este problema ha sido corregido en Go 1.24. Bajo severidad Por lo tanto, el TOB-GOCL-3 es esencial ( La gestión de la memoria en la , que no está habilitado por defecto y no se admite para uso fuera de Google. discutido más abajo Legacy Go+BoringCrypto GOEXPERIMENT 5 Descubrimientos informativos Los resultados restantes son , lo que significa que no representan un riesgo inmediato, pero son relevantes para las mejores prácticas de seguridad. informativo Los hallazgos TOB-GOCL-1, TOB-GOCL-2, y TOB-GOCL-6 se refieren a posibles canales laterales de temporización en diversas operaciones criptográficas. De estos tres hallazgos, sólo TOB-GOCL-2 afecta a las operaciones que se esperaba que fueran constantes debido a operar en valores secretos, pero sólo afecta a los objetivos de Power ISA (GOARCH ppc64 y ppc64le). TOB-GOCL-4 destaca el riesgo de abuso en una API interna, si se reutiliza más allá de su caso de uso actual. TOB-GOCL-5 señala una verificación que falta para un límite que es impracticable alcanzar. Los canales laterales Los hallazgos TOB-GOCL-1, TOB-GOCL-2, y TOB-GOCL-6 se refieren a canales laterales de tiempo menores. TOB-GOCL-1 y TOB-GOCL-6 están relacionados con funciones que no utilizamos para valores sensibles, pero que podrían utilizarse para tales valores en el futuro, y TOB-GOCL-2 está relacionado con la implementación de ensamblaje de P-256 ECDSA en Power ISA. : la conversión de bytes a elementos de campo no es constante en tiempo (TOB-GOCL-1) crypto/ecdh,crypto/ecdsa La implementación interna de las curvas elípticas de NIST proporcionó un método para convertir elementos de campo entre una representación interna y externa que operaba en tiempo variable. Todos los usos de este método operaron en entradas públicas que no se consideran secretas (valores públicos de ECDH y claves públicas de ECDSA), por lo que determinamos que este no era un problema de seguridad. , para evitar el uso accidental de este método en el futuro con valores secretos, y para que no tengamos que pensar en si es un problema o no. Hacer que el método sea constante en cualquier momento La negación condicional P-256 no es un tiempo constante en el ensamblaje de Power ISA (TOB-GOCL-2, CVE-2025-22866) crypto/ecdsa Más allá de la , Go también soporta una serie de plataformas adicionales, incluyendo algunas arquitecturas menos comunes. Durante la revisión de nuestras implementaciones de ensamblaje de varios primitivos criptográficos subyacentes, el equipo de Trail of Bits encontró un problema que afectó a la implementación de ECDSA en las arquitecturas ppc64 y ppc64le. Primera clase de plataformas Debido al uso de una instrucción de ramificación condicional en la implementación de la negación condicional de P-256 puntos, la función operó en tiempo variable, en lugar de tiempo constante, como se esperaba. con un patrón que ya usamos en otros lugares para seleccionar condicionalmente el resultado correcto en tiempo constante. Sustituir la instrucción de ramificación condicional Para priorizar el código que alcanza a la mayoría de nuestros usuarios, y debido al conocimiento especializado necesario para dirigir a ISAs específicos, generalmente confiamos en las contribuciones de la comunidad para mantener el montaje para plataformas no de primera clase. : Scalar.SetCanonicalBytes no es tiempo constante (TOB-GOCL-6) crypto/ed25519 El paquete interno edwards25519 proporcionó un método para convertir entre una representación interna y externa de escalares que operaban en tiempo variable. Este método sólo se utilizó en las entradas de firma para ed25519.Verify, que no se consideran secretas, por lo que determinamos que esto no era un problema de seguridad. , para evitar el uso accidental de este método en el futuro con valores secretos, y porque somos conscientes de que las personas forcan este código fuera de la biblioteca estándar, y pueden estar usando con valores secretos. Hacer que el método sea constante en cualquier momento Gestión de memoria Cgo Encontrar TOB-GOCL-3 se refiere a un problema de gestión de memoria en la integración Go+BoringCrypto. : el finalizador personalizado puede liberar la memoria al inicio de una llamada de la función C usando esta memoria (TOB-GOCL-3) crypto/ecdh Durante la revisión, hubo una serie de preguntas sobre nuestra integración Go+BoringCrypto basada en cgo, que proporciona un modo de criptografía compatible con FIPS 140-2 para uso interno en Google. El equipo de Trail of Bits encontró una vulnerabilidad y una , ambos fueron resultados de la gestión manual de la memoria necesaria para interactuar con una biblioteca C. Dado que el equipo de Go no soporta el uso de este código fuera de Google, hemos optado por no emitir una entrada de la base de datos de vulnerabilidades CVE o Go para este problema, pero . Bugs relevantes para la seguridad Lo he resuelto en 1.24 Este tipo de trampa es una de las muchas razones por las que decidimos alejarnos de la integración Go+BoringCrypto. que utiliza los paquetes regulares de criptografía pura Go, lo que nos permite evitar la compleja semántica cgo en favor del modelo tradicional de memoria Go. Modo nativo FIPS 140-3 Completidad de la implementación Los hallazgos TOB-GOCL-4 y TOB-GOCL-5 se refieren a implementaciones limitadas de dos especificaciones, y . NIST SP 800-90A RFC 8018 API CTR_DRBG presenta múltiples riesgos de mal uso (TOB-GOCL-4) crypto/internal/fips140/drbg Como parte de la que estamos introduciendo, necesitamos una implementación del NIST CTR_DRBG (un generador de bits aleatorios determinísticos basado en AES-CTR) para proporcionar aleatoriedad conforme. Modo nativo FIPS 140-3 Dado que sólo necesitamos un pequeño subconjunto de la funcionalidad del NIST SP 800-90A Rev. 1 CTR_DRBG para nuestros propósitos, no implementamos la especificación completa, en particular omitiendo la función de derivación y las cadenas de personalización. Dado que nuestra implementación está estrechamente abarcada al caso de uso específico que necesitamos, y dado que la implementación no se exporta públicamente, determinamos que esto era aceptable y vale la pena la disminución de la complejidad de la implementación. Detalle de estas limitaciones. Añade una advertencia a la documentación PBKDF2 no aplica límites de longitud de salida (TOB-GOCL-5) crypto/pbkdf2 En Go 1.24, comenzamos el proceso de mover paquetes de entrar en la biblioteca estándar, terminando con un patrón confuso en el que los paquetes de criptografía de Go de primera parte, de alta calidad y estables se mantenían fuera de la biblioteca estándar sin una razón particular. por golang.org/x/crypto Como parte de este proceso, movilizamos el En el momento de revisar este paquete, el equipo de Trail of Bits notó que no aplicamos el límite sobre el tamaño de las claves derivadas definidas en . golang.org/x/crypto/pbkdf2 RFC 8018 El límite es Cuando se utiliza SHA-256, exceder el límite tomaría una llave de más de 137GB. No esperamos que nadie haya usado PBKDF2 para generar una llave tan grande, especialmente porque PBKDF2 ejecuta las iteraciones en cada bloque, pero por el bien de la corrección, . (2^32 - 1) * <hash length> aplicar el límite definido por la norma ¿Qué es lo siguiente Los resultados de esta auditoría validan el esfuerzo que el equipo de Go ha puesto en el desarrollo de bibliotecas de criptografía de alta calidad, fáciles de usar y deben brindar confianza a nuestros usuarios que confían en ellos para construir software seguro y seguro. No estamos descansando en nuestros laureles, sin embargo: los contribuyentes de Go continúan desarrollando y mejorando las bibliotecas de criptografía que proporcionamos a los usuarios. Go 1.24 ahora incluye un modo FIPS 140-3 escrito en puro Go, que actualmente está siendo sometido a pruebas CMVP. Esto proporcionará un modo compatible con FIPS 140-3 soportado para todos los usuarios de Go, reemplazando la integración Go+BoringCrypto actualmente no soportada. También estamos trabajando para implementar la moderna criptografía post cuántica, introduciendo una implementación ML-KEM-768 y ML-KEM-1024 en Go 1.24 en el , y añadiendo soporte al paquete crypto/tls para el intercambio de claves híbrido X25519MLKEM768 . El paquete Crypto/mlkem Por último, planeamos introducir nuevas APIs de criptografía de alto nivel más fáciles de usar, diseñadas para reducir la barrera para seleccionar y utilizar algoritmos de alta calidad para casos de uso básicos.Planamos comenzar con ofrecer una API de hashing de contraseñas simple que elimina la necesidad de que los usuarios decidan cuál de la multitud de algoritmos posibles deben confiar, con mecanismos para migrar automáticamente a algoritmos más recientes como los cambios de última generación. Roland Shoemaker y Filippo Valsorda Este artículo está disponible en The Go Blog bajo una licencia CC BY 4.0 DEED. El blog de Go El blog de Go Fotografía de Batyrkhan Shalgimbekov en Unsplash Batyrkhan Shalgimbekov Unosplash

Try and Download Go 

Read My Stories

Este audio es producido en el idioma original de la historia!

Los paquetes de criptografía de Go fueron auditados: los resultados

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Telegram: el puente de Crypto Island hacia el continente

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Telegram: el puente de Crypto Island hacia el continente

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps