RC4 взломан или не взломан?
Если, допустим, пропустить 3072 начальных байта кейстрима с биасом, и приделать к каждому зашифрованному сообщению рандомный nonce, хэшируя с которым пароль генерировать ключ для RC4 будет это надёжно или нет?
Ссылки
[link1] https://www.pgpru.com/forum/kriptografija/povysheniekriptostojjkostirc4
[link2] https://www.pgpru.com/novosti/2009/vprotokolahssltlsnajjdenakriticheskajaujazvimostj
[link3] http://www.cosic.esat.kuleuven.be/nessie/
[link4] https://www.cosic.esat.kuleuven.be/nessie/deliverables/D20-v2.pdf
[link5] http://www.ecrypt.eu.org/stream/
[link6] http://diskcryptor.net/forum/index.php?action=dlattach;topic=452.0;attach=249;image
[link7] https://xakep.ru/2015/07/16/rc4-nomore/
[link8] https://www.pgpru.com/comment61886
А перевод можно?
Просто как бы уже есть некоторые широкоизвесные термины, такие как ключевой поток, ВИ и т.д., зачем изобретать новые?
По теме: я бы не стал его использовать. А Ваши предложения о усилении равнозначны творчеству на тему: а переделаю я шифр, и сделаю его надежнее... К чему зачатстую это приводит, я думаю, знаете.
Я думаю, что тот кто может ответить на мой вопрос всё понял и так. Не люблю формализм в обычном общении.
Почему?
Вовсе даже не мои предложения.
Судя Вашей логике я не могу ответить на этот вопрос, так что будем ждать :)
Повышение стойкости RC4[link1]
Особо советую обратить внимание:
unknown: "Для RC4 найдено большое число различителей. Он проваливает даже статистические тесты при объеме шифртекста 2 Gb. Есть отклонения в распределении биграмм и т.д. Это не означает практического взлома, но означает дефектность алгоритма."
А это значит никакие отбросы первых байт или магические преобразования ключа не помогут.
П. С.: и учитесь поиском пользоваться + учитесь находить ответы на вопросы, берегите время специалистов. Не попугаи ведь.
Ну так и где определённый ответ можно найти? Я бы не полез на форум, если бы нашёл что-нибудь. Если RC4 абсолютный хлам, то почему до сих пор его спокойно включает стандарт SSL?
Смотря для чего его использовать, какой уровень безопасности нужен и т.д. Насколько важную информацию будете шифровать и т.д.
Много факторов, на которые нужно впервую очередь смотреть при выборе алгоритма шифрования.
Если не бояться, что из 10000 пользователей 10001-й поламает, то вполне можно использовать, если конечно правильно использовать.
Я бы не парил себе мозг... Для тех задач, которые мне приходиться решать, RC4 – хлам. А для Вас – нужно смотреть. Одно дело для банка, другое дело для сайта юных физиков-неатомщиков.
Кстати, сейчас развелось много фирм, чьи консультанты помогут :)
С 40-битовым ключом, ага? А ещё там есть DES. А ещё — архитектурная ошибка[link2]...
Утверждение "А или не А" всегда истинно, поэтому ответ на вопрос темы – да. :)
Ну, скажем так, длина ключа в RC4 никогда не была проблемой. Она может составлять до 256 байт. Triple-DES там действительно есть, и NIST оценивает его как достаточно надёжный алгоритм. А архитектурная ошибка это давно известная проблема до которой никому не было дела, поскольку она затрагивает только экзотические случаи применения SSL.
Но всё же эта тема не про SSL, а про RC4.
Это уже похоже на рекламу... Пытаемся доказать надежность RC4 тем, что он входит в какой-то там стандарт?)
Если так уверены? Зачем тогда спрашиваем? Используйте на здоровье...
Поломают, тогда поймете :)
Не надёжность, а доверие криптографической общественности.
Неконструктивно.
Я не пытаюсь Вам что-то доказать. Спосили – ответил, не верите – Ваше личное дело.
У меня, если чесно, нету никакой заинтересованности переубеждать Вас в чем-то.
Если мне не изменяет склероз, RC4 был добавлен в SSL прежде всего ради экспортных реализаций с 80- и 40-битовыми ключами, а не за какие-то особые заслуги.
DES, именно DES с одним ключом.
Собственно, я об этом вспомнил, только чтобы показать несостоятельность Вашей логики в апеллировании к SSL.
Сыграло свою роль и то, что выбор потоковых шифров был невелик. К тому же, 40-битовая версия RC4 это дела минувших дней, сейчас там 128 битный вариант.
Мне кажется, что в актуальной специфкации SSL я не видел требований к включению DES.
Пусть автор поксорит множества, порождаемые своими вопросами :)
SHA-1, например, тоже взломан, хотя практической атаки продемонстрировано не было. Но не выкинули же его мгновенно из всех стандартов.
RC4 разрешается временно (на свой страх и риск) использовать для старых приложений в целях совместимости с применением примерно тех костылей, что вы сказали.
В новых приложениях RC4 использовать не рекомендуется.
RC4 был заявлен в конкурс NESSIE[link3], ещё до того, как на него были открыты серьёзные атаки, но уже тогда по многим возражениям криптографов его сняли с конкурса (читайте отчёты NESSIE[link4] если вам интересны подробности).
Собственно в отчёте NESSIE из 342 страниц по поводу RC4 уделили маленький абзац:
На нём поставили крест, ещё до того как были открыты более серьёзные атаки, которые пока ещё можно обойти костылями в практическом использовании.
Пока никакого доверямого стойкого потокового шифра нет вообще, его ещё долго будут тащить в стандартах, но уже не включат в качестве кандидата ни в один конкурс на новый.
Конкурс NESSIE в итоге не смог выдвинуть в финалисты ни одного потокового шифра.
Сейчас медленно, муторно и без гарантии на успех проходит конкурс потоковых шифров eStream[link5], одной из мотиваций проведения которого, было придумать что-нибудь вместо RC4, а то с теорией потоковых шифров (как и хэшей) вообще как-то плохо дела обстоят.
Пока доверяемо стойких потоковых шифров не существует рекомендуется использовать блочные в режиме поточного, например AES-counter.
Благодарю за отличный комментарий.
Спасибо всем участникам дискуссии за проявленный интерес к теме :-)
Извиняюсь за регулярно повторенный ляп:
Конкурс eStream[link5] год назад как завершён, голосование прошло, финалисты выбраны, отчёты опубликованы ;-)
Но по аналогии с конкурсом блочных шифров NESSIE, это было чисто академическим мероприятием и результаты не входят ни в какой стандарт.
А шифры, которые стали финалистами, так и не являются доверяемыми, потому что слишком быстро опубликовали работы с новыми атаками.
Надеюсь хоть конкурс хэш функций пройдёт как следует. Что-то там затихло всё.
, . ,
(Brian Gladman) AES128 ,
5 15 .
Даниэль_Надь, gpg --clearsign не поддерживается, но gpg -sa следует юзать, и не забыть правильно указать кодировку галочкой.
SATtva, может быть, следует написать возле капчи s/OpenPGP-подписанное сообщение в кодировке/OpenPGP-подписанное сообщение (gpg -sa) в кодировке/
Бред.
Сранивали RC4 на Pentium II, и AES на Core 2 Duo?
Тестовый код в студию. Сразу скажу – не верю, ибо сравнивал, и по результатам RC4 был быстрее почти на порядок.
[off-topic]
Нет: для винды это не обязательно, а кроме gpg есть и другие реализации. Вся информация есть по ссылке "Помощь". Даниэля извиняет, что он занятой человек и ему некогда читать всякие местные хэлпы.
[/off-topic]
Я голословному утверждению не поверил, и сделал бенчмарк сам. И действительно, скорость AES-128 в ассемблерной реализации Гладмана на моём Core i7 равна 152 мегабайта/сек, RC4 (тупой код из вики) – 260 мб/с, RC4 (оптимизированный сишний код) – 327 мб/с. Думаю хорошая ассемблерная реализация RC4 даст больше 400 мб/с. Не знаю что и как вы меряли, но могу предположить, что вы специально выбрали самую медленную реализацию RC4 какую нашли и скомпилировали её с отключенной оптимизацией.
На Core i7 есть аппаратная реализация AES ;)
На i7 нет, есть на i5, скорость больше 3 Гб/сек[link6]
Хакеры показали практичный метод взлома RC4[link7]
Не новость, вообще-то. Просто закрыть тему. Но могли бы и не показывать.
Все доработки RC4 не изменяли количества индексов, если сделать кол-во индексов не 2(i,j), как в тек.версии а например 8-32? Примерно так:
Цикл 1й генерации:
i[1] = i[1] + S[i[0]] +B; //В – входной байт или 0
поменяли_местами(S[i[0]] и S[i[1]]);
ротация_индексов(i); // i[0]=i[1]=...i[n]=i[0]
c = (S[ i[0] ] + S[ i[1] ] + S[ i[2] ] ) ^ 0xAA;
output S[c];
Это конечно уже не рс4, может у данной схемы будут перспективы?
или перестановочному алгоритму совсем плохо и никакие изменения не помогут?