На какие наземные мины безопасности мне следует обратить внимание с помощью JCA и AES? - PullRequest
1 голос
/ 18 июня 2009

Я использую Java Cryptography API с AES для шифрования коротких строк текста для использования при идентификации файлов cookie пользователем.

Насколько я понимаю, некоторые алгоритмы шифрования небезопасны при использовании с небольшим количеством текста по сравнению с размером ключа. Что мне нужно знать, чтобы убедиться, что я не оставляю свои данные незащищенными? Нужно ли гарантировать, что строка для шифрования длиннее ключа? Есть ли другие мины?

Для генерации ключа я делаю следующее с encryptionType = "AES" и keySize = 128:

public SecretKey createKey() throws NoSuchAlgorithmException {
    KeyGenerator keyGen = KeyGenerator.getInstance(encryptionType);
    keyGen.init(keySize); // 192 and 256 bits may not be available
    return keyGen.generateKey();
}

public String encrypt(Key key, String str) throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, UnsupportedEncodingException, IllegalBlockSizeException, BadPaddingException {
    Cipher ecipher = Cipher.getInstance(encryptionType);
    ecipher.init(Cipher.ENCRYPT_MODE, key);
    byte[] utf8 = str.getBytes("UTF8");
    byte[] enc = ecipher.doFinal(utf8);
    return new BASE64Encoder().encode(enc);
}

public String decrypt(Key key, String str) throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, IOException, IllegalBlockSizeException, BadPaddingException {
    Cipher dcipher = Cipher.getInstance(encryptionType);
    dcipher.init(Cipher.DECRYPT_MODE, key);
    byte[] dec = new BASE64Decoder().decodeBuffer(str);
    byte[] utf8 = dcipher.doFinal(dec);
    return new String(utf8, "UTF8");
}

Ответы [ 3 ]

0 голосов
/ 18 июня 2009

Вы можете начать с этого списка 25 самых опасных программных ошибок , который относится именно к ошибкам безопасности.

0 голосов
/ 18 июня 2009

Хотя для коротких сообщений потребуется заполнение, в этом вопросе ничего не говорится о заполнении. Выбор дополнения может повлиять на безопасность некоторых шифров.

Также в вопросе не указан режим шифрования. Для коротких случайных «сообщений», таких как случайно выбранные идентификаторы пользователя, режим ECB безопасен и имеет то преимущество, что для шифра не требуется вектор инициализации. Однако для сообщений длиной более 16 байт использование режима ECB может выявить шаблоны в виде открытого текста и уязвимо для атак воспроизведения.

Использование других режимов (CBC является распространенным) потребует другого вектора инициализации для каждого сообщения. Очевидно, что для дешифрования потребуется IV, и это обычно приводит к его передаче вместе с шифротекстом.

0 голосов
/ 18 июня 2009

Вам необходимо ознакомиться с принципами проектирования защищенной системы, которые выходят за рамки выбора конкретного алгоритма шифрования.

В принципе AES предназначен для безопасного шифрования пакетов в наименьшем размере (16 байт). Но нужно обратить внимание на его использование в общей схеме безопасности. Обратите внимание на общий дизайн протокола.

Например, я слышал о какой-то онлайн-игре в прошлом (не могу найти ссылку извините), которая зашифровала все свои данные. Проблема заключалась в том, что он не включал никаких «семян». Таким образом, команда сделать что-то конкретное, например, дать игроку дополнительную жизнь, каждый раз имела одинаковую последовательность (зашифрованных) байтов. Таким образом, игрок может просто скопировать этот пакет и отправить его на сервер много раз, даже не зная, какие незашифрованные данные содержатся в пакете.

...