2010-05-28 19 views
60

¿Por qué las personas usan bouncycastle en lugar de Java Cryptography Extension? ¿Cuál es la diferencia?¿Por qué las personas usan bouncycastle en lugar del proveedor JCE integrado de Java? ¿Cuál es la diferencia?

+7

JCE es una API estándar que cualquier algoritmo de criptografía puede implementar para permitir que sea accesible sin codificar dependencias en el proveedor. En otras palabras, al utilizar las API de JCE, puede cambiar las cifras y los proveedores de cifrado sin cambiar su código (en muchos casos). BC es un proveedor, lo que significa que implementa cifrados a los que se puede acceder a través de las API de JCE. Si aparece otro proveedor que implementa el algoritmo que desea mejor que BC o un algoritmo nuevo y más sólido, puede cambiar sin cambiar su código (probablemente). – nicerobot

Respuesta

56

BouncyCastle tiene muchos más cipher suites and algorithms que el default JCE proporcionado por Sun.

Además de eso, BouncyCastle tiene muchas utilidades para leer formatos arcanos como PEM y ASN.1 que ninguna persona en su sano juicio querría reescribir.

+3

Sun nunca tuvo la intención de ser un proveedor exhaustivo de cifrados. Es por eso que JCE utiliza el marco de proveedor que BC admite http://bouncycastle.org/specifications.html#install. Cualquier usuario de BC sería prudente usarlo a través de las API de JCE cuando sea posible. – nicerobot

8

En el servidor o en el escritorio, no veo ninguna razón para utilizar BC a menos que tenga que lidiar con cifrados heredados o formatos no admitidos por Sun JCE.

Sin embargo, muchos JRE no vienen con un proveedor de JCE, como en entornos móviles o integrados. BC es útil en tales casos.

+2

En el servidor definitivamente hay una razón, si su servidor está usando TLS y usted se preocupa por la seguridad (si no lo hace, ¿por qué está utilizando TLS en absoluto?). Las suites de cifrado incluidas con JCE solo incluyen AES en modo CBC, que tiene un par de problemas conocidos: http://googleonlinesecurity.blogspot.dk/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html . –

+1

FYI Esto no es cierto Java8 (De Oracle) al menos. –

15

Bouncy Castle es de origen australiano, y por lo tanto no está sujeto al Export of cryptography from the United States.

Es útil si se encuentra fuera de los Estados Unidos y necesita administrar tamaños de clave mayores que los permitidos por dicha restricción. En ese caso, no está permitido utilizar software de Estados Unidos para eso.

+4

Me pregunto cuántas restricciones realmente permanecen, anno 2016? Por lo que yo entiendo, ya no existe una restricción en el tamaño de la clave siempre que se registre en la Oficina de Industria y Seguridad (BIS) del Departamento de Comercio de EE. UU., Algo que supongo que Oracle ya está haciendo. Pero las regulaciones son crípticas (juego de palabras). – peterh

+0

Uf, si estoy fuera de los EE. UU., No necesito que se me permita nada. El proyecto puede necesitar permiso para enviar algo. –

Cuestiones relacionadas