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

Question

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

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

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

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

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

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

Answer 1

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

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

Обновлено

Брюс Шнайер :

"Однажды коллега сказал мне, что мир полон плохой безопасности системы, разработанные людьми, которые читают Прикладная криптография "

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

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

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

Answer 2

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

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

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

---

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

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

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

---

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

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

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

Answer 3

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