#encryption #hash #cryptography #rainbowtable
#шифрование #хэш #криптография #rainbowtable
Вопрос:
Я выполняю rainbow attack для домашней работы, и у меня возникают некоторые проблемы при взломе паролей разной длины. Это означает, что я могу взломать каждый пароль фиксированной длины 8, например, за -2 минуты. Однако я не знаю, как обрабатывать пароли длиной от 5 до 8, не теряя много времени.
Предположим, что невозможно узнать длину пароля, только имея хэш, я уже пытался взломать хэш, пробуя каждую длину по очереди. Это означает, что я трачу 2 x 4 минуты, чтобы взломать только 1 пароль.
Должен ли я сократить все возможные пароли до максимальной длины пароля, а затем проверять только первые символы или это плохая идея?
Я использую таблицу rainbow с нижним буквенно-цифровым регистром, алгоритм sha256 и 50 000 различных функций R. Я хотел бы найти способ ускорить эту операцию. Спасибо всем, кто может помочь.
Комментарии:
1. Прежде всего, SHA-256 имеет дополнение , чтобы ввод стал кратным 512. Вывод криптографической хэш-функции является случайным, поэтому, если вы ограничите вывод, скажем, 10-битным, любой вывод будет происходить почти одинаково. Итак, только вам нужна хорошая функция сокращения для себя. Я не рекомендую вам ограничивать от 5 до 8, выбирайте <9. Но если вы хотите ограничить, если длина строки меньше 5, используйте функцию для сопоставления 1-4 с 5-8 после функции сокращения.
2. Спасибо за ваш ответ, но я не понял, как проверить длину пароля, потому что я получаю только хэш пароля для взлома.
3. После сокращения у вас будет новый ввод для следующего вычисления хэша, там проверьте длину и процесс.
4. Я предполагаю, что моя функция R плоха, потому что я должен указать ей длину для создания сокращения. Для примера я привожу хэшированный пароль: ecd71870d1963316a97e3ac3408c9835ad8cf0f3c1bc703527c30265534f75ae и длину сокращения параметров. Как функция R может сама определять длину, чтобы я мог знать, что этот пароль имеет длину 7?
5. Почему бы просто не обрезать после функции сокращения?
Ответ №1:
Я подозреваю, что вы на неправильном пути повышения производительности. Как вы, кажется, подозреваете, более короткие пароли никак не связаны с более длинными паролями. Нет никакой связи между всеми паролями, которые начинаются с определенной буквы (при условии, что хэш-функция является криптографической).
Важным моментом является то, что пространство в 7 символов в 36 раз меньше, чем пространство в 8 символов (строчные буквенно-цифровые буквы), а пространство в 6 символов в 36 раз меньше. Таким образом, проверка всего 6-символьного пространства стоит около 0,1% от 8-символьного пространства, а меньшие пробелы практически бесплатны.
Таким образом, ваша работа по повышению производительности должна быть сосредоточена на стоимости каждого хэша. Вы не получите большой пользы, пытаясь сократить короткие длины паролей, потому что они представляют собой такую крошечную часть пространства поиска.