Revault шифрує великий файл сегментами приблизно по 5 MiB, кожен зі своїм тегом автентифікації, тож увесь файл ніколи не мусить одночасно перебувати в пам’яті. У вебзастосунку саме це дає змогу працювати з файлами до 1 GiB.
Чому не шифрувати весь файл одразу?
Великі файли не повинні вимагати багато пам’яті. Revault читає файли сегментами приблизно по 5 MiB, шифрує кожен сегмент у браузері та тимчасово зберігає шифротекст в IndexedDB. Вихідний файл ніколи не зчитується в один гігантський буфер.
Робота сегментами також означає, що перервене завантаження може продовжитися з уже підготовленого шифротексту, а не шифрувати весь файл заново.
Що захищає порядок і повноту сегментів?
Кожен файл отримує власний ключ шифрування, виведений за допомогою HKDF із головного ключа сховища. Контекст виведення містить ідентифікатори сховища й файлу, довжину файлу в байтах і розмір сегмента.
12-байтовий nonce кожного сегмента поєднує випадковий префікс, обраний для цього файлу, чотирибайтовий лічильник сегментів і позначку, що вказує на останній сегмент. Сегменти містять 128-бітні теги GCM. Якщо сегменти поміняно місцями, змінено або обрізано, перевірка не проходить.
Що буде, якщо завантаження перерветься?
Щойно шифрування завершено, мережеві завантаження можна відновити з кешованого шифротексту після оновлення сторінки. Повторні спроби надсилають ті самі зашифровані байти, а не шифрують нове джерело зі старими nonce. Якщо саме шифрування перервано, скасуйте це незавершене завантаження й почніть спочатку з новим ідентифікатором файлу.
Як перевіряються завантаження?
Під час завантаження кожен сегмент автентифікується перед видачею. Оскільки перевірка відбувається під час потокового передавання файлу, помилка наприкінці завантаження може залишити неповний файл, тож переконайтеся, що завантаження завершилося успішно, перш ніж на нього покладатися.
Які є обмеження?
Кожен файл у вебзастосунку може мати розмір до 1 GiB. Попередній перегляд зображень і відео має окреме обмеження пам’яті. Очищення локального сховища браузера може видалити шифротекст, потрібний для відновлення завантаження.
Потоковий формат відповідає задокументованій потоковій конструкції Tink AES-GCM-HKDF і використовує нативні примітиви Web Crypto. Ідентифікатор файлу та очікувана довжина прив’язуються до контексту виведення ключа; лічильники сегментів і кінцева позначка захищають порядок і завершеність. Ця реалізація не проходила незалежного криптографічного аудиту.
Сторінка «Модель безпеки» описує повну конструкцію, зокрема заголовок потоку й виведення ключів.