Интересно, а есть ссылка на закон?Да, новое золото теперь это.
Сейчас еще вели закон что в течение 72 часов в США компании должны будут оповещать службы о киберинцидентах, так как много данных компания имеет о своих клиентах и партнерах. Как это повлияет на "рынок" интересно теперь будет посмотреть.
-
XSS.stack #1 – первый литературный журнал от юзеров форума
Технологии, позволяющие обратить вспять атаки ransomware
- Автор темы rainstorm
- Дата начала
- Автор темы
- Добавить закладку
- #22
вот ссылка на новый закон
Congress Passes 72-Hour Federal Breach Reporting Law for Critical Infrastructure | Insights | Greenberg Traurig LLP
As part of a larger spending bill signed by President Biden on March 15, 2022, Congress passed the Cyber Incident Reporting for Critical Infrastructure Act (CIRA) to increase funding for the federal Cybersecurity and Critical Infrastructure Agency (CISA).
www.gtlaw.com
- Автор темы
- Добавить закладку
- #23
Я бы позволила тебе оплодотворить меня. Я ЛЮБЛЮ ТЕБЯ ЛБ
Если какие-то рансомы юзают 1 ключ на все файлы + хранят его в криптоапи, то мб и поможет. Для нормальной схемы - нет. Хайп на умных словах типа "ии".
Именно так. Я вижу, что это эффективное решение для некоторых локеров, но для большинства оно не поможет восстановить ключ и только привлечет к себе внимание. Разработчики будут адаптироваться.
Да. И американцы будут поджигать свои деньги на средствах защиты. Много хорошего это им принесло )))
Это все теория, на практике AES256 с его ключиком длиной всего 32 байта еще не был взломан (при условии не криворукого использования алгоритма)
А если еще учитывать, что на каждый файл генерируется свой новый и уникальный ключ AES со случайным IV, то даже если будет зашифрован заранее подготовленный файл, для проведения статистики и анализа, в лучшем случае исследователям удастся получить ключ только от этого файла.
Это лишняя работа, все известные мне криптобиблиотеки, будь то Crypto++, botan, mbedtls, libgcrypt и другие автоматически модифицируют IV в каждом блоке в процессе шифрования, поэтому излишне дополнительно наращивать энтропию еще и в ключе. Можешь проверить на примере любой из перечисленных библиотек, посмотреть что у тебя находится в буфере IV до шифрования, и что находится там после шифрования, на каждом шифруемом блоке IV будет меняться. Этого достаточно, что бы использовать один ключ на протяжении всего файла и не беспокоиться о расшифровке.
К тому же в предложенном варианте есть недостаток, если каким-то образом удастся определить ключ, которым были зашифрованы первые 4кб, то все остальные ключи так же будут раскрыты, потому что меняются они линейно, банально применяется хеширование на каждые следующие 4кб от предыдущего ключа. А это вполне реалистичный вариант, если учитывать что в начале файлов как правило располагаются заголовки форматов, и они для одного и того же типа файла одинаковые, так что предположить, что находится в зашифрованном файле для проведения анализа в таком случае можно.
Но этот же самый недостаток присутствует и при классическом шифровании, когда используется один ключ на весь файл. Поэтому метод с модификацией ключа по ходу шифрования равносилен методу без модификации ключа и не дает никаких преимуществ. Если первый блок в 4 кб будет раскрыт, то файл будет дешифрован полностью в обоих случаях. Хеширование ключа на каждой итерации не спасет.
Конечно шансы на дешифровку таким методом очень малы, но это показывает бесполезность линейного изменения ключа. Если взломан начальный ключ и известен алгоритм изменения ключа, то все последующие ключи находятся без проблем.
Лучшим решеним в такой ситуации будет генерация абсолютно нового ключа, на каждый блок из 4кб, в котором не будет никаких математических зависимостей от предыдущего ключа. Но отсюда вытекают и недостатки, ключей будет много, и их нужно сохранять в файл, а это +лишний вес.
Последнее редактирование:
Последнее редактирование:
Ключевой момент в статье заключается в том, что ключ RSA был длиной всего 1024 бит (что уже не безопасно по определению), а так же обращаем внимание на число сообщений, необходимых для анализа в данном случае.
Делаем вывод, что при длине ключа 2048 или даже 4096, и правильном использовании, беспокоиться о дешифровке на момент 2023 года не имеет смысла.
Но все же с одним утверждением в статье я согласен, с RSA давно уже стоит переходить на ECDH. Рано или поздно мощностей хватит и на 2048 бит ключик.
Вы не внимательно читали алг или не разбираетесь в вопросе, там нет этого недостатка.
Знание ключа от первого 4кб блока - encrypt_file_block_key = sha512(base_key) никак не раскрывает base_key из которого будет получен ключ для следующего блока. Будьте внимательнее.
Это вы невнимательно читали мои мысли, либо что-то не так поняли, я имел ввиду раскрытие (пока что в теории, далее поймете почему) самого первого ключа, то есть base_key в самом первом его состоянии, от которого и ведутся все изменения последующих ключей.
Если base_key будет скомпрометирован, все ключи от всех блоков будут раскрыты, в независимости от того какой бы там сложный хеш ни использовался.
Но вы пропустили главную строчку в моем сообщении, выше я написал, что и ваш подход, и классический подход имеют одинаковую фактическую стойкость для такого рода атаки на реальных, не подставных файлах и текущих мощностях, и вероятность взлома стремится к нулю. Потому что все эти методы анализа существуют лишь в теории, и работают лишь в идеальных лабораторных условиях, на практике еще никто не взломал AES-256. И это факт.
Поэтому ваш алгоритм это оверхед, лишние действия, занимающие процессорное время, но не дающие видимой пользы. Это как нацепить на танк 3000мм брони, тогда как на данный момент не существует гранатометов способных пробить больше +-1000мм.
Это имеет место быть, но зачем ? Как музейный экспонат, может и сойдет, но для боевых действий вряд ли.
Последнее редактирование:
Внимаение вопрос каким ключем шифруются первые 4кб?
Будьте внимательнее, первые 4кб как и вторые не шифруются base_key, ключем base_key вообще ничего не шифруется.
Если бы в понимали алгроритм но при этом подразумевали утечку base_key вы бы не стали писать о шифровании первых 4кб, потому что это просто бессмыссленно. Вы бы написали об утечке изначального значения base_key, что было бы тупо. Тупо потому что - в чем разница между утечкой изначального моего base_key и изначального aes256 key и iv, про утечку изначального ключа вообще нет смысла упоминать.
Был бы смысл упомянуть первые 4кб если бы по ним можно было вычислить изначальный base_key, но этого сделать не выйдет, поскольку хеширование не обратимая операция.
И еще IV имеют не все алгоритмы и даже не все вариации aes, я не делал привяки к конкретному алгу шифрования а лишь показал суть подхода.
И я демонстрировал не оптимизацию и глубокое знание криптографии а простейший прием который может понять
При чем тут оверхед и утечка base_key мне не понятно.
Это верно, мысли я читать не умею совсем.
Создадут уникум дешифратор который всё что угодно расшифрует хD ) (сказки)
AES 256 и RSA для ключа, я бы посмотрел как они расшифруют )
AES 256 и RSA для ключа, я бы посмотрел как они расшифруют )
Это понятно младенцу. Бейз кей (из вашего алго) нужен только для формирования последующих ключей, которыми уже и будет производиться шифрование. Если вы думаете, что я не понял этого, спешу вас разочаровать.
Не утечка, а именно компрометация (теоретическая), допустим грубым перебором (что невозможно, но взлом AES это же теория, пока никто его не взломал, а если мы говорим о теории, то тут допустимы любые предположения) или любым другим способом атаки на AES и алгоритмы хеширования.
Именно, разницы нет, поэтому если по-вашему утечка, или по-моему компрометация base_key невозможна, так же как и aes256 key и iv, то нет смысла городить непонятные надстройки, все и так хорошо работает.
Причина в предыдущем цитировании.
Для того что бы показать, что и ваш алго, и классический подход дают на выходе файлы, которые невозможно расшифровать. Только классика будет работать быстрее, вот и все.
Последнее редактирование:
Да это понятно.
Но ведь цель была показать концепт сочиненный буквально не отходя от кассы без привязки к конкретным алгам криптования.
Про оптимизацию там говорить не уместно, послкольку предлагалось не кокретное решение, а логика как это надо делать, причем специально было выложено псевдокодом первое что в голову приходит, и читателю не надо даже знать про всякие aes256cbc.
Вы кстати не откоментировали про вашу привязку к первым 4кб =)
Получилось вот что - вы заговорили про конкретную оптимизацию изложенного на уровне логики концепта, концепт предлагался не как алгоритм к применению в коде а как пример понятный широкой публике.
А вы это прямо вот в серьез восприняли, плохо чуствуете контекст, указали на слабость ключа которой нет(для получения базы по первым 4кб нужно востановить sha512 а потом для этого ша512 найти базу от которой он был взят, найти IV для аеs256 будет на много проще).
То есть вы были не уместны и технически не коректны.
Это относилось к взаимосвязи между ключиком, которым реально шифруются эти 4кб, и бейзкею, из которого он получается. Опять же, рассуждаем мы сугубо в теоретическом контексте, и путь поиска base_key выглядит так:
1) нахождение ключа, которым зашифрованы первые 4кб
2) нахождение из этого ключа base_key (так как хеширование операция необратимая, то нахождение скорее всего будет делаться полным перебором хешей)
На это все уйдут миллионы лет на самом топовом железе, в принципе как и если в лоб брутить классическое применение AES.
Но так как все это лысая теория, а практика говорит нам, что на данный момент AES неуязвим, то возвращаемся к тому, что городить второй забор от соседа не нужно, когда он и первый обойти не может.
Основной посыл заключался в том, что нет разницы, если будут брутить первые 4кб зашифрованные по вашему алгоритму, или 4кб по классическому алгоритму. В обоих случаях это нерешаемая задача.
Я хотел что бы вы это сами поняли, и у меня это получилось, вот ваша цитата:
Хочу поправить, iv не скрывается, и часто даже прикладывается к зашифрованному сообщению в открытом виде.
Сделано это для того, что бы можно было использовать один ключ, с разными iv, для исключения атаки по большому числу сообщений, зашифрованных одним и тем же ключиком.
И от того, что iv используется публичный, стойкость AES не снижается, так уж он устроен.
Дело в том, что любой PoC при реализации в конкретном решении будет подвергаться оптимизациям, особенно в сфере криптографии. Поэтому желательно учитывать это с самого начала проектирования, а не вбрасывать первое, что пришло в голову, иначе это, извините, не концепт, а просто болтовня. Ну либо конецпт, но не очень удачный, от которого либо придется отказаться, либо кардинально переделать.
Теперь про чувство контекста.
Получается некоторое противоречие. Если мы говорим о контексте, то тема, в которой мы вообще сейчас ведем диалог, связана с Ransomware. А в контексте рансома, алго криптования, которые мы можем использовать, это AES, ChaCha, ECC, RSA и другие, как минимум не уступающие им по надежности. Никто в здравом уме не будет использовать RC4 или что-то подобное. И в данном контексте, не имеет смысла подразумевать алгоритмы, отличные от приведенных мной. "без привязки" тут не катит.
Так что ваше замечание насчет контекста здесь неуместно. Я заговорил о AES не случайно, как раз в контексте поднятой проблемы. И если предлагаете PoC, то нужно следовать контексту))
Если подводить черту, хочется выразить следующее. У меня есть классический AES, тут мне предлагают PoC, увеличивающий криптостойкость и так неуязвимого алгоритма, за счет снижения производительности (да, хеширование это очень ресурсоемкая задача, а еще умножаем это на число блоков в каждом файле и на общее число файлов), но отдавая производительность, взамен я не получаю ничего принципиально нового.
Банальный и наглядный пример, у меня в руке кружка наполненая водой до краев, а вы подходите ко мне и предлагаете налить в нее еще воду, вода вытечет из кружки, она мне не нужна, у меня и так полная кружка.
Если вы придумываете новый алгоритм, либо улучшаете старый, он должен быть хоть в чем-то лучше оригинала, что бы плюсы от изменений перевешивали вылезшие минусы.
Последнее редактирование:
Контекст который вы комментировали это был мой пост #11 который был контр аргументом к утверждениею из поста #9.
И находится в контексте это значит учитывать к чему именно был пост, это нормально когда в теме в процессе рассуждений и диалого люди уходят в сторону и рассматривают концепты, но вы взяли контраргумент, оторвали от аргумента, поместили в контекст который для него не предполагался.
Раз уж вы любите аналогии то дело было так, два человека находясь рядом с домом Ерёмы перекинулись словцом про Фому, а вы решили им доказать что все это никак не относится с Федоту который как известно дружит с Павлом а тот в свою очередь будучи в состоянии алкагольного опьянения лапал женну Ерёмы, за что и был в последсвии бит неравнодушным гражданином имя которого осталось неизвестным.
Да и еще, как то сравнить криптоалгоримы построенные на обратимых операцах с криптоалгоритмами построенными на не обратимых - тоже не хорошо, и аргумент что лично вам на сегодняшний день не известны случаи взлома аес256 тоже так себе аргумент. Не нравится одно хеширование на каждых 4кб, сделайте на каждых 40кб.
Последнее редактирование:
Где вы увидели сравнение ? Я перечислил список алгоритмов, которые используются в рансоме чаще всего, это и симметирчные системы, и системы с открытым ключом одновременно, так как по отдельности они сейчас не применяются. Где вы увидели здесь сравнение, я понятия не имею, rc4 был приведен как пример плохого симметричного алгоритма для таких задач, учитывая контекст. Начинаете цепляться к словам ? Признак поражения в споре.
Как же вы любите все переворачивать в удобную себе сторону. Ну ладно, кажется вы просто не умеете признавать то, что не правы. Такое бывает, за сим покидаю диалог. Ничего конструктивного он больше не обещает. А как все начиналось, вы подавали большие надежды.
Последнее редактирование:
Странно было бы переворачивать в не удобную себе сторону, особенно если оно изначльно удобно повернуто само по себе.
А вообще ниче так перетерли за криптоалгоритмы, было весело, а такое вынуждент признать бывает не часто.
Не пропадайте любезный, у меня на ваш счет хорошие предчуствия в плане неожиднных разговоров о всяком интересном.
Радует, что на форуме, есть такие спецы 