Для просмотра на высоком уровне следующие комментарии к обоим должны быть полезны.
Чрезвычайно легко создать протокол на основе RC4 (например, WEP), обладающий чрезвычайно низкой прочностью (его можно сломать на обычном оборудовании за считанные минуты, что считается крайне слабым).
Тройной DES невелик тем, что его сила достигается за счет чрезмерных усилий процессора, но он имеет значительно большую силу (как теоретически при атаках в реальном мире), чем RC4, поэтому должен быть выбран по умолчанию.
Идем немного глубже:
В области шифрования без четко определенного целевого приложения определение «наилучшего» по своей сути сложно, поскольку «пригодность» алгоритма является многовариантной.
- Простота реализации
- Можете ли вы запустить его на обычном оборудовании?
- Реализации подвержены случайным недостаткам, которые значительно снижают безопасность, но при этом допускают «правильность» поведения.
- Стоимость внедрения
- Мощность / кремний / время для кодирования / декодирования.
- усилие сломать
- Сопротивление грубой силе. Довольно количественно
- Стойкость к криптоанализу, менее измеримая, вы могли бы подумать, но, возможно, правильный человек еще не пробовал:)
- Гибкость
- Можете ли вы обменять одно из перечисленного на другое
- Какой максимальный размер ключа (таким образом, верхние пределы грубой силы)
- Какой размер входных данных необходим для получения достойного шифрования, требует ли он засолки.
На самом деле, чтобы отработать усилие, чтобы сломать себя, требуется много времени и усилий, поэтому вы (не криптограф) идете с чем-то уже сделанным, а не бросаете свое. Он также может изменяться со временем, возможно, исключительно в результате улучшения доступного аппаратного обеспечения, а не из-за фундаментальных недостатков обнаруживаемого алгоритма.
Основная проблема, конечно же, заключается в том, безопасна ли она? Следует отметить, что многие старые алгоритмы, ранее считавшиеся безопасными, больше не относятся к этой категории. Некоторые настолько разрушены, что их использование просто бессмысленно, у вас нет никакой защиты, просто неизвестность (полезно, но никак не сопоставимо с реальной безопасностью).
В настоящее время ни один из основных алгоритмов RC4 и TDES не входит в эту категорию, но наивная реализация RC4 считается крайне ошибочной в протоколах, где данные сообщения могут быть вынуждены повторяться. RC4 имеет несколько более существенных теоретических недостатков, чем TDES.
При этом TDES НЕ лучше RC4 во всех областях, перечисленных выше. Это значительно дороже для вычислений (и эта дороговизна неоправданна, существуют другие менее дорогие криптосистемы с сопоставимой безопасностью с TDES)
Если у вас есть приложение для реального мира, вы обычно получаете одно или оба из следующих:
- Ограничения на вашем оборудовании для выполнения задачи
- Ограничения, накладываемые данными, которые вы шифруете (это используется для передачи данных, которые должны храниться в секрете только в течение X дней ... например)
Тогда вы можете заявить, с допусками и допущениями, что может достичь этого (или если вы просто не можете) и пойти с этим.
При отсутствии таких ограничений мы можем дать вам только следующее:
Простота реализации
Оба имеют общедоступные безопасные бесплатные реализации практически для любой доступной архитектуры и платформы.
Реализации RC4 могут быть не такими безопасными, как вы думаете, если сообщение можно будет принудительно повторить (см. Проблемы WEP). Разумное использование соления может снизить этот риск, но это НЕ будет подвергаться тщательному анализу того, что исходные реализации были, и поэтому их следует рассматривать с подозрением.
Стоимость внедрения
У меня нет полезных тестов для RC4 (это СТАРЫЙ) http://www.cryptopp.com/benchmarks.html имеет несколько полезных руководств, чтобы поместить TDES в контекст с RC5, который медленнее, чем RC4 (TDES, по крайней мере, на порядок медленнее, чем RC4) RC4 может зашифровать поток примерно с 7 циклами на байт для быстрой реализации на современных процессорах x86 для сравнения.
Усилие сломать
Устойчивость к грубой силе TDES в настоящее время считается высокой даже при наличии множества выходов шифрования.
RC4 устойчивость к перебору на несколько порядков ниже, чем у TDES, а в некоторых режимах работы чрезвычайно низко (отказ от отбрасывания начальных битов потока)
Стойкость к криптоанализу. Для Triple DES есть общеизвестные недостатки, но они не снижают его эффективность до реалистичной атаки в течение ближайших двух или двух десятилетий, то же самое нельзя сказать о RC4, где известно и объединено несколько недостатков. произвел надежные атаки на несколько протоколов на его основе.
Гибкость
TDES имеет очень небольшую гибкость (и ваша библиотека может не раскрыть их в любом случае)
RC4 обладает гораздо большей гибкостью (теоретически ключ, используемый для его инициализации, может быть произвольно длинным, хотя библиотека может ограничить это.
Исходя из этого и вашего заявления о том, что вы должны использовать одну или другую, вы должны учитывать реализацию RC4 только в том случае, если стоимость CPU TripleDES делает нереалистичной реализацию в вашей среде, или низкий уровень безопасности, обеспечиваемый RC4, все еще значительно выше, чем ваши требования указать.
Я должен также отметить, что существуют системы, которые эмпирически лучше во всех областях, чем RC4 и TDES.
Проект eSTREAM оценивает различные потоковые шифры в порядке 5 или менее циклов на байт, хотя работа криптоанализа над ними на самом деле не завершена.
Существует много более быстрых и сильных блочных шифров, чтобы конкурировать с TDES. AES , вероятно, является самым известным и подходящим кандидатом, поскольку он имеет сопоставимую (если не лучшую) безопасность, но гораздо быстрее.