Переопределить шифрование AES с использованием сторонней библиотеки Java без ограничений законодательства США
Я реализовал шифрование AES с определенными параметрами, специфичными для задачи, используя стандартные инструменты Java и поставщика BouncyCastle для конкретного алгоритма AES.
Вот код:
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"));
}
В некоторых средах этот код требует специальных файлов политики. См. Связанный вопрос: InvalidKeyException Недопустимый размер ключа
Моя цель - переопределить его с помощью сторонней библиотеки, в идеале я бы использовал надувной замок, который уже используется в качестве провайдера. Библиотека не должна иметь ограничений на стандартные файлы политики Java. Другими словами, не должно быть никаких ограничений.
Пожалуйста, предложите в своих ответах, как переопределить его, используя BouncyCastle или другую стороннюю библиотеку, которая может работать без указанных ограничений. В идеале я бы увидел код:-)
Большое спасибо за чтение!
После задержки я теперь с удовольствием выложу решение. Надеюсь, что кто-то может извлечь из этого пользу, потому что документация Bouncy Castle не полна примеров:-)
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;
}
}
Кстати, я обнаружил два отличия между Java API и Bouncy Castle API: 1. Bouncy Castle использует композицию объектов для создания необходимого шифра. В то время как Java API использует строку для определения необходимого шифра. 2. Код шифрования BC немного больше, а код Java API более компактен.
Решение - полная замена оригинальной реализации Java API - доказательством является пользовательский модульный тест, который я сделал.
3 ответа
Используйте облегченный криптографический API Bouncycastle напрямую, а не через интерфейс Java JCE. Bouncycastle включает в себя собственный крипто API, доступный через различные классы в org.bouncycastle.*
пакеты. Он также реализует интерфейс провайдера JCE, чтобы сделать некоторые его криптографические реализации доступными через стандартные классы JCE, такие как Cipher
, KeyGenerator
, так далее.
Ограничения политики криптографии применяются классами JCE, а не bouncycastle. Поэтому, если вы не используете эти классы, вы не встретите никаких ограничений. С другой стороны, вы пожертвуете переносимостью. Чтобы начать, взгляните на javadocs для класса AESEngine и остальные javadocs для bouncycastle.
Почему нельзя просто добавить необходимые файлы политики?
Это было бы проще всего сделать. Если вы живете в США и экспортируете свое программное обеспечение в другие (возможно, "недопустимые") страны, у вас (теоретически) возникнут проблемы в любом случае (включая файлы политики / выполнение шифрования самостоятельно).
Если вы живете за пределами США, зачем даже беспокоиться об этом, просто включите файлы политики, никого не волнует.