С++
Первое свидание заканчивается бурной ночью. Тебе кажется, что ты ее знаешь, хвастаешь друзьям, что она твоя. Но со временем ощущаешь, что это ты ее, и чтобы быть дальше вместе придется очень тщательно выбирать слова и следить за поступками. Через несколько лет чувствуешь, что вот-вот сможешь ее понять.
Haskell
С разбегу не получится, придется целоваться. Так вечер за вечером чувства переходят в любовь.
Java
Любит спать с студентами. Но только опытный мужчина способен получить удовольствие.
Только вот коротких ссылок не более чем 920 миллиардов будет в вашем случае, а исходных текстов (в сравнении) — почти бесконечность. Так что увы, не будет чуда :)
Видимо, необходимо быть американским ученым, чтобы прочувствовать всю гениальность подхода.
1. 20 цифр запоминаются хуже, чем 11 символов [a-z A-Z 0-9] или 8 симвлов [a-z A-Z 0-9 спецсимволы], а вводится (или, тем более, выбирается на карте) дольше.
2. Как уже было сказано, очень вряд ли будут выбраны точки в океане, или места без явных ориентиров, а это существенно сокращает диапазон возможных паролей. Лень исследовать насколько же существенно, но речь здесь идет о порядках.
3. Выбрать точное место даже на зуммированной карте — довольно сложно. Ведь «10-значная точность по долготе и широте» по сути определяет место точнее (до миллиметров), чем его изображение на мониторе в максимальном приближении (я говорю про гугл мапс). Таким образом, и здесь потери значащих цифр на несколько порядков.
тогда ладно. сам пытался рассказывать интуитивную оценку сложности алгоритмов — без пределов это очень поверхностно осознается; казалось бы в простейших случаях ребята все понимают, но в более сложных рассуждая «по аналогии» совершают ошибки. у классов с базовым представлением о мат. анализе проблем не возникало.
Генерация таблиц равна по времени полному перебору.
Это ерунда.
Таблица строится по некоторому диапазону строк X (например = {a..z}^8). И если прямой перебор проверяет каждую строку из X и имеет 100% шанс подобрать пароль для любого хеша, полученного из строки из X (что очевидно), то для радужной таблицы вероятность успешного подбора по нелинейному закону зависит от размера таблицы. И для получения где-то 75% успеха придется применить функцию хеширования по крайней мере в 2 раза больше раз, чем для полного прямого перебора. Для 99.9% покрытия объем вычислений на порядки привышает сложность прямого перебора для аналогичного промежутка. чуть подробнее.
но в наше время не это проблема
Вы считаете, что соль это отдельный параметр алгоритма, а не часть пароля, ладно, исходим из этого… тогда тезис представляет собой абсурд. Пусть мы умеем строить таблицу для конкретной соли, позволяющую восстановить любой пароль с 100% вероятностью (!) и такая таблица будет занимать всего 1 мегабайт (!)… но, вообще говоря входных параметров — различных солей число бесконечное. У кого-то существует бесконечное дисковое хранилище? Мне надо, но у меня нет.
Так вот, к чему это я. Соль — часть пароля.
хеш = MD5( пароль + соль ),
и для построения таблиц возможные соли включаются в диапазон паролей, затем, при подборе пароля по таблице проводится его декомпозиция на часть-соль и часть-пароль-пользователя. Но из-за коллизий (а мы собственно на них и надеемся) часть-соль может не соответствовать (и не будет!) нашей фиксированной соли, для которой мы пытаемся восстановить юзер-пароль по хешу.
А мораль такая, введение соли действительно делает применение таблиц полностью бессмысленным.
Вы про коллизии? только и займет это O(2^64), O(2^80)… (подставить нужное) времени. а короткие пароли ломаются посимвольно за O(x^N), где N — длина пароля.
0. Где хоть какие-нибудь гарантии, что вместе с усложнением алгоритма хеширования, Вы не увеличите теоретическую вероятность коллизии в пропорциональное (а то и худшее) число раз?
Ну и очевидные ошибки:
1. в RAR успех расшифровки определяется сравнением полученных CRC расшифрованного блока, а он не маленький. Отсюда и скорость такая низкая, а не из-за раундовых солей.
2. Радужные таблицы как раз-таки не эффективны после введения соли. Ключевой момент, почему они еще хоть как-то могут быть применимы — небольшая длина соли. Если сделать соль пропорциональной разрядности хеш-значения, то радужные таблицы полностью теряют смысл; их генерация для каждого конкретного случая занимает существенно большее время, чем прямой перебор (да еще и не будет обладать 100% шансами на успех).
Если же мы надемся на произвольную коллизию, то при фиксированной соли равной по разрядности хеш-значению мы с большущей (назовем ее «100%», лень считать) вероятностью получим коллизию, не содержащую эту соль в качестве части пароля, и такой пароль не примет система:
f(pass. ababababab) = hash = f(test. cdcdcdcdcd)
3. Пропорционально вы уменьшите количество одновременно обрабатываемых авторизаций на предполагаемом сервере, может быть в 10 раз — это не существенно, но в 100000 — серьезная проблема. Для локальных решений это имеет смысл, но для сетевых — абсурд.
Первое свидание заканчивается бурной ночью. Тебе кажется, что ты ее знаешь, хвастаешь друзьям, что она твоя. Но со временем ощущаешь, что это ты ее, и чтобы быть дальше вместе придется очень тщательно выбирать слова и следить за поступками. Через несколько лет чувствуешь, что вот-вот сможешь ее понять.
Haskell
С разбегу не получится, придется целоваться. Так вечер за вечером чувства переходят в любовь.
Java
Любит спать с студентами. Но только опытный мужчина способен получить удовольствие.
И libxml я тоже не обидел, но он хоть и быстрее в пару раз, но мороки с ним больше.
Онотоленикто не будет подсказывать через Интернет?1. 20 цифр запоминаются хуже, чем 11 символов [a-z A-Z 0-9] или 8 симвлов [a-z A-Z 0-9 спецсимволы], а вводится (или, тем более, выбирается на карте) дольше.
2. Как уже было сказано, очень вряд ли будут выбраны точки в океане, или места без явных ориентиров, а это существенно сокращает диапазон возможных паролей. Лень исследовать насколько же существенно, но речь здесь идет о порядках.
3. Выбрать точное место даже на зуммированной карте — довольно сложно. Ведь «10-значная точность по долготе и широте» по сути определяет место точнее (до миллиметров), чем его изображение на мониторе в максимальном приближении (я говорю про гугл мапс). Таким образом, и здесь потери значащих цифр на несколько порядков.
и примерно из этой же области, почему md5 сильно хуже sha?
У Вас, кстати, видимо очень быстрый винчестер, у меня за секунду даже 100 мегабайт не считается.
Это ерунда.
Таблица строится по некоторому диапазону строк X (например = {a..z}^8). И если прямой перебор проверяет каждую строку из X и имеет 100% шанс подобрать пароль для любого хеша, полученного из строки из X (что очевидно), то для радужной таблицы вероятность успешного подбора по нелинейному закону зависит от размера таблицы. И для получения где-то 75% успеха придется применить функцию хеширования по крайней мере в 2 раза больше раз, чем для полного прямого перебора. Для 99.9% покрытия объем вычислений на порядки привышает сложность прямого перебора для аналогичного промежутка. чуть подробнее.
Вы считаете, что соль это отдельный параметр алгоритма, а не часть пароля, ладно, исходим из этого… тогда тезис представляет собой абсурд. Пусть мы умеем строить таблицу для конкретной соли, позволяющую восстановить любой пароль с 100% вероятностью (!) и такая таблица будет занимать всего 1 мегабайт (!)… но, вообще говоря входных параметров — различных солей число бесконечное. У кого-то существует бесконечное дисковое хранилище? Мне надо, но у меня нет.
Так вот, к чему это я. Соль — часть пароля.
хеш = MD5( пароль + соль ),
и для построения таблиц возможные соли включаются в диапазон паролей, затем, при подборе пароля по таблице проводится его декомпозиция на часть-соль и часть-пароль-пользователя. Но из-за коллизий (а мы собственно на них и надеемся) часть-соль может не соответствовать (и не будет!) нашей фиксированной соли, для которой мы пытаемся восстановить юзер-пароль по хешу.
А мораль такая, введение соли действительно делает применение таблиц полностью бессмысленным.
то есть, в нашем-то как раз случае, эта проблема существенна.
0. Где хоть какие-нибудь гарантии, что вместе с усложнением алгоритма хеширования, Вы не увеличите теоретическую вероятность коллизии в пропорциональное (а то и худшее) число раз?
Ну и очевидные ошибки:
1. в RAR успех расшифровки определяется сравнением полученных CRC расшифрованного блока, а он не маленький. Отсюда и скорость такая низкая, а не из-за раундовых солей.
2. Радужные таблицы как раз-таки не эффективны после введения соли. Ключевой момент, почему они еще хоть как-то могут быть применимы — небольшая длина соли. Если сделать соль пропорциональной разрядности хеш-значения, то радужные таблицы полностью теряют смысл; их генерация для каждого конкретного случая занимает существенно большее время, чем прямой перебор (да еще и не будет обладать 100% шансами на успех).
Если же мы надемся на произвольную коллизию, то при фиксированной соли равной по разрядности хеш-значению мы с большущей (назовем ее «100%», лень считать) вероятностью получим коллизию, не содержащую эту соль в качестве части пароля, и такой пароль не примет система:
f(pass. ababababab) = hash = f(test. cdcdcdcdcd)
3. Пропорционально вы уменьшите количество одновременно обрабатываемых авторизаций на предполагаемом сервере, может быть в 10 раз — это не существенно, но в 100000 — серьезная проблема. Для локальных решений это имеет смысл, но для сетевых — абсурд.