4 ответов:
Потому что она содержит весь "спектр" возможностей.
Атака по словарю - это техника брутфорса, когда мы просто пробуем возможности. Вот так (псевдокод python)Однако радужная таблица работает иначе, потому что она предназначена для инвертирования хэшей. Высокоуровневый обзор хэша состоит в том, что он имеет несколько ячеек:mypassworddict = dict() for password in mypassworddict: trypassword(password)bin1, bin2, bin3, bin4, bin5, ..., которые соответствуют двоичным частям выходной строки-Вот как строка заканчивается на длину, которой она является. По мере того как хэш продолжается, он влияет на различные части бункеров по-разному. Таким образом, первый байт (или любое другое принимаемое поле ввода) влияет на входные данные (скажем, упрощенно) ячеек 3 и 4. Следующий вход влияет на 2 и 6. И так далее.
Радужная таблица-это вычисление всех возможностей данного Бина, то есть всех возможных инверсий этого Бина для каждого Бина... вот почему он так велик. Если первое значение ячейки0x1, то вам нужно иметь список поиска всех значенийbin2и всех значения bin3 работают в обратном направлении через хэш, который в конечном итоге дает вам значение. Почему это не называется словарной атакой? Потому что это не так. Поскольку я видел ваш предыдущий вопрос, Позвольте мне подробнее остановиться на деталях, которые вы ищете. Криптографически безопасный хэш должен быть безопасным в идеале от небольших входных размеров до целых файлов. Чтобы предварительно вычислить значения хэша для всего файла , потребуется вечность. Таким образом, Радужный стол спроектирован на небольшом хорошо понятное подмножество выходных данных, например перестановки всех символов a-z над полем, скажем, 10 символов. Вот почему здесь работает Совет по паролям для защиты от атак по словарю. Чем больше подмножеств из всего возможного набора входных данных вы вводите для хэша, тем больше радужная таблица должна содержать для поиска. Требуемые размеры данных в конечном итоге глупо велики, и время на поиск тоже. Итак, подумайте об этом:
- Если у вас есть вход, который это
[a-z]для5-8символов, это не так уж плохо радужная таблица.- если вы увеличите длину до 42 символов, это будет массивная радужная таблица. каждый вход влияет на хэш и, следовательно, на ячейки указанного хэша.
- Если вы добавляете числа к вашему требованию поиска
[a-z][0-9], вам нужно еще больше искать.- аналогично
[A-Za-z0-9]. Наконец, вставьте[\w], то есть любой печатный символ, который вы можете придумать, и снова вы смотрите на массивный символ. стол.Итак, делая пароли длинными и сложными, радужные таблицы начинают принимать диски данных размером с Синий луч. Затем, как и в предыдущем вопросе, вы начинаете добавлять в функции salting и hash производные и делаете общее решение для hash cracking hard (er).
Цель здесь состоит в том, чтобы опередить доступную вычислительную мощность.
Rainbow-это вариант атаки по словарю (точнее, предварительно вычисленная атака по словарю), но он занимает меньше места, чем полный словарь (ценой времени, необходимого для поиска ключа в таблице). Другой конец этого компромисса пространства-памяти-полный поиск (атака грубой силы = нулевое предварительное вычисление, много времени).
В радужной таблице предварительно вычисленный словарь пар ключ-шифртекст сжат в цепочки. Каждый шаг в цепочке выполняется с использованием различных функций коммрессии. И на столе много цепочек, поэтому он похож на радугу.
На этом рисунке различные функции сжатия K1, K2, K3 имеют цвета, как в радуге: Таблица, хранящаяся в файле, содержит только первый и последний столбцы,так как средние столбцы могут быть пересчитаны.
Я не знаю, откуда взялось это название, но различия таковы:
Словарь содержит несколько выбранных элементов (например, английские слова), в то время как радужная таблица содержит все возможные комбинации.
- словарь содержит только входные данные, в то время как таблица rainbow содержит как входные, так и выходные данные.
- словарь используется для проверки различных входных данных, чтобы увидеть, являются ли выходные данные допустимыми, в то время как радужная таблица используется для обратного поиска e, т. е. удельная мощность.
К сожалению, некоторые утверждения неверны. В отличие от того, что принесло опубликованные радужные таблицы не содержат всех возможностей для данного пространства ключей, а не тех, которые были созданы для использования, которые я видел. Они могут быть сгенерированы для покрытия 99.9, но из-за случайности хэш-функции нет никакой гарантии, что каждый открытый текст будет покрыт.
Каждая цепь состоит из звеньев или ступеней, и каждая ступень состоит из функции хеширования и редукции. Если ваша цепь была длиной 100 звеньев вы бы прошли это количество функций хэширования / сокращения, а затем отбросили бы все, что находится между ними, кроме начала и конца.
Чтобы найти равнину для данного хэша, вы просто выполняете уменьшение / хэш X длины вашей цепочки. Таким образом, вы выполняете шаг один раз и проверяете конечную точку, если это промах, который вы бы повторили... Пока вы не пройдете через всю длину вашей цепи. Если есть совпадение, вы можете восстановить цепочку с начальной точки, и вы сможете найти равнина. Если после регенерации это не правильно, то это ложная тревога. Это происходит из-за коллизий, вызванных функцией уменьшения хеширования. Поскольку таблица содержит много цепочек, вы можете сделать большой поиск по всем конечным точкам цепочки на каждом шаге, это, по существу, где происходит магия, позволяющая скорость. Это также приведет к ложным сигналам тревоги, так как вам нужно только регенерировать цепочки, которые имеют совпадения, вы экономите много времени, пропуская ненужные цепочки.
Они этого не делают. содержат словари.... Ну не традиционные таблицы есть варианты радужных таблиц, которые включают использование словарей, хотя.
Вот и все. Существует много способов оптимизации этого процесса, включая удаление цепочек слияния / дублирования и создание идеальных таблиц, а также хранение их в различной упаковке для экономии места и времени загрузки.
Comments