Pull to refresh

Comments 24

Из этого списка сегодня считаются безопасными только AES и ChaCha20. Другие алгоритмы были взломаны: люди смогли предсказывать их

Что правда что ли? И 3des?! (Double des)
Как народ то не боится карточками расплачиваться…
И вообще попытка рассказать все на уровне "детского сада" как то вызывает раздражение. Ощущение что автор снисходительно снизосходит…
Да лучше стандарты почитать!

> Что правда что ли? И 3des?! (Double des)

Да, вот тут можно почитать подробнее sweet32.info

> И вообще попытка рассказать все на уровне «детского сада» как то вызывает раздражение.

Я думаю, что это, наоборт, преимущество. Человек простым языком объяснил сложные вещи. Такие статьи вдохновляют на изучение чего-то нового.
Sweet32 не является атакой на конкретный алгоритм, это атака на режим CBC для всех блочных шифров с размером блока 64-бит (при условии, что на одном ключе шифруется достаточно большое количество данных).
К слову в статье сказано, что все алгоритмы работают по схеме XOR с открытым текстом, но это актуально только для потоковых шифров, блочные шифры работают по такой схеме только в некоторых режимах.
Ну и
Длина этого блока для AES128 128 бит, для AES256 — 256 бит, для ChaCha20 — 512 бит

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

Если тут какая-то ошибка (я её не вижу), напишите об этом в твиттер автору (https://twitter.com/colmmacc/status/1101578627592839168).
Размер блока для алгоритма AES всегда 128 бит и не зависит от длины ключа (который как раз 128, 192 или 256).
Для потокового шифра ChaCha20 говорить про размер блока, наверное, не совсем корректно, правильнее было бы говорить о размере состояния шифра.
> Sweet32 не является атакой на конкретный алгоритм

Но при этом с помощью него был взломан 3DES, так что ссылка правильная.
Думаю корректнее было бы сказать, что была взломана система шифрования, использующая алгоритм 3DES в режиме CBC (а также любой другой шифр с 64-битным блоком). Сам по себе алгоритм никто не взламывал.

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

Человек простым языком объяснил сложные вещи.
Говоря откровенно, не таким уж и простым языком. Вот пример из статьи:
Правила простые: если бит из A «1» ИЛИ бит из B «1», тогда мы устанавливаем соответствующий бит C в «1», но только в том случае, когда «A» и «B» одновременно не являются «1».
Ну и как Вам — простой язык?
А теперь то же самое действительно простым языком:

«Если биты A и B — разные, то A^B=1. Если же одинаковые, то A^B=0.»
> Ну и как Вам — простой язык?
> А теперь то же самое действительно простым языком:
> «Если биты A и B — разные, то A^B=1. Если же одинаковые, то A^B=0.»

Для меня лично и ваш вариант понятен, и вариант автора. Но из описания автора сразу становится ясно, почему эта операция носит название «исключающее или».
Да, вот тут можно почитать подробнее sweet32.info
Уязвимость алгоритма и уязвимость схемы его применения это разные вещи.
Впрочем, мегя опередили и это прокомментировали
Если ваше приложение для звонков отправляет данные только тогда, когда люди говорят, но не во время молчания, этого достаточно для того, чтобы восстановить 70% английской речи. Всего лишь из тишины. Страшно клёво.


Не поверил. Посмотрел оригинал. Там тоже кто-то не поверил, попросил пруфы. Получил в ответ такую ссылку: www.iis.sinica.edu.tw/~swc/pub/skype_voice_activity_detection.html

Я почитал, там пытаются находить тишину в трафике скайпа. И с 70-90% точностью им удаётся отлавливать участки тишины, несмотря на шифрование. Про восстановление речи там говорится ну просто совсем. Использования каких-то особеностей именно английской речи, по сравнению с любыми другими, тоже не было. Можно расходиться, сенсации не было.
Причём AES имеет немного запятнанную репутацию, потому что криптографы говорят следующее:


Кто-то редактировал наш сегмент ru.wikipedia.org/wiki/Triple_DES и сообщил следующее:

Тем не менее, 3DES понемногу выходит из употребления: на смену ему приходит новый алгоритмом AES Rijndael. Rijndael, реализованный программно, работает в шесть раз быстрее. Поэтому 3DES больше подходит для аппаратных реализаций. Многие системы безопасности продолжают поддерживать как 3DES, так и AES, по умолчанию используя AES. Хотя 3DES может поддерживаться для обратной совместимости, он больше не рекомендован к использованию.


Все же, что сейчас предпочтительнее в разработке применять?
Писал видимо кто-то из прошлого века, потому что 3des уже давно все забыли. Применять стоит алгоритмы на базе AES или той же ChaCha, зависит от задачи. Посмотрите на библиотеку libsodium

На 3des автоизационные криптограммы по чиповым картам и шифрлвание pin блоков для online pin. И это останется так еще много лет.
А применять нужно то что требуется для конкретной задачи. Где то и гост нужно (и сертифицированное по)

Но не надо беспокоиться — у нас почти всегда есть поддержка AES на уровне аппаратного обеспечения
Всегда удивлялся. Кто этому верит? А что если в процессоре стоит бекдор и если записать в пару регистров магические числа, то с каких-то других регистров можно прочитать последние использованные ключи? Шифруешь такой сообщение, а рядом програмка с парой строк ассемблера сливает твои ключи куда надо.

Вот буквально:

movl $0xdeadbeef, %r11
movq %r12, (key)
movq %r13, (key + 8)

Вместо 0xdeadbeef подставить секрет известный человеку, который заказал бекдор.
Заголовок:
Самое простое объяснение...

А теперь смотрим, как «просто» объясняют:
современное шифрование берёт вашу секретную строку и хитро комбинирует её со случайными данными.

Спасибо за хитрую простоту!
Статья не о том, как просто, а как пографоманствовать (я про оригинла) в манере хи-хи-ха-ха, да ещё, судя по комментам, с серьёзными ошибками.
Насчёт слово «хитро» – это просто я так перевёл фразу «in a clever way» ¯\_(ツ)_/¯

Я такие статьи воспринимаю как научно-популярные документальные фильмы, они тоже очень важны, даже если в них есть много упрощений. Именно поэтому я взялся переводить этот тред. Вот тут еще комментировал по этой теме habr.com/ru/post/443050/#comment_19886806
Самое простое объяснение принципа работы

Самая большая ложь во Вселенной..
Так, как не сможет прочитать злоумышленник. Зависит от модели угроз. Обычно используют протокол Диффи — Хеллмана.
Довольно странно что в статье с «самым простым объяснением шифрования» этот момент не раскрыт. Как будто шифрование имеет какой-либо смысл без обмена ключами.
Процесс обмена ключами выходит за рамки объяснения алгоритмов симметричного шифрования. Поэтому, видимо, автор не стал про них рассказывать. Алгоритмы обмена ключами используют асимметричное шифрование.
Only those users with full accounts are able to leave comments. Log in, please.