Шифрование файлов налету

Тема в разделе "WASM.CRYPTO", создана пользователем gloomyraven, 29 мар 2011.

  1. OLS

    OLS New Member

    Публикаций:
    0
    Регистрация:
    8 янв 2005
    Сообщения:
    322
    Адрес:
    Russia
    Хотите честно лично мое мнение почему "монолог" - потому что я не понимаю половины Ваших идей.
    Вы черезчур кратко их описываете.

    Вот, например, последний пост.

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

    Что означают шаги "сохраняем указатель в файле" и "восстанавливаем указатель в файле" - ни в первой ни во второй схеме эти шаги не нужны или по крайней мере мне не понятны.
     
  2. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    да, данные будут в тех же местах, шифроваться данные будут блочным шифром "посекторно".

    хеш можно хранить между "секторами"
    тогда указатель на н-ый сектор вроде будет так: pos_in_file / (SECTOR_SIZE + HASH_SIZE +1)

    как я понял, то дефрагментация и т.п. будут не нужны, т.к. для каждого файла отдельный контейнер (для простоты).

    т.к. мы перехватываем функции чтения/записи в чужой программе, то она не должна терять указатель (FilePos) в файле, который наш перехватчик обрабатывает. По-этому его надо сохранить вначале (мы ведь будем читать "сектора" из этого файла и указатель собьется).
     
  3. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    т.е. нарисовить можно примерно так:

    оригинальный файл (как его видит программа)
    offset data
    000 AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA
    ... AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA
    496 AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA
    512 AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA
    ...

    контейнер
    offset data
    sect_1
    000 ABABABABABABABAB ABABABABABABABAB
    ... ABABABABABABABAB ABABABABABABABAB
    496 ABABABABABABABAB ABABABABABABABAB

    HASH 16 byte

    sect_2
    528 ABABABABABABABAB ABABABABABABABAB
    ...
     
  4. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    гемор имеется в виду, ставить PAGE_NOACCESS и отлавливать обращение к промаппленному файлу? или так тоже не выйдет?
     
  5. OLS

    OLS New Member

    Публикаций:
    0
    Регистрация:
    8 янв 2005
    Сообщения:
    322
    Адрес:
    Russia
    Что мешает Вам для каждого обрабатываемого файла "рядом" или в отдельном каталоге создавать второй, хранящий только контрольные разряды ?
    С именем, отличающимся добавлением расширения ".hash". А если в NTFS, то можно организовать хранение и в альтернативных потоках основного файла.
     
  6. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    хм... хорошая идея, почему-то я об этом не подумал... выглядит не так изящно как с контейнером, зато скорость будет на порядок выше. Хотя придется обновлять хеш, даже если программа записала 1 байт, а если файл 100Мб?
    Возможно ли пересчитывать не весь хеш, а хотя бы блоки, которые изменились?
     
  7. OLS

    OLS New Member

    Публикаций:
    0
    Регистрация:
    8 янв 2005
    Сообщения:
    322
    Адрес:
    Russia
    Именно так я и подразумевал.

    Хешируется каждый блок исходного текста размером блочного шифра по отдельности.
    Вам кстати лучше всего подойдет режим не CBC или CFB, а именно шифрующий каждый блок
    отдельно, но в зависимости от его порядкового номера в файле.

    Разрядность хеша можно выбрать ровно в длину блока блочного шифра (хеш-файл будет длины, равной исходному файлу)
    или еще меньше - по факту Вам даже 32 бит будет хватать. Единственно что это должен быть не CRC, а что-то более стойкое - хотя бы 128-битное, и от него берется только первые 32 бита например.
     
  8. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    Как я понял это и есть XTS - от чего уходим, к тому и пришли )))

    Я то подразумевал, что шифр будет поточный, RC4
     
  9. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    Если честно, то не совсем понял мысль, размер блока 8 бит?
    Чтение, запись в приложении происходит блоками 1..n, где n - размер файла.
     
  10. OLS

    OLS New Member

    Публикаций:
    0
    Регистрация:
    8 янв 2005
    Сообщения:
    322
    Адрес:
    Russia
    Давайте тогда снова.

    Какой режим доступа к файлу у приложения ?
    random-access или последовательный (только дозапись) ?

    Зачем Вам именно поточный шифр ? Каковы его преимущества / каковы Ваши цели его использования ?
     
  11. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    он самый...
     
  12. OLS

    OLS New Member

    Публикаций:
    0
    Регистрация:
    8 янв 2005
    Сообщения:
    322
    Адрес:
    Russia
    Вы принципиально хотите размер блока в 1 байт ?
     
  13. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    поточный не изменяет размер открытого текста (ну можно и блочный в режиме OFB CFB)
     
  14. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    очень не хочу )
     
  15. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    пока что подходит либо XTS (с изобретением велосипеда, т.к. трукрипт не в силах прикрутить), либо шифровать поточным шифром и при каждой записи обновлять весь хеш.
     
  16. OLS

    OLS New Member

    Публикаций:
    0
    Регистрация:
    8 янв 2005
    Сообщения:
    322
    Адрес:
    Russia
    То есть Вас беспокоит увеличение зашифрованного файла на длину "хвоста" последнего блока в режимах CBC/XEX ? "Ciphertext stealing" решает эту проблему.

    Или в чем-то другом опасения (просто немного непонятно) ?
    Блочные шифры в любом режиме зацепления либо вообще не увеличивают файл, либо увеличивают но только на размер не больший длины "хвоста" последнего блока в случае некратности длины исходного файла размеру блока. Решение - CTS.
     
  17. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    меня это не беспокоит особо, главное, чтобы программа могла читать и писать по рандомному офсету.

    проблема в том (я уже писал раньше), что приложение может писать по любому офсету любое число байт => блочный шифр отпадает, т.к. если, скажем, по офсету 100 записали (и зашифровали) 50 байт, то при чтении с офсета 110 мы уже не сможем расшифровать, только если не строить полностью всю гамму до этого офсета и отбрасывать часть гаммы до офсета 110 (вроде так выразился)
    кстати, тогда уж и RC4 не подойдет )
     
  18. OLS

    OLS New Member

    Публикаций:
    0
    Регистрация:
    8 янв 2005
    Сообщения:
    322
    Адрес:
    Russia
    Пусть размер блока 16 байт и программа на смещение 100 пишет 50 байт. Вы обязаны (вся нумерация дальше с 1) :

    1) считать блок №7, занимающий позиции [97..112] в файле
    2) расшифровать его в режиме XTS с I=7
    3) взять из него неизмененные 4 байта с адресов [97..100]
    4) дополнить их справа 12 байтами из записываемых программой
    5) зашифровать получившиеся 16 байт в режиме XTS с I=7
    6) положить получившиеся 16 зашифрованных байт на позиции [97..112]

    7) зашифровать следующие 16 байт из записываемого блока (в его нумерации - это [13..28]) в режиме XTS с I=8 и положить в файл на позиции [113..128], затирая предыдущие байты по этим адресам
    8) зашифровать следующие 16 байт из записываемого блока (в его нумерации - это [29..44]) в режиме XTS с I=9 и положить в файл на позиции [129..144], затирая предыдущие байты по этим адресам

    9) считать блок №10, занимающий позиции [145..160] в файле
    10) расшифровать его в режиме XTS с I=10
    11) взять из него неизмененные 10 байт с адресов [151..160]
    12) дополнить их слева 6 байтами из записываемых программой
    13) зашифровать получившиеся 16 байт в режиме XTS с I=10
    14) положить получившиеся 16 зашифрованных байт на позиции [145..160]

    Границы блоков всегда будут кратны 16 отсчитывая с начала файла вне зависимости от того, как пишет программа.
    Исключение из общей методики изложенной выше - последние 2 блока (там режим CTS).
    Хеширование я здесь не описал, но оно тоже идет по блокам, кратным границами 16 от начала файла.
     
  19. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    OLS
    это чуть лучше, чем я предложил (пункты 7-8).
    Спасибо.
     
  20. gloomyraven

    gloomyraven Руслан

    Публикаций:
    0
    Регистрация:
    16 апр 2006
    Сообщения:
    288
    Адрес:
    Москва
    Отличный велосипед получился ))) RC4-XTS
    Правда очень многое приходится учитывать, делать свои обертки над GetFileSize, SetFilePointer и другими файловыми API (может даже дорастет до FileMapping`а)