Сильнейший шифр для использования с C / C ++? - PullRequest
0 голосов
/ 02 апреля 2010

Мне просто интересно, если вы должны написать какое-то действительно безопасное приложение с данными, передаваемыми по незащищенным сетям, какой тип алгоритма шифрования вы будете использовать, чтобы сделать его безопасным? Я знаю несколько библиотек c ++ для шифрования, предоставляющих хорошие функции с различными алгоритмами, но я не совсем уверен, какой шифр использовать - AES, DES, RSA, Blowfish или что-то более другое?

Пожалуйста, предоставьте ваши идеи и предложения.

Ответы [ 9 ]

5 голосов
/ 02 апреля 2010

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

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

Если вы работаете в любой из обычных ОС POSIX, используйте / dev / random для генерации вашего ключа.

4 голосов
/ 02 апреля 2010

использовать AES для шифрования данных и использовать RSA для обмена ключами AES между сторонами

1 голос
/ 02 апреля 2010

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

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

В общем, это нерешенная проблема и область текущих исследований. Большинство или все реализации имеют недостатки, хотя для последних версий хорошо используемых библиотек, вероятно, не так, как кто-либо публично объявил, что они могут использовать. Атаки на основе синхронизации на OpenSSL были продемонстрированы в прошлом, хотя только в сильно предсказуемой локальной сети AFAIK. Вы можете тратить на это столько времени, сколько захотите, вплоть до всей вашей карьеры.

На практике просто используйте SSL, в любой реализации, которая поставляется с вашей платформой.

1 голос
/ 02 апреля 2010

Ответ: не надо. Если это должно быть безопасно, и вы задаете этот вопрос, это означает, что вам нужно найти эксперта по безопасности, чтобы сделать это. Вы не собираетесь разрабатывать безопасный протокол, обращаясь за помощью к SO. Вы можете [возможно] использовать существующий протокол, такой как ssh или TLS, но если вы свернете свой собственный, у вас не получится.

1 голос
/ 02 апреля 2010

Прежде всего вам нужно разделить симметричные блочные шифры с шифрами с открытым ключом :

  • у них действительно разные исполнения
  • их реализация действительно отличается
  • их сильные / слабые стороны основаны на различных факторах

Кстати:

  • DES больше не считается безопасным, всегда следует избегать его использования
  • AES по-прежнему считается безопасным (можно использовать 256-битные ключи)
  • RSA (и другие алгоритмы с открытым ключом, такие как ElGamal , Ellipctic Curve ) основаны на сложности математических задач, с которыми связаны эти алгоритмы основаны. Например: факторизация числа. Если количество битов, которые вы используете для хранения ключей, достаточно велико, вы можете считать их достаточно безопасными.

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

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

1 голос
/ 02 апреля 2010

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

Согласно их FAQ , это во многом зависит от того, что вы хотите сделать. Из их рекомендуемого списка алгоритмов :

блочный шифр: DES-EDE3, AES, Serpent (Serpent работает медленнее, чем AES, но имеет больший запас безопасности и не уязвим для временных атак.)
потоковый шифр: любой из вышеперечисленных блочных шифров в режиме CTR
быстрый потоковый шифр: Salsa20, Panama, Sosemanuk (доступно в версии 5.5)
хэш-функция: SHA-256, SHA-512, Whirlpool
код аутентификации сообщения: HMAC / SHA1 или HMAC с одной из вышеуказанных хеш-функций
шифрование с открытым ключом: RSA / OAEP / SHA1, ECIES
подпись: RSA / PSS / H, ECDSA / H, в которой H одна из вышеуказанных хеш-функций
ключевое соглашение: DH, ECDH
генератор случайных чисел: RandomPool, AutoSeededRandomPool

Мы не можем дать точный ответ, потому что нет ни одного, не зная больше о том, чего вы пытаетесь достичь.

1 голос
/ 02 апреля 2010

Любой из хорошо известных шифров имеет хорошо понятный уровень безопасности, поэтому его легко выполнить.Меня больше беспокоит качество и уровень доверия к используемой вами библиотеке, а также ошибки в ее использовании.Рассматривали ли вы возможность использования внешних программ, таких как ssh, для генерации ключа, обработки соединения и передачи его с помощью библиотеки API?

1 голос
/ 02 апреля 2010

Вы указали слишком мало требований для ваших нужд шифрования. Это зависит от обстоятельств.

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

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

Надеюсь, это поможет!

0 голосов
/ 02 апреля 2010

На самом деле, нам, возможно, не нужно знать все детали. Но, ИМХО, каскадируйте эти алгоритмы с помощью Chain Of Responsibility Pattern или Composite + Strategy.

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