LINUX.ORG.RU

Мамкины криптографы. AES.

 


0

1

Щас будет тупой вопрос. Режимы ECB, CBC и т.п. тут не суть.

  1. Сам по себе AES блочный симметричный: если ключ не меняется, то для одного и того же шифруемого текста выход алгоритма (шифротекст) будет один и тот же. То есть, посылая через такую сырую хрень одинаковые HTTP-запросы, перехватчик будет видеть, что запросы идут одинаковые. Или что у них одинаковое начало)

  2. Поэтому добавляют всякие там initialization vector и подобные приколы.

  3. Вопрос треда в том, насколько нижеописанная идея избавления от повторяемости нормальна, годна, жизнеспособна и криптостойка в целом.

—- Описание идеи —-

  • обмена ключами нет: никакого Diffie–Hellman. Ключ известен двум сторонам заранее, он достаточно длинный и его точно никто не знает, кроме админа Васи, который руками сходил разложил. Ясно, что тут АНБ уже Васю завербовало, но не суть.

  • когда одна сторона хочет законнектиться, то она генерит рандомную строку 1024 байтиков, шифрует её ключом, отправляет другой стороне.

  • Далее эта строка в комбинации с ключом (xor например) уже используется как ключ для всей дальнейшей коммуникации.

  • Всё. В этом месте достигнут кайф. Повторяемости гарантированно взяться неоткуда при не меняющемся ключе. Вопрос в том, верно ли это, что кайф произошёл. В чём тут проблемы, где жопа?

Возможно это уже как-то называется и реализовано, но вопрос школьный и тупой, поэтому автор не в курсе. Спасибо.



Последнее исправление: lesopilorama (всего исправлений: 5)

Ответ на: комментарий от no-such-file

Ну кстати да, можно наверное… НАДО ПОДУМАТЬ! Ну во-первых затем, чтобы можно было ещё к этому IV приаттачить в конце его sha1 и на приёмнике сразу сделать проверку, что сам ключ шифрования годен и всё годно расшифровывается.

lesopilorama
() автор топика
Последнее исправление: lesopilorama (всего исправлений: 1)

Первый вопрос про криптостойкость AES, дальше идут какие-то попытки переизобрести сессионный ключ, как тут уже заметили.

Учебник по криптографии лучше читать последовательно и вдумчиво.

seiken ★★★★★
()

Чтобы избежать возможных проблем, нужно только отделить отправку этой строки от отправки первых данных.

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

Если так не сделать то злоумышленник может запомнить отправленный от клиента пакет со строкой и началом данных и потом слать его серверу ещё раз через какое-то время. Сервер будет думать что это настоящий клиент (т.к. всё соблюдено) и, вероятно, либо предпринимать какие-то действия, либо что-то отвечать клиенту (всегда с одним и тем же ключом получается). Оба результата злоумышленник может как-то использовать.

firkax ★★★★★
()

Ключ известен двум сторонам заранее, он достаточно длинный и его точно никто не знает

посылая через такую сырую хрень одинаковые HTTP-запросы

use TLS1.2 он сам все сделает

anonymous2 ★★★★★
()
Последнее исправление: anonymous2 (всего исправлений: 1)

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

peregrine ★★★★★
()
Ответ на: комментарий от lesopilorama

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

От того что ты их ещё один раз сессионным ключём помажешь что поменяется? Ну или объясняй нормально от какой атаки твой велосипед должен защищать. Я вот думал что тебя волнует то что у тебя злоумышленника интересует совершает ли подключившийся к серверу какие-то действия, которые статистически видно по одинаковым запросам. Например 5 запросов типа A, 3 запроса типа Б и 7 запросов типа В означает что подключившийся что-то сделал конкретное, ещё и размер ответов можно отслеживать для надёжности. От того что ты превратишь их в 5 Запросов типа Я, 3 запроса типа И и 7 запросов типа У ты ничуть не усложнишь жизнь злоумышленнику.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

От того что ты их ещё один раз сессионным ключём помажешь что поменяется?

Поменяется только то, что байтики в юзерском payload станут гарантированно каждый раз меняться.

lesopilorama
() автор топика
Ответ на: комментарий от lesopilorama

Каждый раз это при смене сессии? Как часто у тебя будет меняться сессия? Чаще чем свершаемые юзером действия факт свершения которых интересен злоумышленнику или реже? Если реже то смысла 0. Или ты ксорить запросы с гигабайтным ключом предлагаешь?

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от peregrine

Каждый раз это при смене сессии? Как часто у тебя будет меняться сессия?

Короч не очень ясно, с чего берутся умозаключения о том, что AES-трансмиссия на одном и том же ключе длиной в месяц может быть расшифрована как-то особо более вероятно, чем на ключе, поменянном через час)

lesopilorama
() автор топика
Ответ на: комментарий от peregrine

А, да, я пропустил этот момент. Рандомный сессионный ключ конечно нельзя использовать как AES-ключ. Правильная схема такая: AES-ключ вообще не трогаем (он всегда одинаковый), а рандомную строку используем для генерации chacha20-последовательности (точнее, двух - одну для C>S и вторую для S>C отправок) с которой делаем xor перед aes-шифрованием и после aes-дешифрования. Ну или вместо chacha20 можно использовать другой криптографический рандом-генератор, но особого смысла не вижу. Раньше использовали rc4.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от vbr

Ну можешь зашифровать, если делать нечего. Сильно хуже вроде не должно стать.

Станет однозначно лучше - уменьшится поверхность атаки. А минусов вообще никаких.

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от firkax

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

vbr ★★★
()

вот ты законнектился и передал картинку. Чтобы увидеть эту картинку не нужно будет даже ничего расшифровывать.

IV нужны, чтобы одинаковые блоки изменялись даже если идут в одном соединении один за другим.

sergej ★★★★★
()
Ответ на: комментарий от peregrine

Какими ещё повторениями? Посмотри что такое chacha20, никаких повторений там нет. Вариант с «сделаем новый AES-ключ из той строки» разумеется неправильный, я уже про это написал.

firkax ★★★★★
()
Ответ на: комментарий от vbr

Уменьшится. И никакого лишнего кода, наоборот это проще реализовать.

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

Вот именно, поэтому не надо с такой уверенностью заявлять что не уменьшится.

firkax ★★★★★
()
Ответ на: комментарий от vbr

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

Так если не чёрный ящик, то давайте прозрачно логичные причины конкретно что-то не вызывать или вызывать. А то «это не чёрный ящик», а потом «можно и напороться». Так если можно напороться, значит хрен знает что там у вас и как раз «чёрный ящик». Бугага. Ладно. Просто это такой типичный кринжовый поворот в теме криптухи, когда собеседник начинает заявлять, что «лучше не надо», потом что «а хрен знает что может случиться» и хрен знает как первое со вторым связано, что тоже оправдывается таинственностью и загадочностью тематики)

lesopilorama
() автор топика
Последнее исправление: lesopilorama (всего исправлений: 1)
Ответ на: комментарий от sergej

Мм, это ты описал не IV, а block chaining (ну или другие варианты сделать из block cipher что-то полезное).

А ТС да, изобрёл смесь IV с сессионным ключом.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от lesopilorama

Криптографию в мире понимает человек 100 может. И шансы того, что они окажутся на лоре невелики. А нам, простым работягам остаётся только креститься и перестраховываться, не используя ничего нетрадиционного и нестандартного. Чем чаще читаешь CVE, связанные с криптографией, тем лучше это понимаешь.

Поэтому ответ на твой исходный вопрос - берёшь какой-нибудь AES GCM и всё. Если тебе надо сессию установить - берёшь TLS, реализованный в популярной библиотеке.

vbr ★★★
()
Ответ на: комментарий от vbr

Криптографию в мире понимает человек 100 может.

Ложное утверждение, много кто понимает. Тема за последнее время сильно популяризирована, много кто успел копнуть вглубь, а особенно с этими криптовалютами тема ещё больше разраслась. Тема криптухи сильно разрекламирована, много кто успел повникать, она повсюду. Много кто свои протоколы пишет (самое известное - Николай Дуров MTProto: там же никакой магии, всё вроде бы собрано из понятных логичных блоков, работа которых хорошо изучена: мол, ключами обмениваемся так-то, а блоки шифруем в таком-то режиме). А ещё сколько народу менее известных чё-то пишет своё на коленке и оно работает и не ломается. Ну да, это особо чувствительная тема, ну да, нужно не писать код с багами, но это тоже реально, есть ещё код-ревью и тесты всякие) Опять же, например ты написал свою реализацию AES и думаешь как бы проверить. Да просто берёшь, шифруешь что-то коммерческой шифровалкой и расшифровываешь своей. С багами у тебя просто ничё не шасшифруется совсем и наоборот. А бекдоры и уязвимости с переполнениями: ну это скорее уже приколы не с твоим алгоритмом шифрования, а с реализацией сервера, куда заслали байтики и переполнили ему буфер и всю память сервера прочитали. Остаются всякие тонкие материи в том духе, что «как бы нам потреблять процессором ток монотонно, чтобы по замерам тока питания нельзя было понять что делает алгоритм», но это уже ненужная дичь в области сетевого программирования.

lesopilorama
() автор топика
Последнее исправление: lesopilorama (всего исправлений: 2)

наверное вам будет интересно поискать историю, почему RC4/ArcFour перестал считаться безопасным шифром для больших объемов данных.

PS: А еще разницу между ECB и CBC,GCM гляньте, в случае ECB возможно будут какие-то сомнения, а вот в случае «перехлеста» данных... повторы шифрованных данных, при одинаковых исходных будут гарантиовано исключены.

Sylvia ★★★★★
()
Последнее исправление: Sylvia (всего исправлений: 1)

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

Если тебе это не важно, то лучше взять готовый AES-CGM, там и иммитовставка, и IV.

maxcom ★★★★★
()
Ответ на: комментарий от Sylvia

А еще разницу между ECB и CBC,GCM гляньте, в случае ECB возможно будут какие-то сомнения, а вот в случае «перехлеста» данных… повторы шифрованных данных, при одинаковых исходных будут гарантиовано исключены.

Кажется понимаю сее. ECB конечно слишком наивно, нужен перехлёст с лавинным замесом.

lesopilorama
() автор топика

Тред не читал, почитай как работает AES. Блочное шифрование - это часть протокола, у него есть еще несколько режимов работы. Прям неизменным ключем шифруется каждый блок только в ECB, который, НЯП, особо не рекомендован к применению.

—- Описание идеи —-

Никак не решает проблему с повторяемостью ключа. У тебя получается что твоя рандомная строка XOR-нутая с ключом выступает как ключ шифрования. Если открытый текст длиннее строки - то у тебя будет переиспользование ключа.

anonymous
()

В чём тут проблемы, где жопа?

На самом деле плюс-минус полноценный ответ на твой вопрос звучит так.

Есть две возможности: либо тебе нужна PFS, либо не нужна.

В первом случае ты в жопе, потому что тот, кто получит доступ к долговременному ключу и дампу трафика, сможет восстановить временный ключ. Чтобы вылезти из жопы, юзай DH.

Во втором случае ты переизобрёл IV with extra steps. Шифровать его не нужно, можно передавать открытым текстом.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Ага спасибо за интересную мысль. PFS в идеале конечно нужна наверное чуть более чем всем. Клёвая же особенность: перехваченный старый трафик не подлежит дешифрации при выпытывании ключа паяльником.

Я тут подумал: обойдусь без этого свойства. Я хочу получить обновление бинарника с сервера и передать на сервер телеметрию. Мне хочется избавиться только от man in the middle, чтобы мне бинарник не подменили и чужой. А то, что враг потом получит содержимое моих переданных бинарников, когда выпытает ключ у кого-то - относительно пофигу.

И вот «выпытает ключ» тут самое критичное. От этого ведь нет защиты уже. Плюс, ключ служит и аутентификацией клиента. У кого ключ от «vasya», тот и настоящий «vasya». Всмысле, если клиент пришёл на сервер и сказал, что он «vasya» и серверу удалось с ним пообщаться через «vasya»-ключ, то значит это и был вася. То есть, что-то, доказывающее, что ты вася, на клиенте быть должно: ключ, пароль и т.п. Так пусть этим средством служит долговременный, который юзается для шифрования.

lesopilorama
() автор топика
Ответ на: комментарий от lesopilorama

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

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

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

vbr ★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от lesopilorama

Проблема в том, что ты не осознаешь сути сложности. Просто возьми и почитай книжки по теме. Их хватает. Не статьи и не видосы с ютуба, а нормальные толстенькие книжки. С дискретной математикой и прочими развлечениями. Да, это не прикольно, это скучно, но ты после этого не будешь приходить с такими вопросами, если дочитаешь. А будешь осознанно использовать готовые криптосхемы )

Не просто так говорят «never roll your own cryptography». Не просто так.

vbr ★★★
()
Последнее исправление: vbr (всего исправлений: 1)

«Чувак посередине» перехватывает твою шифрованную рандомную строку, подменяет ей все последующие рандомные строки, и получает то, от чего ты защищался.

Puzan ★★★★★
()