Проверка валидности пароля?

Discussion in 'WASM.CRYPTO' started by Arthur, Feb 28, 2009.

  1. Arthur

    Arthur New Member

    Blog Posts:
    0
    Joined:
    Jan 27, 2007
    Messages:
    494
    Добрый день!

    Мне требуется шифровать файлы, чьи размера могут колебаться от 4 Кб до 64 Гб, шифратор собственно Blowfish.

    Вычислять CRC32/CRC64, и основываться на сходстве данного показателя? Или как то по другому можно?
    А как 7z проверяет?
     
  2. Partner

    Partner Павел

    Blog Posts:
    0
    Joined:
    Feb 28, 2008
    Messages:
    917
    Location:
    Los Angeles
    Хранить какой нибудь (MD5, SH1, etc) хэш пароля.

    Или вычислить хэш шифруемых данных, добавить в конец к данным и зашифровать все используя пароль(или его хэш) как ключ.
    При расшифровке пароль не проверять, а просто расшифровавать тем что есть.
    После посчитать хэш расшифрованых данных и сравнить с оригинальным хэшем. При совпадении считать пароль правильным, а расшифрованные данные валидными.
     
  3. Arthur

    Arthur New Member

    Blog Posts:
    0
    Joined:
    Jan 27, 2007
    Messages:
    494
    Partner
    а пароль не будет уязвимым?
     
  4. Partner

    Partner Павел

    Blog Posts:
    0
    Joined:
    Feb 28, 2008
    Messages:
    917
    Location:
    Los Angeles
    Arthur
    Что ты понимаешь под уязвимостью? Простоту подбора?
     
  5. Partner

    Partner Павел

    Blog Posts:
    0
    Joined:
    Feb 28, 2008
    Messages:
    917
    Location:
    Los Angeles
    В любом случае, пароль явно нигде не хранится. В одном случае хранится только хэш пароля, а в другом хэш данных.
     
  6. _tmp17628

    _tmp17628 New Member

    Blog Posts:
    0
    Joined:
    Feb 7, 2009
    Messages:
    144
    Partner
    64 ГБ таким образом расшифровывать?

    Имхо сигнатуру надо шифровать и хранить в зашифрованном файле, а потом расшифровывать и сравнивать с оригинальной.
     
  7. OLS

    OLS New Member

    Blog Posts:
    0
    Joined:
    Jan 8, 2005
    Messages:
    322
    Location:
    Russia
    1) сформировать из хорошего (!) rnd случайный блок, равный по длине блоку шифра
    2) зашифровать этот блок паролем
    3) приложить к файлу первый блок целиком, а второй - либо весь, либо частично (чем меньшую часть зашифрованного блока приложишь, тем больше будет вероятность ложного допуска до реальной расшифровки неверного ключа, но теоретически тем меньше информации ты сообщаешь для тех, кто захочет с помощью этих данных взломать ключ - я бы посоветовал около 16-20 бит - от случайных опечаток при вводе пароля защитит хорошо, а те, кто будут подбирать, получат 2^108 ложных ключей)

    - "пароль не будет уязвимым", т.к. одно из тщательно соблюдаемых свойств блочных шифров - это защита от атаки "known plaintext" - и Blowfish его выполняет
    т.е. для вычисления ключа по этим "припискам" злоумышленнику потребуется в среднем 2^129 таких пар

    - шифровать фиксированную сигнатуру плохо, т.к. если разные файлы будут зашифрованы одним и тем же паролем, то этот факт будет сразу заметен

    - хешировать пароль конечно можно, но 1) обязательно с длинной солью, 2) прогресс в области rainbow-таблиц и прочих атак на хеш-суммы мне не нравится, 3) придется в коде реализовывать еще и хеш-функцию, а в предлагаемом мною методе используется уже имеющийся блочный шифр


    P.S. Определенную проблему любая дополнительная проверка валидности пароля (неважно как криптографически реализованная) создает в тех случаях, когда пользователь шифросистемы выбирает относительно слабые пароли. Как известно, человеку очень сложно придумать пароль информационной емкостью выше 64 бит, "типовые" "стойкие" пароли живут в диапазоне 25-40 бит. Вот тут быстрая проверка валидности может сыграть злую шутку.

    Лучше бы конечно сделать ее весьма медленной, если есть угроза использования слабых паролей, например как в RAR-е - порядка миллиона (если я правильно помню) итеративных операций. Проверка валидности 1 пароля должна занимать где-то 100 миллисекунд. Тогда для валидного пользователя это незаметно, а вот злоумышленнику проверить хотя бы 2^30 паролей займет 4 года. В-общем, решай сам.
     
  8. Partner

    Partner Павел

    Blog Posts:
    0
    Joined:
    Feb 28, 2008
    Messages:
    917
    Location:
    Los Angeles
    Разбить на блоки подходящего размера и шифровать каждый отдельно.
     
  9. Arthur

    Arthur New Member

    Blog Posts:
    0
    Joined:
    Jan 27, 2007
    Messages:
    494
    OLS
    по первому: srand+time+rand - я так понимаю не хороший rnd?
    по третьему: первый блок - это собственно данные, второй блок - это весь или половина блока заполненного случайными значениями (т. е. блок для проверки валидности ключа)? Я правильно понял?
     
  10. OLS

    OLS New Member

    Blog Posts:
    0
    Joined:
    Jan 8, 2005
    Messages:
    322
    Location:
    Russia
    Извини мне мое незнание конкретных платформ и языков программирования, но я не понимаю твой язык ... :)

    Про то как ты хранишь собственно зашифрованные данные, я вообще ничего не говорю. Я описываю только возможную процедуру "предпроверки" валидности пароля.

    первый блок (пусть p[0-63]) - это случайные данных от rnd
    второй блок (пусть c[0-15])- это частичка от блока "c[0-63]", который равен c[0-63]=CRYPT(p[0-63], key)

    ведь для проверки достаточно снова зашифровать "p[0-63]" (а он прилагается к файлу полностью) и сравнить соответствующую часть (биты 0-15) с прилагаемым к файлу блоком c[0-15]

    P.S. Отвлеченно говоря, а тебе ради чего вообще нужна предпроверка валидности пароля ?
     
  11. Arthur

    Arthur New Member

    Blog Posts:
    0
    Joined:
    Jan 27, 2007
    Messages:
    494
    OLS
    функции из стандартной библиотеки Си.

    Ага: первый блок чистый (заполненный случайными числами), второй небольшая часть уже закриптованого первого блока. Все понял спасибо!

    Ну к примеру файлом в 1-4 гб сегодня ни кого не удивишь, и к примеру ждать расшифровки такого файла чтобы сравнить md5 или crc, слишком долгий и утомительный процесс, при условии что пароль был забыт. А так предварительно хоть программа сможет определить валидность ключа прежде чем весь файл будет расшифрован.