Это очень плохо. Если кто-то знает 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, считая ее идеальной хеш-функцией, что очевидно неправильно.
Впрочем, как уже писали выше, проще взять какой-нибудь
готовый шифр — будет и существенно быстрее, и надёжнее
(репутацию MD5 в последние годы существенно подмочили, хотя
там речь про поиск коллизий и не факт, что в данном случае
это как-то скажется на криптостойкости).
Здравствуйте, <Аноним>, Вы писали:
А>Но в данный момент нужен относительно простой алгоритм, легко реализуемый на практике, малый по объему кода.
Нет ничего проще чем взять готовую реализацию.
Но если очень хочешь написать сам то 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) А. Эйнштейн
Здравствуйте, 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;
}
}
}
Здравствуйте, a18, Вы писали:
a18>"On 18 March 2006, Klima published an algorithm[5] that can find a collision a18>within one minute on a single notebook computer, using a method he calls tunneling.". a18>О как!
Это (пока что?) не те коллизии. Зная строку s1, все еще трудно придумать строку s2 такую, что md5(s1) == md5(s2). Но вот подобрать пару строк с совпадающей md5 можно действительно довольно быстро.
Ребята, которые это изобрели, в качестве proof of concept написали програмучину, которая берет любые 2 файла (или N файлов, не помню), и делает из них 2 (или N) self-extractor'я. При запуске каждо self-extractor'а выпадает соответствующий файл. При этом self-extractor'ы имеют одинаковую md5.
Но это, на самом деле, обман зрения. Каждый self-extractor содержит оба файла целиком, и еще небольшую дописочку. Эти дописочки разные, но получающаяся md5 — одинаковая. Как уж self-extractor различает, какой из файлов выплевывать, я не в курсе.
А>В принципе, я понимаю, что если дешифровать первый блок, то можно будет дешифровать и все сообщение. А>Может есть варианты как улучшить влгоритм без излишнего усложнения.
Хочу спросить у людей, хорошо разбирающихся в методах шифрования...
На сколько криптостоек будет следующий ПРОСТЕЙШИЙ алгоритм, приведенный ниже.
Я понимаю, что он очень прост... Однако он будет использоваться для хранения зашифрованного 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 файлов на компьютере пользователя равнялась возрасту вселенной.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, <Аноним>, Вы писали:
WH>>А зачем ты вобще изобретаешь велосипед? WH>>Возьми например Blowfish WH>>Реализаций полно. Например crypto++
А>О существовании таких монстров как Blowfish, AES, ГОСТ и т.д. и т.п. мне очень хорошо известно!
А>Но в данный момент нужен относительно простой алгоритм, легко реализуемый на практике, малый по объему кода. А>И СОВСЕМ НЕ ОБЯЗАТЕЛЬНО, чтобы криптостойкость зашифрованых СOOKIE файлов на компьютере пользователя равнялась возрасту вселенной.
посмотри в сторону RC4. он примитивен технически (строк в 50-100 можно уложиться, а то и меньше), быстр и относительно стоек. Правда он поточный, но в случае который ты предлагаешь (xor поблочно) не вижу никакой разницы.
Упс, пожалуй, всё-таки лучше, как уже предлагали выше, режим CFB, чтобы
изменение одного бита в plaintext приводило к изменению всего
последующего зашифрованного текста.
Кстати, можно ещё каждый раз генерировать случайный IV и приписывать его
значение в начале зашифрованного сообщения — тогда даже при одинаковых
входных данных каждый раз будут получаться совершенно разные зашифрованные
тексты — мелочь, а приятно!
Здравствуйте, 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 попыток.
А насколько крут алгоритм ТEA в этом отношении?
Re[6]: XOR шифрование с MD5 дайджестами
От:
Аноним
Дата:
08.11.07 13:07
Оценка:
Здравствуйте, Pzz, Вы писали:
Pzz>Это тоже очень плохо. Для одного и того же ключа RC4 выдает всегда одну и ту же последовательность. Поэтому если в сообщениях понятно хоть что-то, ее можно восстановить из последовательности сообщений. Скажем, если внутри там английские слова (или, еще лучше, XML), то угадав первые 3 буквы слова, легко можно угадать и 4-ю. А разглядывая уже раскрытые буквы в соседних сообщениях, можно угадать и остальные.
Нет ну напрямую, я функцию, которую предложил WolfHound я использовать и не собираюсь... Можно оступить так:
Этот код:
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];
};
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 (128 бит) нахождение коллизии методом "дня рождения" требует
порядка 2^64 операций (условно 600 лет), а на практике в Википедии пишут следующее:
"On 18 March 2006, Klima published an algorithm[5] that can find a collision within one minute on a single notebook computer, using a method he calls tunneling.".
О как!
И, собственно, в обсуждаемой статье суть сформулирована довольно точно: критерии проектирования для хешей и для блочных шифров отличаются, и лучше лишний раз не рисковать.
Но это всё, естественно, касается серьезных приложений, а для простых случаев того, что понаписали в ветке, ИМХО хватит с запасом!
Про TEA — не знаю, попробуйте для начала в Википедии посмотреть — там наверняка всё аккуратно изложено — кто, когда и как.
Re[5]: XOR шифрование с MD5 дайджестами
От:
Аноним
Дата:
08.11.07 14:06
Оценка:
Здравствуйте, a18, Вы писали:
a18>В таких случаях стоит обращать внимание даже не на сами цифры, а на тенденцию. a18>К примеру, в теории для MD5 (128 бит) нахождение коллизии методом "дня рождения" требует a18>порядка 2^64 операций (условно 600 лет), а на практике в Википедии пишут следующее: a18>"On 18 March 2006, Klima published an algorithm[5] that can find a collision a18>within one minute on a single notebook computer, using a method he calls tunneling.". a18>О как!
На счет Klima читал и ранее... Но легкое обнаружение коллизий — не означает легкую обратимость функции MD5.
А на счет тенденции — согласен!!! Математика развивается — и неизвестно, что будет в будущем! Может завтра мы все умрем .
a18>И, собственно, в обсуждаемой статье суть сформулирована довольно точно: критерии проектирования для хешей и для блочных шифров отличаются, и лучше лишний раз не рисковать. Но это всё, естественно, касается серьезных приложений, а для простых случаев того, что понаписали в ветке, ИМХО хватит с запасом!
OK. Я тоже все больше склоняюсь теперь к использованию XXTEA, чем писать нечто свое — непроверенное.
Здравствуйте, <Аноним>, Вы писали:
А>Есть один вопрос... Криптостойкость информации в TEA как-то зависит от длины ключа? А>Достаточно ли хорошо будет, если в качестве ключа брать допустим MD5 дайджест от пароля с каким нибудь сольдом?
Ну в "классическом" варианте, который приведен в оригинальной статье и в моем предыдущем сообщении длина ключа фиксирована и составляет 128 бит.
MD5 от пароля с солью в принципе должен подойти. По крайней мере, каких либо очевидных уязвимостей я не вижу, если придерживаться грамотной политики распределения паролей. Кроме конечно того, что при большом желании на 128-битный ключ можно организовать birthday attack.
Здравствуйте, Аноним, Вы писали:
А>TEXT = BLOCK1 + BLOCK2 + BLOCK3 + ... + BLOCKN А>BLOCK1 = XOR(BLOCK1, RC4(KEY = RC4(KEY), BLOCK0 )) А>BLOCK2 = XOR(BLOCK2, RC4(KEY = RC4(KEY), BLOCK1 )) А>BLOCK3 = XOR(BLOCK3, RC4(KEY = RC4(KEY), BLOCK2 )) А>BLOCKN = XOR(BLOCKN, RC4(KEY = RC4(KEY), BLOCKN-1)) А>BLOCK1 + BLOCK2 + BLOCK3 + ... + BLOCKN = TEXT
А>В отличии от MD5 тут можно выбирать длину блока. Однако на сколько хорош этот ГСЧ от RC4?
RC4 довольно медленно пережевывает ключ. Делать это на каждый блок не очень разумно.
Насчет качества ГСЧ, имеет смысл почитать по интернету. Говорят, у него не очень хорошие первые сколько-то килобит, и ключ течет потихоньку (т.е., набрав много выдачи этого ГСЧ, дальше можно уже продолжить не зная ключа). Поэтому рекомендуется подмешивать в ключ что-нибудь случайное, и делать регулярный rekeying. Но все же не на каждые 16 байт
Re[8]: XOR шифрование с MD5 дайджестами
От:
Аноним
Дата:
09.11.07 07:00
Оценка:
Здравствуйте, Pzz, Вы писали:
Pzz>RC4 довольно медленно пережевывает ключ. Делать это на каждый блок не очень разумно.
Pzz>Насчет качества ГСЧ, имеет смысл почитать по интернету. Говорят, у него не очень хорошие первые сколько-то килобит, и ключ течет потихоньку (т.е., набрав много выдачи этого ГСЧ, дальше можно уже продолжить не зная ключа). Поэтому рекомендуется подмешивать в ключ что-нибудь случайное, и делать регулярный rekeying. Но все же не на каждые 16 байт
Спасибо, почитаю подробнее на счет этого в интернете...
Здравствуйте, Sergey Chadov, Вы писали:
SC>Здравствуйте, <Аноним>, Вы писали:
А>>Есть один вопрос... Криптостойкость информации в TEA как-то зависит от длины ключа? А>>Достаточно ли хорошо будет, если в качестве ключа брать допустим MD5 дайджест от пароля с каким нибудь сольдом? SC>Ну в "классическом" варианте, который приведен в оригинальной статье и в моем предыдущем сообщении длина ключа фиксирована и составляет 128 бит. SC>MD5 от пароля с солью в принципе должен подойти. По крайней мере, каких либо очевидных уязвимостей я не вижу, если придерживаться грамотной политики распределения паролей. Кроме конечно того, что при большом желании на 128-битный ключ можно организовать birthday attack.
Здравствуйте, Pzz, Вы писали:
А>>Необходимо 'размазывать' ключ!!! Догадайтесь почему!
Pzz>Нет, я не очень понимаю, объясните пожалуйста. Pzz>А обойтить одним, а не 2-мя, MD5 на блок можно?
Извините, глючу! При детальном рассмотрении, мои размышления оказались надуманными...
Разницы в действительности нет! Но первый вариант с одним MD5 на блок конечно предпочтителен.
Да, если бы это были ТЕ коллизии, народ бы сейчас лихорадочно переписывал многие системы
Pzz>Ребята, которые это изобрели, в качестве proof of concept написали програмучину, которая берет любые 2 файла (или N файлов, не помню), и делает из них 2 (или N) self-extractor'я. При запуске каждо self-extractor'а выпадает соответствующий файл. При этом self-extractor'ы имеют одинаковую md5.
Здравствуйте, Pzz, Вы писали:
Pzz>Насчет качества ГСЧ, имеет смысл почитать по интернету. Говорят, у него не очень хорошие первые сколько-то килобит, и ключ течет потихоньку (т.е., набрав много выдачи этого ГСЧ, дальше можно уже продолжить не зная ключа). Поэтому рекомендуется подмешивать в ключ что-нибудь случайное, и делать регулярный rekeying. Но все же не на каждые 16 байт
А если сделать что-то типа такого
class RC4M
{
public:
RC4M(void const* key, int len)
{
unsigned char const* k = reinterpret_cast<unsigned char const*>(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;
for (int k = 0; k < 1024; ++k)
next();
}
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];
}
unsigned char encode(unsigned char c)
{
unsigned char cc = next();
j += c;
c ^= cc;
return c;
}
unsigned char decode(unsigned char c)
{
unsigned char cc = next();
c ^= cc;
j += c;
return c;
}
private:
unsigned int i;
unsigned int j;
unsigned char buf[256];
};
И начинать поток с N (скажем 256 чтобы генератор сделал полный цикл) байт мусора.
Ну и иногда вставлять сообщения с мусором которые прикладной протокол будет тупо дропать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>И начинать поток с N (скажем 256 чтобы генератор сделал полный цикл) байт мусора. WH>Ну и иногда вставлять сообщения с мусором которые прикладной протокол будет тупо дропать.
Можно конечно, но такая вешь не пройдет скажем с такими языками как PHP (так как в нем нет понятия мусора).
Здравствуйте, Mira, Вы писали:
M>Можно конечно, но такая вешь не пройдет скажем с такими языками как PHP (так как в нем нет понятия мусора).
/dev/urandom
Ы?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
