encriptación AES reimplementar el uso de la biblioteca de Java de terceros, sin limitaciones de las leyes de los Estados Unidos

Question

He implementado el cifrado AES con ciertos parámetros de tareas específicas utilizando herramientas estándar de Java y proveedor de BouncyCastle específica algoritmo AES.

Este es el código:

private byte[] aesEncryptedInfo(String info) throws UnsupportedEncodingException, IllegalBlockSizeException, BadPaddingException, InvalidKeyException, NoSuchAlgorithmException, NoSuchPaddingException, InvalidParameterSpecException, InvalidAlgorithmParameterException, NoSuchProviderException {
    Security.addProvider(new BouncyCastleProvider());
    SecretKey secret = new SecretKeySpec(CUSTOMLONGSECRETKEY.substring(0, 32).getBytes(), "AES");
    Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding", "BC");
    cipher.init(Cipher.ENCRYPT_MODE, secret, new IvParameterSpec(VECTOR_SECRET_KEY.getBytes()));
    return cipher.doFinal(info.getBytes("UTF-8"));
}

En algunos entornos de este código requiere archivos de políticas especiales. Ver pregunta relacionada: InvalidKeyException ilegal tamaño de la clave

Mi objetivo es volver a implementar usando biblioteca de terceros, lo ideal sería que yo usaría castillo hinchable que ya se utiliza como proveedor. La biblioteca no debería tener restictions de archivos de política de Java estándar. En otras palabras, no debe haber restricciones.

Para sugerir en sus respuestas de cómo volver a implementar usando BouncyCastle u otra biblioteca de terceros que pueden trabajar sin restricciones mencionadas. Lo ideal sería ver el código: -)

Muchas gracias por leer!

Después de un retraso ahora feliz de publicar una solución. Esperanza de que alguien puede beneficiarse de ella porque la documentación Castillo Hinchable no está lleno de una gran cantidad de ejemplos: -)

private byte[] aesEncryptedInfo(String info)
// Creating AES/CBC/PKCS7Padding cipher with specified Secret Key and Initial Vector
PaddedBufferedBlockCipher cipher = new PaddedBufferedBlockCipher(new CBCBlockCipher(new AESEngine()), new PKCS7Padding());
cipher.init(true, new ParametersWithIV(new KeyParameter(CUSTOMLONGSECRETKEY.getBytes()), VECTOR_SECRET_KEY.getBytes()));

byte[] inputData = info.getBytes("UTF-8");
int outBlockSize = cipher.getOutputSize(inputData.length);
byte[] outputData = new byte[outBlockSize];

int outLength = cipher.processBytes(inputData, 0, inputData.length, outputData, 0);
outLength += cipher.doFinal(outputData, outLength);
if (outLength != outBlockSize) {
    return Arrays.copyOf(outputData, outLength);
}
else {
    return outputData;
}    

}

Por cierto me encontré con dos diferencias entre la API Java y API Castillo Hinchable: 1. Castillo Hinchable utiliza composición de los objetos para crear cifrado necesaria. Mientras Java API utiliza para identificar la cadena de cifrado necesario. 2. código de cifrado antes de Cristo un poco más grande, mientras que el código API Java es más compacto.

La solución está lleno de reemplazo para la implementación original de la API de Java -. La prueba es una prueba de unidad personalizada que hice

Answer 1

El uso del BouncyCastle ligera Crypto API directamente , en lugar de a través de la interfaz de Java JCE. BouncyCastle incluye su propia API criptográfica accesible a través de diversas clases en paquetes org.bouncycastle.*. También implementa la interfaz de proveedor de JCE para hacer algunos de sus implementaciones de cifrado disponibles a través de clases JCE estándar como Cipher, KeyGenerator, etc.

Las restricciones de la política de criptografía se hacen cumplir por las clases de la JCE, no por BouncyCastle. Por lo tanto, si usted no utiliza estas clases podrás no encontrará ningún tipo de restricciones. En el lado negativo va a sacrificar algo de portabilidad. Para empezar, echar un vistazo a las javadocs para la AESEngine clase, y el resto de los javadocs para la BouncyCastle .

Answer 2

¿Por qué no es posible sólo tiene que añadir los archivos de política necesaria?

Eso sería lo más fácil de hacer. Si usted vive en los EE.UU. y exportar el software a otros países (tal vez "no permitidos"), usted (en teoría) obtener problemas de cualquier manera (incluyendo archivos de políticas / haciendo el cifrado usted mismo).

Si usted vive fuera de los EE.UU., ¿por qué molestarse en ello, basta con incluir los archivos de política, a nadie le importa.

Answer 3

No hay opción para la compra de un kit de herramientas? RSA BSAFE