Legalidad del cifrado en bibliotecas estándar [cerrado]

Question

Algunos lenguajes de programación como Java y C# incluyen paquetes de cifrado en sus bibliotecas estándar.Otros, como Python y Ruby, te obligan a descargar módulos de terceros para realizar un cifrado seguro.Supongo que esto es por razones legales;tal vez Sun Microsystems tenga suficientes abogados para no tener miedo de ser demandado, mientras que Guido van Rossum se siente más vulnerable.

Pero ¿qué dice realmente la ley al respecto?En este punto, ¿tendrían algo que temer los autores de código abierto si incluyeran un cifrado fuerte en las bibliotecas estándar de sus lenguajes de programación?Si es así, ¿por qué no lo hacen?Si no es así, ¿cómo se salen con la suya Sun y Microsoft?

Answer 1

Hay dos cuestiones:importación de software de cifrado y exportación de software de cifrado.

Algunos países (China, Rusia, Irán, Irak, Myanmar, etc.) restringen el uso de la criptografía por parte de sus ciudadanos.Es ilegal importar software de cifrado a esos países.

Para habilitar una potencia de cifrado ilimitada en el JDK, debe descargar un nuevo archivo de política.La licencia de software allí no le permite utilizar el software si se encuentra en un país que no permite la importación de cifrado.Esto se llama "Política de jurisdicción de fuerza ilimitada" y a continuación incluyo parte de su archivo README.txt.

Otros países, como Estados Unidos, no quieren exportar software de cifrado al Eje del Mal.Entonces, puede ser ilegal exportar software de cifrado a esos países.

Las restricciones a las exportaciones de Estados Unidos se han suavizado considerablemente, probablemente en reconocimiento de la inutilidad de mantener el cifrado fuera del alcance de los enemigos, o posiblemente para fomentar el uso de cifrado que ha sido comprometido por la NSA.Pero no han desaparecido por completo.No creo que los terroristas puedan licenciar el software.

JCE para JDK 5.0 ha pasado por EE.UU.proceso de revisión de exportaciones.El marco JCE, junto con el proveedor de SunJce que viene de serie, es exportable.

La arquitectura JCE permite configurar la fuerza criptográfica flexible a través de archivos de política de jurisdicción.Debido a las restricciones de importación de algunos países, los archivos de política de jurisdicción distribuidos con el software JDK 5.0 tienen restricciones incorporadas sobre la fuerza criptográfica disponible.Los archivos de política de jurisdicción en este paquete de descarga (el paquete, incluido este archivo ReadMe) no contienen restricciones a las fortalezas criptográficas.Esto es apropiado para la mayoría de los países.Los proveedores de Framework pueden crear paquetes de descarga que incluyen archivos de política de jurisdicción que especifican restricciones criptográficas apropiadas para países cuyos gobiernos exigen restricciones.Los usuarios de esos países pueden descargar un paquete apropiado, y el marco JCE aplicará las restricciones especificadas.

Se recomienda consultar a su asesor o abogado de control de exportación/importación para determinar los requisitos exactos.

Answer 2

En los EE.UU. la ley importante es ITAR.

Answer 3

Google rápido mostró un artículo de Wikipedia.

http://en.wikipedia.org/wiki/Export_of_cryptography

Pero por ahora parece que la frase "No es necesario reinventar la rueda" es correcta.

Answer 4

IANAL, pero...

Java y C# son de código cerrado y, por lo tanto, tienen términos en el EULA que dicen más o menos "No es culpa nuestra si usas esto en algún lugar donde no debes hacerlo".También cuentan con equipos de abogados para protegerse y hacer cumplir esa cláusula.

La mayoría de las licencias de código abierto no tienen un lenguaje similar, e incluso las que sí lo tienen, no tienen equipos de abogados de su lado, como dijo el OP.

Además, Python y PERL son más antiguos que Java y C#, de los días en que era ilegal exportar software criptográfico desde Estados Unidos.No agregar criptografía desde que se cambió la ley es quizás simplemente una decisión de "la coherencia es buena".