Выбор алгоритма шифрования

Question

Мое требование: нужно обменять некоторые ключи между сервером и клиентом (J2EE).

Ключ - это просто фрагмент текста, может быть числом, строкой, размер которой, вероятно, будет не более 30 символов.

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

Q1) Устаревший код использует PBEWithMD5AndDES.Я хотел бы знать, уместно ли это.

Что может быть лучше в контексте производительности?

ОБНОВЛЕНИЕ:

• На стороне клиента не будет логики.Сервер отправляет зашифрованную строку клиенту, а клиент возвращает ее.Так же, как jsessionid.

• Ключ не слишком чувствителен, как номер кредитной карты.Но его необходимо заменить в нечитаемом формате, лучше, чем обычная техника кодирования

ОБНОВЛЕНИЕ 2:

• Вот сценарий.Мы отправляем электронное письмо клиенту, в котором мы включаем «отписаться» от оповещений.Нажатие на эту ссылку должно деактивировать оповещения без запроса входа в систему.Итак, я зашифровал его userID и включил в него ссылку для отмены подписки.На стороне сервера я расшифровываю и деактивирую его / ее предупреждения.Таким образом, параметры, передаваемые хакерами, не будут работать.

Answer 1

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

Или просто используйте что-нибудь сильное и симметричный ключ, например, AES256.

Я бы не стал использовать DES для новых систем, он довольно старый и доказал свою надежность.

Что касается фактической реализации, я не совсем уверен, что в этом вопросе достаточно подробностей.

Answer 2

Я бы предложил AES-256 . На данный момент он нерушим и становится стандартом для надежного симметричного шифрования.

Также он полностью поддерживается Java (см. java.security и javax.crypto ). Кроме того, AES поддерживается многими бесплатными инструментами, вы можете использовать его, например, с OpenSSL в Unix.
AES256 сильно влияет на производительность, но это не будет проблемой при шифровании 30 строк / документов. (Если, конечно, их нет миллионов).

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

• Алгоритм шифрования: AES с использованием 256-битного ключа
• Режим блокировки: CBC (Цепочка блоков шифрования)
• Заполнение: PKCS5Padding

Answer 3

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

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

Answer 4

AES256 был бы хорошим вариантом. Надежный и перспективный.Но это было бы тяжелым выступлением.Другой вариант - RC4.