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

Хотите честно лично мое мнение почему "монолог" - потому что я не понимаю половины Ваших идей.
Вы черезчур кратко их описываете.

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

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

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

 

да, данные будут в тех же местах, шифроваться данные будут блочным шифром "посекторно".

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

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

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

 

т.е. нарисовить можно примерно так:

оригинальный файл (как его видит программа)
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
...

 

гемор имеется в виду, ставить PAGE_NOACCESS и отлавливать обращение к промаппленному файлу? или так тоже не выйдет?

 

Что мешает Вам для каждого обрабатываемого файла "рядом" или в отдельном каталоге создавать второй, хранящий только контрольные разряды ?
С именем, отличающимся добавлением расширения ".hash". А если в NTFS, то можно организовать хранение и в альтернативных потоках основного файла.

 

хм... хорошая идея, почему-то я об этом не подумал... выглядит не так изящно как с контейнером, зато скорость будет на порядок выше. Хотя придется обновлять хеш, даже если программа записала 1 байт, а если файл 100Мб?
Возможно ли пересчитывать не весь хеш, а хотя бы блоки, которые изменились?

 

Именно так я и подразумевал.

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

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

 

Как я понял это и есть XTS - от чего уходим, к тому и пришли )))

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

 

Если честно, то не совсем понял мысль, размер блока 8 бит?
Чтение, запись в приложении происходит блоками 1..n, где n - размер файла.

 

Давайте тогда снова.

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

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

 

он самый...

 

Вы принципиально хотите размер блока в 1 байт ?

 

поточный не изменяет размер открытого текста (ну можно и блочный в режиме OFB CFB)

 

очень не хочу )

 

пока что подходит либо XTS (с изобретением велосипеда, т.к. трукрипт не в силах прикрутить), либо шифровать поточным шифром и при каждой записи обновлять весь хеш.

 

То есть Вас беспокоит увеличение зашифрованного файла на длину "хвоста" последнего блока в режимах CBC/XEX ? "Ciphertext stealing" решает эту проблему.

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

 

меня это не беспокоит особо, главное, чтобы программа могла читать и писать по рандомному офсету.

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

 

Пусть размер блока 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 от начала файла.

 

OLS
это чуть лучше, чем я предложил (пункты 7-8).
Спасибо.

 

Отличный велосипед получился ))) RC4-XTS
Правда очень многое приходится учитывать, делать свои обертки над GetFileSize, SetFilePointer и другими файловыми API (может даже дорастет до FileMapping`а)