Скремблирование как бюджетная защита данных.
 

Здравствуйте!

Может ли кто похвастаться успешным опытом применения скремблирования для защиты передаваемых между сервером и клиентом данных?

Собственно размышления навеяны этим постом на Хабре.

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

Скремблирование приглянулось за счет его быстродействия, в приведенном выше посте используется всего 3 xor и 1 or операции для (де)кодирования данных. Что, по моему мнению, здорово - это отсутствие необходимости передавать клиенту ключ, который все - равно можно без проблем отловить, хотя в данном подходе талантливый реверс - инженер может щелкнуть всю защиту за некоторое время и без проблем шифровать поддельные данные для отправки их на сервер.

Может есть более надежные техники? Ткните пожалуйста! :)

Я в курсе, что защитить данные на 100%, да что там даже на 40%, нельзя, но все - же хочется отсеять максимум "нелегалов".

Ответ: Скремблирование как бюджетная защита данных.
 

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

Ответ: Скремблирование как бюджетная защита данных.
 

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

Ответ: Скремблирование как бюджетная защита данных.
 

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

Ответ: Скремблирование как бюджетная защита данных.
 

MoKa, ты прав насчет "лохануться", кажется прочитав статью на Хабре я решил собрать очередной велосипед. Почитал сейчас статью с Вики, узнал, что на основе открытого ключа работают RSA, PGP и Twofish порожденный RSA, следовательно если уже есть отлаженные способы шифровки, а главная ценность в них ключ, а не алгоритм, то писать свое - это только ради тренировки, но ни в коем случае не для рабочей системы. Тем более, как оказалось, скорость шифрования, даже у такого тяжеловеса как RSA, 30 кб/c, что явно превосходит потребности современной клиент - серверной системы, на мой взгляд.

Кстати, информация для потомков:
Используя RSA based шифрование, необходимо помнить, что ключ, размерностью ниже 1024 бит, в условиях современных вычислительных мощностей, более не актуален. Также настоятельно советуют как можно быстрее переползать и с 1024 битного ключа, т.к. сегодняшняя планка это взлом шифрованного сообщения с 768 битным ключом.

Чтобы вдруг не наткнуться, в поисках подходящего алгоритма, на OpenSSL, вот отличная замена www.cryptopp.com

Ответ: Скремблирование как бюджетная защита данных.
 

Собственно:
http://ru.wikipedia.org/wiki/Принцип_Керкгоффса