Шифрование файлов на мобильных устройствах с ограниченными ресурсами

Question

Таким образом, основной вопрос заключается в шифровании файлов на устройствах с ограниченными ресурсами. Я использовал довольно опасный подход для использования двух FileStreams, где

1. FileStream 1 читает файл и копирует его в байтовый массив
2. Содержимое байтового массива зашифровано.
3. FileStream 2, записывает байты обратно в тот же файл.

Это работает нормально, но есть большой шанс испортить файл, если шифрование остановится на полпути и т. Д.

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

Однако проблема заключается в мобильных телефонах, где ресурсы (особенно хранилища) очень ограничены, например, создание еще одного файла размером 200 МБ или 300 МБ невозможно.

Итак, какие существуют подходы для решения этой проблемы в Mobile Devies? Нужно ли играть между пробелом и порчей файла?

Answer 1

Одним из способов сделать процесс немного более безопасным может быть:

1. FileStream 1 читает файл и копирует его в байтовый массив
2. Байты, которые вы прочитали, записываются в небольшой «рабочий» файл того же размера, что и ваш буфер, вместе с положением последнего блока, успешно прочитанного.
3. Содержимое байтового массива зашифровано.
4. FileStream 2, записывает байты обратно в тот же файл.

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

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

Answer 2

Должен ли я играть между пробелом и порчей файла?

В основном, да.
Если ограничения по пространству заставляют вас конвертировать (шифровать) на месте,нет варианта отката.

Следующая проблема - размер.Если ваша конверсия (может) увеличит размер данных, у вас будет очень ограниченное пространство для маневра.Если ResultSize> (InputSize + Buffer), то у вас ничего не получится.

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

Короче говоря, на мобильном устройстве вы достигли предела.Вам нужно будет назначить дополнительное устройство памяти.

Answer 3

Прежде всего, вы всегда можете проверить, достаточно ли места для записи вашего массива в файл tmp.

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

edit Теперь я понимаю, что вы частично шифруете и записываете в файл, поскольку в противном случае он не поместился бы в ОЗУ,Это правильно?