Хочу спросить у людей, хорошо разбирающихся в методах шифрования...
На сколько криптостоек будет следующий ПРОСТЕЙШИЙ алгоритм, приведенный ниже.
Я понимаю, что он очень прост... Однако он будет использоваться для хранения зашифрованного COOKIE на компьютере пользователя.
TEXT = текст для шифрования
KEY = ключ для шифрования
Текст разбиваем на блоки равные длине дайджеста MD5:
TEXT = BLOCK1 + BLOCK2 + BLOCK3 + ... + BLOCKN
Вычисляем MD5 дайджест ключа:
DIGEST1 = MD5(KEY)
Затем запускаем цикл шифрования в котором выполняем операцию XOR с блоками текста и вычисляем новый дайджест:
В принципе, я понимаю, что если дешифровать первый блок, то можно будет дешифровать и все сообщение.
Может есть варианты как улучшить влгоритм без излишнего усложнения.
А>В принципе, я понимаю, что если дешифровать первый блок, то можно будет дешифровать и все сообщение. А>Может есть варианты как улучшить влгоритм без излишнего усложнения.
А зачем ты вобще изобретаешь велосипед?
Возьми например Blowfish
Реализаций полно. Например crypto++
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: XOR шифрование с MD5 дайджестами
От:
Аноним
Дата:
07.11.07 14:55
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, <Аноним>, Вы писали:
WH>А зачем ты вобще изобретаешь велосипед? WH>Возьми например Blowfish WH>Реализаций полно. Например crypto++
О существовании таких монстров как Blowfish, AES, ГОСТ и т.д. и т.п. мне очень хорошо известно!
Но в данный момент нужен относительно простой алгоритм, легко реализуемый на практике, малый по объему кода.
И СОВСЕМ НЕ ОБЯЗАТЕЛЬНО, чтобы криптостойкость зашифрованых СOOKIE файлов на компьютере пользователя равнялась возрасту вселенной.
Здравствуйте, <Аноним>, Вы писали:
А>Но в данный момент нужен относительно простой алгоритм, легко реализуемый на практике, малый по объему кода.
Нет ничего проще чем взять готовую реализацию.
Но если очень хочешь написать сам то RC4:
class RC4
{
public:
RC4(void* key, int len)
{
init(key, len);
}
void init(void* key, int len)
{
unsigned char* k = reinterpret_cast<unsigned char*>(key);
i = j = 0;
for (; i < 256; ++i)
buf[i] = i;
i = j = 0;
for (; i < 256; ++i)
{
j = (j + buf[i] + k[i % len]) % 256;
std::swap(buf[i], buf[j]);
}
i = j = 0;
}
unsigned char next()
{
i = (i + 1) % 256;
j = (j + buf[i]) % 256;
std::swap(buf[i], buf[j]);
return buf[(buf[i] + buf[j]) % 256];
}
private:
unsigned int i;
unsigned int j;
unsigned char buf[256];
};
Далие тупо XOR'ишь данные с тем что выдает этот ГПСЧ.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, <Аноним>, Вы писали:
WH>>А зачем ты вобще изобретаешь велосипед? WH>>Возьми например Blowfish WH>>Реализаций полно. Например crypto++
А>О существовании таких монстров как Blowfish, AES, ГОСТ и т.д. и т.п. мне очень хорошо известно!
А>Но в данный момент нужен относительно простой алгоритм, легко реализуемый на практике, малый по объему кода. А>И СОВСЕМ НЕ ОБЯЗАТЕЛЬНО, чтобы криптостойкость зашифрованых СOOKIE файлов на компьютере пользователя равнялась возрасту вселенной.
посмотри в сторону RC4. он примитивен технически (строк в 50-100 можно уложиться, а то и меньше), быстр и относительно стоек. Правда он поточный, но в случае который ты предлагаешь (xor поблочно) не вижу никакой разницы.
Здравствуйте, Leonidze, Вы писали:
L>посмотри в сторону RC4. он примитивен технически (строк в 50-100 можно уложиться, а то и меньше), быстр и относительно стоек. Правда он поточный, но в случае который ты предлагаешь (xor поблочно) не вижу никакой разницы.
Или можно взять TEA. Он еще проще и относительно криптостоек(хотя специфические атаки на него есть).
void TEAEncrypt(const void* pin, void* pout, const void* pkey, unsigned int datasize)
{
tea_dword32 cns = 0x9E3779B9;
const tea_dword32* in = (tea_dword32*)pin;
tea_dword32* out = (tea_dword32*)pout;
const tea_dword32* key = (tea_dword32*)pkey;
for (tea_dword32 i=0;i<datasize/8;i+=2)
{
tea_dword32 t0 = in[i];
tea_dword32 t1 = in[i+1];
tea_dword32 s = 0;
for (int j=0;j<32;j++)
{
s+=cns;
t0 += ((t1<<4)+key[0])^(t1+s)^((t1>>5)+key[1]);
t1 += ((t0<<4)+key[2])^(t0+s)^((t0>>5)+key[3]);
out[i]=t0;out[i+1]=t1;
}
}
}
void TEADecrypt(const void* pin,void* pout, const void* pkey, unsigned int datasize)
{
tea_dword32 cns = 0x9E3779B9;
const tea_dword32* in = (tea_dword32*)pin;
tea_dword32* out = (tea_dword32*)pout;
const tea_dword32* key = (tea_dword32*)pkey;
for (tea_dword32 i=0;i<datasize/8;i+=2)
{
tea_dword32 t0= in[i];
tea_dword32 t1= in[i+1];
tea_dword32 s = 0xC6EF3720;
for (int j=0;j<32;j++)
{
t1-=((t0<<4)+key[2])^(t0+s)^((t0>>5)+key[3]);
t0-=((t1<<4)+key[0])^(t1+s)^((t1>>5)+key[1]);
s-=cns;
out[i]=t0;out[i+1]=t1;
}
}
}
Впрочем, как уже писали выше, проще взять какой-нибудь
готовый шифр — будет и существенно быстрее, и надёжнее
(репутацию MD5 в последние годы существенно подмочили, хотя
там речь про поиск коллизий и не факт, что в данном случае
это как-то скажется на криптостойкости).
Упс, пожалуй, всё-таки лучше, как уже предлагали выше, режим CFB, чтобы
изменение одного бита в plaintext приводило к изменению всего
последующего зашифрованного текста.
Кстати, можно ещё каждый раз генерировать случайный IV и приписывать его
значение в начале зашифрованного сообщения — тогда даже при одинаковых
входных данных каждый раз будут получаться совершенно разные зашифрованные
тексты — мелочь, а приятно!
Это очень плохо. Если кто-то знает plaintext от первого блока, то ничего не стоит расшифровать все сообщение, не зная ключа. А вероятность угадать первый блок очень велика, если там лежит более-менее стандартный header.
Гораздо лучше было бы так:
BLOCK0 = RANDOM(); // Вначале втыкаем 16 байт от генератора случайных чисел
BLOCK1 = XOR( BLOCK1, MD5( KEY, BLOCK0 ) );
BLOCK2 = XOR( BLOCK2, MD5( KEY, BLOCK1 ) );
BLOCK3 = XOR( BLOCK3, MD5( KEY, BLOCK2 ) );
...
BLOCKN = XOR( BLOCKN, MD5( KEY, BLOCKN-1)
MAC = MD5( KEY, BLOCKN ); // Используем при расщифровке для проверки
Т.е. некоторое подобые CBC. Существенным является то, что:
1) Даже одно и то же сообщение, переданное повторно, будет выглядеть по-другому из-за псевдослучайных байт в начале
2) Каждый следующий блок зависит от всех предыдущих, что скрывает повторяющиеся между сообщениями блоки
3) Раскрытие какого-то блока мало помогает раскрыть остальные
4) Есть проверка подлинности сообщения
Но в серьезной программе я бы так делать не стал — все равно велика вероятность, что где-то затесалась ошибка. Кроме того, я совершенно не учитываю свойства MD5, считая ее идеальной хеш-функцией, что очевидно неправильно.
Здравствуйте, michael_srv, Вы писали:
А>>В принципе, я понимаю, что если дешифровать первый блок, то можно будет дешифровать _>CBLOCK1 = XOR(BLOCK1, DIGEST1) _>DIGEST2 = MD5(CBLOCK1)
_>CBLOCK2 = XOR(CBLOCK2, DIGEST2) _>DIGEST3 = MD5(CBLOCK2)
_>CBLOCK1 + CBLOCK2 + CBLOCK3 + ... + CBLOCKN = TEXT
_>хотя это не особо защитит, но все-же...
При таком способе только лень может помешать расшифровать что-то кроме CBLOCK1
Ключ вообще почти не нужен
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Pzz>Но в серьезной программе я бы так делать не стал — все равно велика вероятность, что где-то затесалась ошибка.
+1!
Вот и яндекс — как раз услужливо ссылочку выдал: http://data.mf.grsu.by/Crypto/papers/2887/28870036.pdf
Цитата:
==
4 Conclusions
We have presented attacks against block ciphers that have been directly derived
from dedicated hash functions. Section 2 discusses slide attacks against SHA-1
and SHACAL-1 and section 3 describes simple attacks against MDC-MD5 and
the Kaliski-Robshaw cipher.
Compression functions are meant to be only ran in one direction. The security
properties of compression functions can be different when ran in the opposite
direction (“decryption”). Furthermore a key-scheduling mechanism suitable for
a dedicated hash function may be insufficient for a block cipher.
Based on evidence in hand, we assert that since the design criteria of compression
functions and block ciphers are radically different, adaptation of even
a secure compression function as a block cipher is often not a wise thing to do.
==
Re[4]: XOR шифрование с MD5 дайджестами
От:
Аноним
Дата:
08.11.07 10:54
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, <Аноним>, Вы писали:
А>>Но в данный момент нужен относительно простой алгоритм, легко реализуемый на практике, малый по объему кода. WH>Нет ничего проще чем взять готовую реализацию. WH>Но если очень хочешь написать сам то RC4: [код поскипан] WH>Далие тупо XOR'ишь данные с тем что выдает этот ГПСЧ.
Здравствуйте, Аноним, Вы писали:
А>>>Но в данный момент нужен относительно простой алгоритм, легко реализуемый на практике, малый по объему кода. WH>>Нет ничего проще чем взять готовую реализацию. WH>>Но если очень хочешь написать сам то RC4: [код поскипан] WH>>Далие тупо XOR'ишь данные с тем что выдает этот ГПСЧ.
А>Спасибо, кажется, такое решение может подойти...
Это тоже очень плохо. Для одного и того же ключа RC4 выдает всегда одну и ту же последовательность. Поэтому если в сообщениях понятно хоть что-то, ее можно восстановить из последовательности сообщений. Скажем, если внутри там английские слова (или, еще лучше, XML), то угадав первые 3 буквы слова, легко можно угадать и 4-ю. А разглядывая уже раскрытые буквы в соседних сообщениях, можно угадать и остальные.
Для RC4 надо обязательно подмешивать в ключ что-нибудь не повторяющееся от сообщения к сообщению. Например, просто сколько-то байт от генератора случайных чисел. И передавать их в начале зашифрованного текста в открытом виде, чтобы можно было расшифровать сообщение на другой стороне.
Кроме того, с RC4 не стоит использовать линейные контрольные суммы, типа CRC32, для проверки подлинности сообщения. Известный факт, если сообщение зашифровано RC4 и защищено CRC32, то в нем можно поменять байты даже не расшифровывая сообщения, и пересчитать CRC так, что у получателя все сойдется.
В общем, мой совет — взять готовый шифр (cihper) и использовать его в стандартном режиже (mode) — ребята, которые придумывают эти режимы, они не зря свой хлеб едят.
Re[4]: XOR шифрование с MD5 дайджестами
От:
Аноним
Дата:
08.11.07 11:16
Оценка:
Здравствуйте, Leonidze, Вы писали:
L>посмотри в сторону RC4. он примитивен технически (строк в 50-100 можно уложиться, а то и меньше), быстр и относительно стоек. Правда он поточный, но в случае который ты предлагаешь (xor поблочно) не вижу никакой разницы.
Спасибо, посмотрю... Поточный алгоритм тоже подойдет...
Re[5]: XOR шифрование с MD5 дайджестами
От:
Аноним
Дата:
08.11.07 11:32
Оценка:
Здравствуйте, Sergey Chadov, Вы писали:
SC>Или можно взять TEA. Он еще проще и относительно криптостоек (хотя специфические атаки на него есть).
Спасибо!
Буквально еще вчера уже нашел этот алгоритм и две его коррекции XTEA и XXTEA.
Думаю, это вообще идеальный вариант! Маленький и быстрый код основаный на функциях Фейстеля.
На этих же функциях постороен DES и 3DES.
XXTEA действительно достаточно криптостоек (и вносит две коррекции в TEA исключая известнык на этот момент специфические атаки на него).
Думаю буду использовать его.
Есть один вопрос... Криптостойкость информации в TEA как-то зависит от длины ключа?
Достаточно ли хорошо будет, если в качестве ключа брать допустим MD5 дайджест от пароля с каким нибудь сольдом?
Re[3]: XOR шифрование с MD5 дайджестами
От:
Аноним
Дата:
08.11.07 11:42
Оценка:
Здравствуйте, a18, Вы писали:
a18>>http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation a18>>ИМХО вариант со счётчиком довольно интересный.
a18>Упс, пожалуй, всё-таки лучше, как уже предлагали выше, режим CFB, чтобы a18>изменение одного бита в plaintext приводило к изменению всего a18>последующего зашифрованного текста.
Вариант, который предложил Егор так и будет работать:
...
a18>Кстати, можно ещё каждый раз генерировать случайный IV и приписывать его a18>значение в начале зашифрованного сообщения — тогда даже при одинаковых a18>входных данных каждый раз будут получаться совершенно разные зашифрованные a18>тексты — мелочь, а приятно!
Такие примочки мне известны... Но это несущественно, в конкретной ситуации!
Re[3]: XOR шифрование с MD5 дайджестами
От:
Аноним
Дата:
08.11.07 11:53
Оценка:
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, michael_srv, Вы писали:
А>>>В принципе, я понимаю, что если дешифровать первый блок, то можно будет дешифровать _>CBLOCK1 = XOR(BLOCK1, DIGEST1) _>>DIGEST2 = MD5(CBLOCK1)
_>>CBLOCK2 = XOR(CBLOCK2, DIGEST2) _>>DIGEST3 = MD5(CBLOCK2)
_>>CBLOCK1 + CBLOCK2 + CBLOCK3 + ... + CBLOCKN = TEXT
_>>хотя это не особо защитит, но все-же... E>При таком способе только лень может помешать расшифровать что-то кроме CBLOCK1 E>Ключ вообще почти не нужен
Спасибо! Но в этом алгоритме существует уязвимость для определенных сообщений с повтрояющимися блоками...
Я думаю, вы сами догадаетесь для каких... Вот заплатка:
Необходимо 'размазывать' ключ!!! Догадайтесь почему!
Re[3]: XOR шифрование с MD5 дайджестами
От:
Аноним
Дата:
08.11.07 12:47
Оценка:
Здравствуйте, a18, Вы писали:
a18>Based on evidence in hand, we assert that since the design criteria of compression a18>functions and block ciphers are radically different, adaptation of even a18>a secure compression function as a block cipher is often not a wise thing to do.
В этой же статье написано, что шифр MDC основанный на MD5 функции можно раскрыть за 2^48 попыток, используя таблицу расписаний MD5 ключей.
В случае WEB-приложений получается, что если 100000 компьютеров делающих 1 запрос в 1 секунду взломают один пароль за 8 лет.
Мне кажется такая криптостойкость вполне достаточна для простых сайтов с авторизацией (НЕКОМЕРЧЕСКИХ, на которорых не храняться ни деньги пользователей, ни какая либо важная информация).
Итак понятно, что практически все MD5 шифры можно снять за максимум 2^48 попыток.