Как создать надежный ключ шифрования для TripleDESCryptoServiceProvider - PullRequest
3 голосов
/ 09 октября 2011

Я использую TripleDESCryptoServiceProvider и мне нужно хранить ключ шифрования.

Если я вызываю метод провайдеров GenerateKey, это просто строка в кодировке base64? Если да, могу ли я безопасно его расшифровать, например, использовать полученную строку как ключ?

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

Ответы [ 2 ]

4 голосов
/ 09 октября 2011

Вызов GenerateKey сгенерирует новый, случайный безопасный (т. Е. Не слабый) ключ. Его длина (128 или 192) будет зависеть от того, как настроен ваш TripleDESCryptoServiceProvider.

Если я вызываю метод провайдера GenerateKey, это просто строка в кодировке 64?

Сам формат представляет собой массив byte[], поскольку вы можете извлечь его только из свойства Key - так что это , а не base64, но при желании его можно легко закодировать таким образом, например Convert.ToBase64String(algo.Key);

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

Вы не можете использовать строку в качестве ключа - нет, если вы не конвертируете ее обратно в byte[]. Однако вы можете хранить ключ как строку между его использованием (если это поможет вашему приложению).

На немного другой ноте, есть ли проблема с использованием этого же ключа в качестве солт-ключа при выполнении односторонних хэшей?

Если вы используете случайные данные в качестве ключа или в качестве соли , то проблем быть не должно. Только не используйте одни и те же данные для и ( и ).

1 голос
/ 09 октября 2011

На несколько другой ноте, есть ли проблемы с использованием этого тот же ключ, что и солевой ключ при выполнении односторонних хэшей?

Соли являются публичными параметрами; а закрытые и симметричные ключи должны быть секретными.

Я пишу простой членский провайдер для .net, который позволяет Пользователь выбирает метод шифрования (обычный, хэш, зашифрованный), так Интересно, нужно ли было заставлять пользователя указывать как соль? ключ и ключ шифрования.

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

...