шифрование / дешифрование и Java - основные вопросы - PullRequest
0 голосов
/ 29 ноября 2009

Я должен реализовать следующий сценарий.

Пользователь вызывает веб-сервис, отправляя запрос с текстом, который должен быть зашифрован моим сервисом, если он не зашифрован. После этого он должен быть сохранен в базе данных. Это хорошая идея, чтобы объявить этот атрибут в xsd как String, или это лучший тип? Должен ли я разрешить использовать CDATA?

Используя Jaxb, я преобразую этот xml в класс с паролем, хранящимся в объекте String. Это нормально, если предположить, что строка является Unicode (2 байта)?

Я должен использовать API, который является оберткой для клиента RSA, с двумя способами:

  • decryptInformation (String)
  • encryptInformation (String)

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

Я также видел, что люди используют класс Base64 для кодирования и декодирования. Должен ли я использовать его перед сохранением зашифрованного текста в базе данных? Не могли бы вы объяснить это мне по-простому?

Ответы [ 3 ]

4 голосов
/ 29 ноября 2009

По необходимости кодирования
При многих методах шифрования зашифрованный текст , то есть зашифрованная форма сообщения, представляет собой массив байтов , т.е. если рассматривать как последовательность "символов", зашифрованный текст может содержать любой символ между 0 и 255 (десятичное) или $ 00 и $ FF (шестнадцатеричное). Такой диапазон символов включает в себя множество непечатаемых символов, например, «tab» или «eot», а также символы с кодом выше 128, интерпретация которых может различаться.
Кроме того, даже не учитывая эти непечатаемые или не-ASCII-символы, некоторые символы в зашифрованном тексте могут быть такими, что они «отбрасывают» интерпретацию возможного формата, в котором включен зашифрованный текст (как для пример XML, как подсказано в вопросе).

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

Все кодирование (от двоичного до текстоподобного формата) приводит к использованию большего пространства для закодированной формы данных. Base64 - популярный формат, потому что он относительно компактен.

Другим возможным форматом кодирования является шестнадцатеричный («база 16»), который занимает вдвое больший размер, чем исходные двоичные данные. Шестнадцатеричный также проще / проще в использовании, поскольку существует прямое отображение между любым байтом на входе и его двумя соответствующими символами на выходе. (при этом Base64 использует 1,25 символа для кодирования одного байта, что приводит к блокам из 3 входных байтов для закодированных байтов)

О необходимости «побега» закодированных данных
После того как зашифрованный текст закодирован, он все еще может содержать символы, допускающие отбрасывание структуры «внешнего» формата, в который включен зашифрованный текст, и поэтому в случае XML вы можете захотеть «экранировать» этот контент как CDATA. (Это не обязательно с шестнадцатеричным и может не потребоваться в Base64, в зависимости от двух дополнительных используемых символов (Base64 использует от 0 до 9, от A до Z, от th до z и два дополнительных символа, обычно + и /, а также =).

О необходимости хранения данных в базе данных как Base64 (или другая кодировка)
Люди используют Base64 (или аналогичные кодировки) для хранения данных в базах данных по двум причинам:

  • для введения [слабого / слабого] шифрования, для данных, которые легко доступны в текстовом виде . Это слабая форма шифрования, так как кто-то может быстро определить кодировку. Тем не менее, это делает хранимые данные менее «очевидными».
  • для хранения данных в двоичном виде в формате TEXT.

Большинство СУБД включают в себя типы данных, которые позволяют хранить последовательности байтов в двоичном формате, и поэтому нет необходимости использовать кодирование и хранение в формате текстового типа. Тем не менее, есть много причин, по которым люди все еще могут сохранять текст:

  • потому что данные в конечном итоге передаются / используются в качестве закодированного текста (нет необходимости шифровать во время выполнения, просто шифруйте один раз при сохранении данных)
  • для облегчения переносимости
  • для облегчения отладки
1 голос
/ 29 ноября 2009

Насколько я понимаю, вот последовательность, которую вы должны реализовать:

  1. Отправить открытый ключ сервера клиенту
  2. Заставить клиента подписать пароль (возвращает byte[])
  3. Base64 кодирует подписанный пароль (возвращает String)
  4. Отправьте строку base64 через ваш веб-сервис (используя xsd:base64Binary)
  5. На сервере unmarshall (используя JAXB) пароль (возвращает байтовый массив)
  6. Сохранение строки в кодировке base64, шестнадцатеричной строки или байтового массива (в Lob).
0 голосов
/ 29 ноября 2009

В зависимости от вашего метода шифрования зашифрованная строка может содержать произвольные порядки байтов, включая вещи, которые могут запутать синтаксический анализатор XML - включая такие вещи, как ]]>, что маловероятно, но возможно. Кроме того, зашифрованное перемешивание может содержать NULL-байты или другие невидимые символы, которые создают проблемы при передаче файла.

Кодировка Base 64 гарантирует, что только «действительные» символы заканчиваются в документе, поэтому кодировку Base 64 следует кодировать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...