алгоритмы шифрования - PullRequest
       22

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

0 голосов
/ 19 марта 2011

У меня есть резервная сеть P2P, в которой одноранговый узел может хранить данные и впоследствии получать их от другого однорангового узла. Какие меры безопасности я могу предпринять, чтобы данные не читались другими пользователями, которые их не создавали? Я собирался использовать шифрование с одним ключом и цифровые подписи, но я уверен, что это правильный подход. Заранее спасибо за помощь

Ответы [ 4 ]

1 голос
/ 19 марта 2011

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

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

0 голосов
/ 19 марта 2011

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

Чтобы взломать, к примеру, секретный токен, используемый для подписи некоторого URL-адреса или пароля за хешем md5, вы можете просто запустить несколько экземпляров Amazon EC2, просто заплативих на то время, когда они вам нужны, и распределите атаку грубой силой.Большинство алгоритмов работают намного лучше на графических процессорах, чем на CPUS, но в основном это более удобно, потому что вы можете арендовать и совместно использовать процессоры.

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

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

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

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

Итак, после этого вступления ... Так какой же путь?

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

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

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

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

0 голосов
/ 19 марта 2011

Вопрос неопределенный, но в любом случае здесь идет речь:

Каждый узел генерирует уникальный ключ шифрования - известный только ему самому.Когда ему нужно хранить данные, он должен делать, например: хеш-данные, например, с помощью алгоритма SHA, объединять данные и хэшировать, шифровать, хранить.Это позволяет проводить дешевую проверку данных после получения без необходимости работать с асимметричными алгоритмами.

Подводя итог: используйте алгоритмы хеширования и симметричного шифрования без известных недостатков, таких как SHA-2 и AES, избегайте, например, MD5 и DES,Нет необходимости в асимметричных алгоритмах, таких как RSA / DSA, лучше подписать с помощью встроенного хэша.

0 голосов
/ 19 марта 2011

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

Сертификаты (или открытые / закрытые ключи) не нужны, поскольку ни один другой пользователь не вовлечен в процесс шифрования.

Примите во внимание также необходимость использования функции MAC (Код аутентификации сообщения), чтобы гарантировать, что сохраненные данные не будут изменены.

...