Всё правильно. Главная проблема большинства алгоритмов шифрования в том, что их придумали мужчины.
Соответственно мужики сами их взломать не могут, а тётки, используя альтернативную логику, щёлкают их как орешки.
Вот пусть попробуют свой алгоритм придумать — мы их ух как!
Блудов Павел wrote:
> А>http://safe.cnews.ru/news/line/index.shtml?2007/01/23/232525 > > Всё правильно. Главная проблема большинства алгоритмов шифрования в том, > что их придумали мужчины. > Соответственно мужики сами их взломать не могут, а тётки, используя > альтернативную логику, щёлкают их как орешки. > Вот пусть попробуют свой алгоритм придумать — мы их ух как!
Наверное ей это уже не под силу, ведь для составления алгоритма надо правильную логику применять.
Проблема в том, что китайцев много — то что нужно ломать миллион лет, миллиард китайцев ломают за 1/1000 года, т.е. за
~8 часов.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Т.е. если ты украл табличку хэшей sha1 паролей для входа в какую-нибудь систему, то сможешь "быстро" подобрать пароль, с
которым тебя система авторизует.
Или если у тебя какая-то система передаёт сообщение и в качестве проверки целостности использует sha1 хэш, то можно так
исказить это сообщение, что подмену не просекут — хэши будут совпадать.
Вообще говоря, это всё не так уж ужасно, но сам факт...
> А то красной селедкой пахнет.
Это что?
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
.>Т.е. если ты украл табличку хэшей sha1 паролей для входа в какую-нибудь систему, то сможешь "быстро" подобрать пароль, с .>которым тебя система авторизует. .>Или если у тебя какая-то система передаёт сообщение и в качестве проверки целостности использует sha1 хэш, то можно так .>исказить это сообщение, что подмену не просекут — хэши будут совпадать.
.>Вообще говоря, это всё не так уж ужасно, но сам факт...
Хм.. А что тогда ужасно?
Где почитать нормальные сообщения на эту тему?
Какова сложность алгоритма поиска коллизии?
Igor Trofimov wrote:
> Где почитать нормальные сообщения на эту тему? > Какова сложность алгоритма поиска коллизии?
По sha1 не знаю, надо погуглить, а вот по md5 неплохая статейка тут: http://www.codeproject.com/dotnet/HackingMd5.asp
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Блудов Павел, Вы писали:
БП>Вот пусть попробуют свой алгоритм придумать — мы их ух как!
Да легко! Они же заразы логикой вообще не пользуются. Их алгоритмы будут невозможно взломать! Правда будет один побочный эффект. С их помощью можно будет легко зашифровать информацию, но при попытке расшифровать ее будут получаться совершенно разные результаты.
А что вы хотите? Вы пробовали женщине задвать один и тот же вопрос несколько раз в разное время?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Кратко говоря — утка, прошлогодняя Пока не найдут хоть одну коллизию, считать взломанным алгоритм даже как-то странно.
Суть простая, вместо 2^80 операций по перебору для нахождения коллизии хэша достаточно и 2^63. Статья об этом была опубликована на Crypto 2006, а заявлено о факте вообще было чуть ли не в феврале того года.
Здравствуйте, Шахтер, Вы писали:
А>>А что осталось-то?.. Ш>Если ты имеешь ввиду, какие ещё hash функции есть, то например, SHA-256, SHA-384, SHA-512.
Они основаны на тех же принципах что и MD5 и SHA-1, а так как основной подход к нахождению коллизий в них уже найден, то вскрытие более сильных функций — считается делом времени.
Также в том году небезызвестный NIST провёл конкурс Hash WorkShop — предполагалось выработать новый вариант стандарта на хэш-функцию. Пока о результатах ничего не слышно.
Здравствуйте, Andir, Вы писали:
А>>>А что осталось-то?.. Ш>>Если ты имеешь ввиду, какие ещё hash функции есть, то например, SHA-256, SHA-384, SHA-512.
A>Они основаны на тех же принципах что и MD5 и SHA-1, а так как основной подход к нахождению коллизий в них уже найден, то вскрытие более сильных функций — считается делом времени.
Ну, подходы к вскрытию DES и RSA так же известны давно. Только элементарное увеличение длины ключа в несколько раз делает осуществление взлома на существующих аппаратных ресурсах практически бесполезным.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > Ну, подходы к вскрытию DES и RSA так же известны давно. Только > элементарное увеличение длины ключа в несколько раз делает осуществление > взлома на существующих аппаратных ресурсах практически бесполезным.
Для DES увеличение ключа — бесполезно. Для 3DES у нас будет перебор в
2^80 вариантов, если я не ошибаюсь, а алогитмическая сложность у него
почти как у AES.
Здравствуйте, Cyberax, Вы писали:
>> Ну, подходы к вскрытию DES и RSA так же известны давно. Только >> элементарное увеличение длины ключа в несколько раз делает осуществление >> взлома на существующих аппаратных ресурсах практически бесполезным. C>Для DES увеличение ключа — бесполезно.
Я бы больше сказал -- невозможно
Т.к. он жестко завязан на 64-х битовые ключи, из которых для шифрования используются только 56-ть бит.
Но в том-то и дело, что имея в основе довольно слабоустойчивый алгоритм, устойчивость шифрования увеличили в три раза просто трижды применяя DES над шифруемым текстом.
C> Для 3DES у нас будет перебор в 2^80 вариантов, если я не ошибаюсь, а алогитмическая сложность у него C>почти как у AES.
Насколько помню, в 3DES используется две основные схемы -- с ключами в 128 бит (где только 112 бит используются при шифровании) и с ключами в 192 бита (где только 168 бит задействованы). Причем, теоритически для ключа в 128 бит есть возможность подбора ключей но для этого требуется получение и хранение 2^56 64-х битовых значений. Для ключей же в 192 бита только полный перебор.
Что касается алгоритмической сложности и устойчивости DES по отношению к AES, то не буду ничего утверждать, т.к. подзабыл все уже основательно. Какие-то атаки на него были, и проблема подбора хорошего ключа для него была. Но, если не ошибаюсь, было это не сильно критично.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
C>> Для 3DES у нас будет перебор в 2^80 вариантов, если я не ошибаюсь, а алогитмическая сложность у него C>>почти как у AES.
E>Насколько помню, в 3DES используется две основные схемы -- с ключами в 128 бит (где только 112 бит используются при шифровании) и с ключами в 192 бита (где только 168 бит задействованы). Причем, теоритически для ключа в 128 бит есть возможность подбора ключей но для этого требуется получение и хранение 2^56 64-х битовых значений. Для ключей же в 192 бита только полный перебор.
Подробности можно найти по ссылкам, например, здесь. В частности:
Quoting from the paper "Attacking Triple Encryption" cited above:
[A]bout 2^108 steps of computation are sufficient to break three-key triple DES. If one concentrates on the number of single DES operations and assumes the other operations to be much faster, 2^90 of these are enough.
Better attacks than this are available against two-key triple DES (which should only be used for backward compatibility, if at all).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ну, подходы к вскрытию DES и RSA так же известны давно. Только элементарное увеличение длины ключа в несколько раз делает осуществление взлома на существующих аппаратных ресурсах практически бесполезным.
Не знаю ни одного подхода к взлому DES и RSA. Ключ DES — увеличить невозможно. Отсюда я делаю вывод, что ты имел ввиду перебор ключей RSA и соответственно соревнования по распределённому вычислению ключей RSA.
Здесь ситуация иная, используется вполне конкретный алгоритм, который позволяет уменьшить перебор до неприличных значений — MD4 — вручную на бумажке, MD5 за несколько секунд (по результатам прошлого года).
Алгоритм имеет слабое место: для его использования требуется найти хотя бы один достаточно длинный путь в котором сохраняется коллизия (длина пути — кол-во операций при котором возможно сохранение коллизии внутри сжимающей функции). Нахождение выполняется вручную (грубо говоря — случайно), и для MD5 — известен ровно 1 путь, которого хватило чтобы найти коллизию, а далее и стало возможно находить произвольные коллизии.
Собственно применение этого алгоритма к SHA-256 дело времени нахождения такого пути. Вполне возможно, что его найдут легко и быстро а может и долго и муторно.
Возможно будет формализована сложность нахождения такого пути, а возможно задача будет автоматизирована.
Чисто эмпирически можно оценить, учитывая, что применение этого алгоритма к SHA-1 (более сложной функции, и дело не только в длине) заняло менее года, то применение к SHA-256 (отличается только длиной, алгоритм вычисления не отличается ничем), что "взлом" займёт примерно 1-2 года.
Здравствуйте, Andir, Вы писали:
E>>Ну, подходы к вскрытию DES и RSA так же известны давно. Только элементарное увеличение длины ключа в несколько раз делает осуществление взлома на существующих аппаратных ресурсах практически бесполезным.
A>Не знаю ни одного подхода к взлому DES и RSA. Ключ DES — увеличить невозможно. Отсюда я делаю вывод, что ты имел ввиду перебор ключей RSA и соответственно соревнования по распределённому вычислению ключей RSA.
Да, brute force еще никто не отменял
Тем более, что DES, если я не ошибаюсь был взломан за 8-мь часов.
И еще в одном случае я слышал, что для ключей DES так же возможны коллизии.
<...с поскипанным согласен...>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andir, Вы писали:
A>Не знаю ни одного подхода к взлому DES и RSA.
Про DES — я конечно загнул, имел ввиду, что практического алгоритма взлома зашифрованного сообщения DES (кроме брутфорса) — мне неизвестно. Всякие дифференциальные и линейные криптоанализы, которые и развивались благодаря DES — мне конечно известны
eao197 wrote: > C>Для DES увеличение ключа — бесполезно. > Я бы больше сказал -- невозможно > Т.к. он жестко завязан на 64-х битовые ключи, из которых для шифрования > используются только 56-ть бит.
Можно, берешь три разных ключа и последовательно шифруешь ими.
Получается 3DES — стойкость будет больше, чем у обычного DES, но все
равно не очень высокая.
> Но в том-то и дело, что имея в основе довольно слабоустойчивый алгоритм, > устойчивость шифрования увеличили в три раза просто трижды применяя DES > над шифруемым текстом.
Не в "три раза", а примерно в 2^34 раз. Сложность нелинейно растет
(из-за парадокса дней рождений).
> Что касается алгоритмической сложности и устойчивости DES по отношению к > AES, то не буду ничего утверждать, т.к. подзабыл все уже основательно. > Какие-то атаки на него были, и проблема подбора хорошего ключа для него > была. Но, если не ошибаюсь, было это не сильно критично.
Пока 3DES считается достаточно стойким алгоритмом, но у него нет запаса
от будущих атак.
Здравствуйте, Cyberax, Вы писали:
>> C>Для DES увеличение ключа — бесполезно. >> Я бы больше сказал -- невозможно >> Т.к. он жестко завязан на 64-х битовые ключи, из которых для шифрования >> используются только 56-ть бит. C>Можно, берешь три разных ключа и последовательно шифруешь ими. C>Получается 3DES — стойкость будет больше, чем у обычного DES, но все C>равно не очень высокая.
Извини за догматизм, но я таки настаиваю, что в DES нельзя изменить длину ключа. В отличии от, скажем, AES, Blowfish, MARS или Twofish.
TripleDES (3DES) -- это уже другой алгоритм, хотя и построенный на основе DES. К тому же по стандарту 3DES реализуется как DES(k3,UNDES(k2,DES(k1,v))), а не последовательными шифрованиями.
Формальность здесь очень важна
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Пока не найдут хоть одну коллизию, считать взломанным алгоритм даже как-то странно.
