Какой из подходов шифрования я должен использовать?

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

В настоящее время я думаю об этих методах:

  1. Пусть сервер сгенерирует 2048/4096-битные ключи RSA, отправит открытый ключ клиенту, пусть клиент зашифрует данные, а затем отправит их на сервер.
  2. Для обмена ключом AES-256 используйте метод обмена ключами, например, Диффи-Хеллмана (Диффи-Хеллман-Меркле).
  3. Инициируйте соединение TLS и сообщите серверу ключ AES напрямую.

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

PS: я мог бы использовать цепочку на симметричном алгоритме, как AES-Twofish-Serpent.

РЕДАКТИРОВАТЬ: Любое рекомендуемое программное обеспечение должно быть в лицензии, которая не ограничивает частное использование. LGPL настолько ограничен, насколько это возможно. Это исключает GPL.

12.10.2009 22:40:21
Я бы просто использовал GPG. Готов к использованию и своего рода отраслевой стандарт для электронной почты (для тех, кому небезразличны безопасные электронные письма). Но у вас могут быть особые требования, я не знаю.
liori 12.10.2009 22:48:01
AES-128 на самом деле более безопасен, чем другие варианты AES. neworder.box.sk/newsread.php?newsid=22916
Trevor Tippins 12.10.2009 22:49:56
GPG действительно бесполезен в этом случае. @ AES-128, будучи более безопасным, вряд ли AES близок к взлому. На странице, на которую вы ссылаетесь, даже говорится, что атаки совершенно непрактичны. Это также говорит, что только 9 раунд Rinjdael потенциально был сломан. Стандарт AES определяет минимум 10 раундов, а AFAIK 256-битная версия имеет 14 раундов.
CMircea 13.10.2009 20:41:58
Чтобы добавить больше к GPG, это под GPLv3, который я не могу использовать вообще.
CMircea 13.10.2009 20:47:43
3 ОТВЕТА
РЕШЕНИЕ

Я бы порекомендовал использовать существующую реализацию S / MIME (или CMS) с надежным криптографическим модулем для шифрования вашего контента.

Конвертированные данные S / MIME обеспечивают хороший формат для хранения зашифрованных данных «в состоянии покоя»: конверт записывает информацию об используемых алгоритмах и ключах, чтобы эта информация была доступна авторизованным получателям позже, когда это необходимо.

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


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

TLS и S / MIME зависят от наличия набора известных сертификатов CA на каждом клиенте. Они используются для подписи открытого ключа сервера, чтобы клиент мог обнаруживать попытки замены ключей. Протокол не может загрузиться сам; Должен существовать безопасный способ распространения «якорей доверия» вне диапазона.

Также обратите внимание, что RSA невероятно медленный по сравнению с симметричными шифрами. Реальные протоколы генерируют «ключ шифрования содержимого» для симметричного алгоритма, такого как AES, затем используют открытый ключ RSA в качестве «ключа шифрования ключа» для шифрования ключа шифрования содержимого для получателя (ей) сообщения.


Таким образом, основная проблема заключается в надежном получении вашего открытого ключа для клиента. Если вы можете сделать это, подойдет вариант № 1 или № 2 - при условии, что вы просто используете этот открытый ключ, а не пытаетесь отправить еще один «внутриполосный». На самом деле, в CMS вариант № 1 называется «транспортировкой ключей», а вариант № 2 называется «соглашением о ключах».

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

Хотя Crypto ++ является «отраслевым стандартом», его безопасность зависит от того, как вы его используете. Как Джерри сказал Крамеру: «Дверь должна быть… закрыта! » Использование криптографических примитивов в Crypto ++ с плохо разработанным протоколом ни к чему вас не приведет. Вот почему я подчеркиваю использование CMS (протокол более высокого уровня) вместе с хорошим криптографическим модулем (криптографические примитивы).

3
13.10.2009 22:56:54
Crypto ++ выглядит промышленным стандартом, по крайней мере для меня. Скорее всего, алгоритм не изменится, и даже если он изменится, все сохраненные файлы будут сопровождаться метаданными, поэтому изменение алгоритма не представляет проблемы.
CMircea 13.10.2009 20:45:32
Вот почему я спрашиваю здесь, чтобы убедиться, что я действительно использую это правильно.
CMircea 3.12.2009 13:17:35

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

Используйте готовые протоколы, такие как SSL / TLS. Например. TLS, инициализированный с парами ключей RSA для взаимной аутентификации, и звуки сеансовых ключей AES подходят для того, что вы описываете

обновленный

Брюс Шнайер :

«Коллега однажды сказал мне, что мир полон плохих систем безопасности, разработанных людьми, которые читают Прикладную криптографию»

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

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

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

11
13.10.2009 23:21:11
На самом деле, даже если вы криптограф, вы, скорее всего, ошибетесь. Вот почему криптографические алгоритмы и протоколы, как правило, разрабатываются группами, открыто и тщательно проверяются годами, прежде чем они будут развернуты.
Jörg W Mittag 13.10.2009 15:30:03
Я предполагаю, что я буду связывать OpenSSL и просто использовать TLS для подключения в этом случае. Однако, если я шифрую свои данные с помощью открытого ключа, который я получаю с сервера, зачем мне использовать TLS? Данные, зашифрованные с помощью открытого ключа, могут быть расшифрованы только с помощью закрытого ключа, который не покидает сервер.
CMircea 13.10.2009 20:43:49
@Wikie: Теоретически вы правы (исключая все проблемы с предоставлением открытого ключа, такие как корень доверия, обработка отзыва и т. Д. И т. Д.). На практике никто не шифрует данные с использованием ключа RSA. Вы шифруете его, используя ключ сеанса, и шифруете ключ сеанса, используя ключ RSA. Если используется шифрование канала (связанное, онлайн, синхронное), такой протокол, как TLS, выполняет управление ключами для вас (получение и обмен ключом сеанса). Если используется шифрование документа (отсоединенное, автономное, асинхронное), существуют протоколы, такие как S / MIME или PGP, которые решают эту проблему.
Remus Rusanu 13.10.2009 21:05:40
Зачем мне шифровать главный ключ с помощью ключа RSA? Это звучит бессмысленно ИМО. Это шифрование документов AFAIK.
CMircea 14.10.2009 11:15:00
Где вы собираетесь хранить симметричный ключ, связанный с документом? Собираетесь ли вы использовать один единственный ключ для всех ваших документов? Как вы собираетесь обрабатывать обновление ключей, повторно шифровать все существующие документы?
Remus Rusanu 14.10.2009 19:40:19

Как насчет SSH? (rsync по ssh например)?

0
13.10.2009 22:19:10
SSH - своего рода боль в Windows, и мне нужно больше, чем просто загрузить файлы. Я могу даже не загружать их, просто сообщить серверу ключ шифрования / получить его с сервера.
CMircea 14.10.2009 11:12:02