Creo que puedo responder a esta pregunta para el caso específico de una biblioteca criptográfica escrita en Go --- es fácil, y en absoluto hipotética, porque ya existe una paquete TLS, crypto/tls en Go que no depende de ninguna biblioteca externa.
Mientras que con respecto a los típicos desbordamientos de búfer, Go idiomático es mucho más seguro que C tradicional, Go ofrece al desarrollador entusiasta muchas opciones para eludirlo, como imitar la aritmética de punteros de C a través de unsafe.pointer . Uno se pregunta si podría acordar no usar código frágil en una pieza crítica de software.
La criptografía, por supuesto, es exactamente el tipo de software que utiliza un código tan frágil, por buenas razones. Después de todo, las comparaciones de tiempo constante implementadas en el paquete Go crypto.subtle sí requieren y tienen, de manera similar, extremas advertencias sobre el uso cuidadoso como las de unsafe . La única pregunta que queda, realmente, es si algún error aún puede sobrevivir en ese entorno.
Por lo que puedo decir, Go implementa comparaciones constantes de tiempo de valores hash correctamente. No me he molestado en mirar si los hash complicados que involucran cajas S se calculan de manera constante: nadie se molestó en ponerlos en un paquete con nombres como subtle y advertencias sobre lo fácil que es romper cosas. , entonces estoy realmente dudoso.
Lo que sí comprobé es que la criptografía de curva elíptica no se implementa de forma constante en Go. Nadie parece siquiera haber considerado intentarlo en lo más mínimo: la implementación llama a muchas funciones enteras de longitud arbitraria que ni siquiera están diseñadas para el uso criptográfico y, de hecho, utilizan algoritmos de tiempo no constante. Cuando recientemente se demostró que este tipo de canal lateral de sincronización también ocurre en OpenSSL en una arquitectura, fue lo suficientemente bueno para a documento que demuestra el compromiso de la clave privada .
La misma situación continua existe en Go, en todas las arquitecturas. Y, bueno, realmente no parece que a nadie le importen detalles como el trabajo de criptografía; el foco está solo en la legibilidad y la velocidad (bueno, y funciona de la manera en que el usuario casual y algunas pruebas de unidad son engañados por él, supongo). Después de todo, ¿por qué incluso se molestaría en elegir un algoritmo adecuado cuando el lenguaje ya lo mantiene a salvo de la mayoría de las formas de introducir desbordamientos de búfer, y al elegir un algoritmo correcto se corre el riesgo de arruinar la afirmación de Google de que TLS se ha vuelto computacionalmente barato? Dejando de lado el sarcasmo, hacer que el lenguaje responsable de detectar nuestros errores solo significará que todos los errores que el lenguaje no puede detectar para nosotros seguirán estando allí.
Finalmente, las bibliotecas como OpenSSL tienen las ventajas de que las correcciones de errores oportunas son una posibilidad razonable. Si bien, en principio, lo mismo se aplica a los paquetes Go, una vez que algo se convierte en parte del núcleo de Go, como el paquete TLS, se ve afectado por el calendario de lanzamiento. Obviamente, eso puede interferir con el despliegue oportuno de correcciones de errores. Supongo que el Go-1.3, que se entregará este verano, no solucionará el problema de la temporización del ECC, incluso si fuera reconocido como el problema crítico, dada la congelación de funciones.