Комментарии 37
Статья интересная, но мне было бы проще применить SSL даже там, где оно того не требует. Просто потому, что это пара строчек готового кода с готовыми примерами и готовыми решениями. А здесь все это надо тестить/отлаживать, разрабатывать. Да и шифрование вполне нормальное получится:)
Иногда применить SSL не проще. SSL предполагает наличие сокета, точнее, он сам является сокетом. И он уж явно более затратный по ресурсам. Даже если забыть о том, что эти простенькие алгоритмы можно использовать вообще для чего-то несетевого, то всё равно даже и для сети можно найти применения, например, подумайте о том, как сделать нечто такое для UDP.
я так думаю человек имел в виду openssl, в функции которого на вход подаем исходную строку (буфер), и на выходе получаем зашифрованную строку (буфер)
Я всё равно настаиваю, что использовать SSL может быть не проще в каких-то ситуациях. Случаи бывают разные. Допустим, у вас микропроцессор с ограниченным объёмом ROM и RAM, и openssl там нет. Обычно в таких случаях полагаются либо на hardware решения на регистрах сдвига, но если нужно именно простое программное решение? Я соглашусь, что при наличии соответствующих библиотек может быть проще написать и отладить с openssl (или каком-то другом алгоритме), но будет ли это быстрее работать? Не верю, за исключением, может быть случаев, когда имеется hardware поддержка.
В таком случае — да, однако во введении вы обозначили область применения как «простая защита там, где без защиты стремно, а серьезно защищать нечего». Поэтому я вам и отвечаю, что при наличие готовых библиотек — проще, быстрей и дешевле сделать готовое, чем городить этот колхоз.
Хотя на контроллерах да, ваше решение может быть полезно.
Хотя на контроллерах да, ваше решение может быть полезно.
>подумайте о том, как сделать нечто такое для UDP
преимущества использования UDP испаряются, если обратить внимание на то, что для такого шифрования необходимо получить предыдущий блок для расшифровки текущего.
преимущества использования UDP испаряются, если обратить внимание на то, что для такого шифрования необходимо получить предыдущий блок для расшифровки текущего.
О преимуществах UDP никто и не заикался… А также и том, что конкретная реализация с использование этих идей будет именно поточная. Обратите внимание, что описанная вами проблема касается в основном передачи потоков через непотоко-ориентированные каналы, т.е. это скорее затронет поточные шифры, да и то зависит от того, как их использовать. Если сделать шифрование блока/сообщения самодостаточным, то такой проблемы нет.
И никакого сравнения с существующими поточными шифрами ни по скорости, ни по криптостойкости. Совершенно не обоснованная статья. Не верю, что лучше уже проверенных временем поточных шифров.
Нормальная статья. То что здесь описано — это скремблирование, и оно имеет отличную от шифрования область применения. Область применения шифрования — это когда можно обеспечить секретность ключа. Когда же ключ, данные и алгоритм неизбежно доступны злоумышленнику, то единственный выход — скремблирование, а его нужно делать своим собственным, уникальным алгоритмом, и всячески защищать его от реверс-инженеринга. Известный алгоритм легко идентифицировать в коде и выковырять к нему ключ, неизвестный же придется долго и упорно реверсить, да еще его можно сделать специально неудобным для злоумышленника.
> Когда же ключ, данные и алгоритм неизбежно доступны злоумышленнику, то единственный выход — скремблирование.
В этом случае злоумышленнику нужно просто подставить ключ и данные в алгоритм и получить исходное сообщение :)
>То что здесь описано — это скремблирование, и оно имеет отличную от шифрования область применения.
И в этой области применения вполне достаточно простого смешивания с спевдослучайной последовательностью.
В этом случае злоумышленнику нужно просто подставить ключ и данные в алгоритм и получить исходное сообщение :)
>То что здесь описано — это скремблирование, и оно имеет отличную от шифрования область применения.
И в этой области применения вполне достаточно простого смешивания с спевдослучайной последовательностью.
> В этом случае злоумышленнику нужно просто подставить ключ и данные в алгоритм и получить исходное сообщение :)
Но сначала нужно найти ключ и алгоритм, а это может быть не так просто. И реализация нужного алгоритма может плохо ложиться на платформу, на которой злоумышленник хочет расшифровывать данные. Например скремблируется сетевой трафик, причем скремблируется так, что чтобы получить хоть часть данных надо расшифровать их полностью. И алгоритм скремблирования содержит много операций и никак не упрощается. Злоумышленнику придется потратить много денег на покупку оборудования, ресерс-инженеринг алгоритмов и программирование дешифрации, чтобы читать такой трафик.
> И в этой области применения вполне достаточно простого смешивания с спевдослучайной последовательностью.
В этой области нет, и не может быть универсальных рецептов. Каждый случай индивидуален, и под него можно придумать оптимальный алгоритм.
Но сначала нужно найти ключ и алгоритм, а это может быть не так просто. И реализация нужного алгоритма может плохо ложиться на платформу, на которой злоумышленник хочет расшифровывать данные. Например скремблируется сетевой трафик, причем скремблируется так, что чтобы получить хоть часть данных надо расшифровать их полностью. И алгоритм скремблирования содержит много операций и никак не упрощается. Злоумышленнику придется потратить много денег на покупку оборудования, ресерс-инженеринг алгоритмов и программирование дешифрации, чтобы читать такой трафик.
> И в этой области применения вполне достаточно простого смешивания с спевдослучайной последовательностью.
В этой области нет, и не может быть универсальных рецептов. Каждый случай индивидуален, и под него можно придумать оптимальный алгоритм.
Намного полезнее будет подумать в сторону криптостойкого генератора псевдослучайных чисел. А если не нужна криптостойкость, то и не городить ничего, а использовать линейный конгруэнтный.
Намного полезнее будет подумать головой. А что использовать — зависит от задачи. Глупо давать конкретные советы не зная где и как это используется.
дайте пример области применения, где не подойдет то, что я предлагаю и подойдет то, что написано в этой статье.
Пример номер раз: мы делаем защиту софта от реверс-инженеринга и нам нужно заскремблировать код, чтобы усложнить его анализ хакером. Алгоритм должен быть как можно сложнее и запутаннее, и желательно меняться при каждой компиляции. Тогда будет сложно сделать автоматический распаковщик.
Пример номер два: мы делаем некий протокол, который провайдеры очень хотели бы заблокировать (p2p, Skype, e.t.c.). Нам нужно как можно сильнее усложнить им жизнь и увеличить их расходы. Для этого скремблирование стоит сделать двойным: алгоритм первого слоя зависит от данных и помимо расшифровки выдает на выходе ключ для второго слоя. В итоге чтобы отличить данные от случайных придется как минимум расшифровывать весь первый слой целиком и часть второго. Реализация будет сложной и потребует много ресурсов, и чтобы фильтровать трафик пользователей никаких денег не хватит.
Пример номер два: мы делаем некий протокол, который провайдеры очень хотели бы заблокировать (p2p, Skype, e.t.c.). Нам нужно как можно сильнее усложнить им жизнь и увеличить их расходы. Для этого скремблирование стоит сделать двойным: алгоритм первого слоя зависит от данных и помимо расшифровки выдает на выходе ключ для второго слоя. В итоге чтобы отличить данные от случайных придется как минимум расшифровывать весь первый слой целиком и часть второго. Реализация будет сложной и потребует много ресурсов, и чтобы фильтровать трафик пользователей никаких денег не хватит.
Для скремблирования много где найдется применение. Что первым приходит в голову — это неблокируемый провайдерами файлообмен. Для этого достаточно придумать такой алгоритм, реалтаймовое дешифрование которого для многих гигабит трафика стоило бы провайдеру слишком больших денег. И чтобы не было никаких особенностей трафика, позволяющих это заблокировать средствами циски.
Во-первых, тут не излагается конкретный алгоритм, а даются оригинальные идеи (по-крайней мере две).
Во-вторых, эти идея не обязательно использовать для потоков, более того, идея шафлера вообще может быть использована для чего-то далёкого от шифрования.
В-третьих, сравнивать скорости имеет смысл только для конкретных реализаций в конкретных условиях. Хотя у меня есть большие сомнения, что можно обогнать такую простую арифметику, как здесь.
В-четвёртых, сравнивать криптостойкость… А это сильно важно надо для тех применеий для которых оно рассчитано? Она очевидно лучше, чем у часто применяемого XOR с фиксированым ключом и использующих его это почему-то не сильно волнует, причем этот алгоритм ненамного сложнее в реализации.
Во-вторых, эти идея не обязательно использовать для потоков, более того, идея шафлера вообще может быть использована для чего-то далёкого от шифрования.
В-третьих, сравнивать скорости имеет смысл только для конкретных реализаций в конкретных условиях. Хотя у меня есть большие сомнения, что можно обогнать такую простую арифметику, как здесь.
В-четвёртых, сравнивать криптостойкость… А это сильно важно надо для тех применеий для которых оно рассчитано? Она очевидно лучше, чем у часто применяемого XOR с фиксированым ключом и использующих его это почему-то не сильно волнует, причем этот алгоритм ненамного сложнее в реализации.
Вот алго попроще:
1) Генерим keysize рэндомных байт
2) Шифруем данные любым понравившимся поточным алгоритмосом
3) Пишем в начало мессаджа key, потом данные
При получении считываем key, потом расшифровываем данные
4) ?????
5) PROFIT!
Единственный минус который можно придумать — длинна данных вырастает на keysize байт.
1) Генерим keysize рэндомных байт
2) Шифруем данные любым понравившимся поточным алгоритмосом
3) Пишем в начало мессаджа key, потом данные
При получении считываем key, потом расшифровываем данные
4) ?????
5) PROFIT!
Единственный минус который можно придумать — длинна данных вырастает на keysize байт.
Проще чего? Куда уж проще-то? Сложность "любого понравившегося поточного алгоритма" вы учитываете в общей сложности своего алгоритма?
Кстати, применение поточного алгоритма в лоб с одим ключом к одинаковым данным даёт одинаковый результат, что уже само по себе недостаток с точки зрения криптографии. В статье указано, как с этим просто забороться. Хотя идея добавления мусора перед данными не нова, но в своё время я этот велосипед изобрёл сам (интернета тогда, можно сказать, не было).
Собственно, в статье даются идеи, изложенные на пальцах. Уверен, что кому-то эти идеи будут полезны.
Кстати, применение поточного алгоритма в лоб с одим ключом к одинаковым данным даёт одинаковый результат, что уже само по себе недостаток с точки зрения криптографии. В статье указано, как с этим просто забороться. Хотя идея добавления мусора перед данными не нова, но в своё время я этот велосипед изобрёл сам (интернета тогда, можно сказать, не было).
Собственно, в статье даются идеи, изложенные на пальцах. Уверен, что кому-то эти идеи будут полезны.
>Проще чего? Куда уж проще-то?
Проще, чем придумывать что то радикально своё. Я имею в виду сложность разработки решения для поставленной задачи
>Кстати, применение поточного алгоритма в лоб с одим ключом к одинаковым данным даёт одинаковый результат, что уже само по себе недостаток с точки зрения криптографии.
см п. 1.
Притензий к идеям в статье, кстати, не имею, просто указываю на более простой в реализации вариант.
Проще, чем придумывать что то радикально своё. Я имею в виду сложность разработки решения для поставленной задачи
>Кстати, применение поточного алгоритма в лоб с одим ключом к одинаковым данным даёт одинаковый результат, что уже само по себе недостаток с точки зрения криптографии.
см п. 1.
Притензий к идеям в статье, кстати, не имею, просто указываю на более простой в реализации вариант.
Придумывать уже не надо — я же не зря надрывался, когда статью писал. Так что этот пункт уже отпадает. (это я нашутил)
В конце концов все эти поточные шифры кто-то когда-то изобрёл, и сделали это люди (скорее всего) как мы. Развелось их (шифров) уже столько, что время, потраченное на выбор алгоритма, уже сопоставимо со временем написания своего. Да, я осознаю, что защита слабаная на коленке и основанная на закрытости кода скорее всего устоит лишь до первой действительно серьёзной попытки взлома. Но тут такой задачи и не ставилось, да и не уверен я, что он так просто сдастся… Хотя у меня и есть некие идеи по взлому этого кода, но математически эта задача непростая, а идеи изложенные тут очень generic, так что при необходимости его можно легко отмасштабировать для увеличения стойкости, например, увеличить битность параметров генератора ключей.
В конце концов все эти поточные шифры кто-то когда-то изобрёл, и сделали это люди (скорее всего) как мы. Развелось их (шифров) уже столько, что время, потраченное на выбор алгоритма, уже сопоставимо со временем написания своего. Да, я осознаю, что защита слабаная на коленке и основанная на закрытости кода скорее всего устоит лишь до первой действительно серьёзной попытки взлома. Но тут такой задачи и не ставилось, да и не уверен я, что он так просто сдастся… Хотя у меня и есть некие идеи по взлому этого кода, но математически эта задача непростая, а идеи изложенные тут очень generic, так что при необходимости его можно легко отмасштабировать для увеличения стойкости, например, увеличить битность параметров генератора ключей.
Зато очень легко взламывается ) для защиты об блокировки провайдерами слабовато будет )
Не сложнее, чем предложенный в статье. Суть та же: не знаешь алго — куришь в сторонке.
Ведь суть скремблирования (обфускации), чтобы внешне поток данных был не отличим от случайных. Удачи провайдерам в попытках разбора данных на нестандартных портах — перебирать все алгоритмы и возможные способы обфускации для их оборудования — непозволительная роскошь.
Хотите большего? Пользуйте нормальное шифрование
Ведь суть скремблирования (обфускации), чтобы внешне поток данных был не отличим от случайных. Удачи провайдерам в попытках разбора данных на нестандартных портах — перебирать все алгоритмы и возможные способы обфускации для их оборудования — непозволительная роскошь.
Хотите большего? Пользуйте нормальное шифрование
Сейчас читаю в перерывах на работе книгу «Практическая криптография» Нильса Фергюсона.
Так вот, один из основных тезисов криптографии — это «При́нцип Керкго́ффса», согласно которому в секрете должны держаться только ключи. Все остальное должно быть известно публично (на это следуюет опираться).
А выдумывание своей функции кодирования — это как раз прямое противоречие этому принципу. Это может работать, если применяется дома, или на небольшом предприятии, но полагаться на секретность функции кодирования в более-менее больших системах — зло (утечка информации в любом виде о функции ломает всю систему защиты).
Хотя тоже моменты спорны :) вот тут habrahabr.ru/blogs/crypto/116481/ — как раз проблема ФБР, что они не знают «функции» кодирования
Так вот, один из основных тезисов криптографии — это «При́нцип Керкго́ффса», согласно которому в секрете должны держаться только ключи. Все остальное должно быть известно публично (на это следуюет опираться).
А выдумывание своей функции кодирования — это как раз прямое противоречие этому принципу. Это может работать, если применяется дома, или на небольшом предприятии, но полагаться на секретность функции кодирования в более-менее больших системах — зло (утечка информации в любом виде о функции ломает всю систему защиты).
Хотя тоже моменты спорны :) вот тут habrahabr.ru/blogs/crypto/116481/ — как раз проблема ФБР, что они не знают «функции» кодирования
Я уже в комментах писал про это. Конечно да, основная сложность во взломе первой идеи — это добыть сам алгоритм, и это явно больше чем полдела. Но, допустим, ключи (в данном случае параметры генератора) не присутствуют в коде — это я оставил на усмотрение программиста. Математическая задача нахождения этих параметров довольно нетривиальна и она сильно зависит от функций. Если приоритетом была скорость, то битность параметров скорее всего определяется битностью платформы, но я специально не оговаривал то, что делается в F() и Q(), а там этих параметров может быть сколько угодно. Подбирать брутфорсом можно, тем более к счастью-несчастью алгоритм быстрый, но какой будет критерий подбора, если в начале идёт мусор? Да, доказать криптостойкость даже для какой-то конкретной реализации будет проблематично, а оно вам действительно важно для этих применений? Вон радиообмен военных лётчиков НАТО слушают и картинку с предаторов без проблем смотрят, а вы говорите… Кстати, для предаторов этого шифра было бы достаточно — доступ к его коду получить непросто, для этого сначала нужно его сбить или выкрасть.
Ничего не спорные моменты, ФБР не знает ни ключ, ни алгоритм. У них только зашифрованный текст есть. Ну и конечно же предположение, что алгоритм должен быть простой и не криптостойкий, ведь человек мог в уме шифровать.
На самом деле можно существенно усложнить взлом, используя только скремблирование.
В том числе подменять алгоритм в случае, если по вторичным признакам мы обнаруживаем, что нас отлаживают. В этом случае взломщику придется копать, почему в отладчике все путем, а без него все падает. В итоге для взлома требуется более высокая квалификация, следовательно, вероятность падает.
В том числе подменять алгоритм в случае, если по вторичным признакам мы обнаруживаем, что нас отлаживают. В этом случае взломщику придется копать, почему в отладчике все путем, а без него все падает. В итоге для взлома требуется более высокая квалификация, следовательно, вероятность падает.
Вообще, я довольно давно присматриваюсь к подобных алгоритмам (а лучше — реализациям) скрэмблеров.
Не то чтобы очень интенсивно ищу, но время от времени у меня возникает необходимость иметь какой-то алгоритм, если не полноценного шифрования, то хотя бы, вот, скрэмблирования, который нормально работал бы как минимум на Java, GWT, PHP и Javascript.
А то, как обычно, — то мега библиотеки подключаем (Java),
то они не работают в GWT (клиентская часть),
то «simple» Javascript что-то по-своему делает,
то в PHP md5 у данных изменяется (версия PHP что-ли?!)…
Вот если бы такое что-то найти. Забрал бы себе :-)
Не то чтобы очень интенсивно ищу, но время от времени у меня возникает необходимость иметь какой-то алгоритм, если не полноценного шифрования, то хотя бы, вот, скрэмблирования, который нормально работал бы как минимум на Java, GWT, PHP и Javascript.
А то, как обычно, — то мега библиотеки подключаем (Java),
то они не работают в GWT (клиентская часть),
то «simple» Javascript что-то по-своему делает,
то в PHP md5 у данных изменяется (версия PHP что-ли?!)…
Вот если бы такое что-то найти. Забрал бы себе :-)
Ну, собственно, я лично именно для таких нужд чаще всего и использую эти свои алгоритмы. Именно так — бывает нужно связывать delphi/FPC, Java, JavaScript, Perl. В случае Delphi/FPC у меня имплементации на ассемблерах x86 и x64, а в оригинале (20 лет назад в дипломе девочки) это был Ассемблер IBM 370.
Мы с Димой Скляровым как-то обсуждали создание такого вот сверхлегкого, но относительно стойкого шифра для работы «на лету» и пришли к выводу, что в общем-то достаточно старой доброй связки ADD + XOR, особенно в 64-битном варианте. Если криптосхема реализована правильно, то обратить эту функцию, не зная ключа, уже очень и очень трудно. Для данных, уязвимых к статистическому анализу, можно добавить циклический сдвиг на переменное количество бит.
Управляемый ГПСЧ добавить можно, но вот насколько оно добавит криптостойкости — вопрос сложный. Самое уязвимое здесь место — передача сеансового ключа шифрования: если злоумышленник сможет его перехватить, то все остальное уже неважно.
Управляемый ГПСЧ добавить можно, но вот насколько оно добавит криптостойкости — вопрос сложный. Самое уязвимое здесь место — передача сеансового ключа шифрования: если злоумышленник сможет его перехватить, то все остальное уже неважно.
>Самое уязвимое здесь место — передача сеансового ключа шифрования: если злоумышленник сможет его перехватить, то все остальное уже неважно.
Что мешает использовать шифрование с открытым ключем для передачи сеансового ключа для скремблирования?
Что мешает использовать шифрование с открытым ключем для передачи сеансового ключа для скремблирования?
Ну так в первой идеи именно это и сказано, только обобщено и формализовано, а также устранены некоторые типичные недостатки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простые алгоритмы скремблирования данных