Здравствуйте, 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 байт
Здравствуйте, 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 различает, какой из файлов выплевывать, я не в курсе.
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) А. Эйнштейн
