Добрый день! Прекрасно, что вы стараетесь разбраться, как использовать криптографию.
Увидел проблемы:
из-за разницы в использовании nonce в зависимости от размера файла и из-за использования AEAD (шифртекст больше открытого текста на размер тэга -- 16 Б), файл, зашифрованный в режиме non-streaming (размером (100 МБ - 8 Б)) будет расшифровываться в режиме streaming. Nonce при зашифровании и расшифровании не совпадет.
заявленная отказоустойчивость недействительна, потому что расшифрование файла зависит еще и от франимых в метаданных nonce, а файл с метаданными сохраняется после зашифрования всех файлов.
Предложил бы использовать AI в том числе в качестве ревьюера. Он нашел больше проблем, чем я увидел своими глазами, например:
зашифрование в поточном режиме не работает, потому что последовательно делаются два цикла for chunk in reader.iter_chunks() (второй цикл сразу выйдет);
verify несовместим со streaming: делает cipher.decrypt всего файла, независимо от размера.
Считаю, что за префикс check нужно бить больно и беспощадно, особенно если методы с этим префиксом возвращают bool. Императив "сходи проверь" слишком многозначен. checkValidity может иметь поведение isValid (почему бы так не назвать), а может иметь поведение isNotValid (или это должно называться checkInvalidity?) или isValiditySpecified, isValidityConsisent. Единственное хотя бы немного оправданное поведение для функции/метода check -- бросать исключение, когда очевидно, что из-за значения Validity дальше все точно пойдет не так, но это тоже неочевидно, особенно что конкретно проверяла эта check-функция.
ГОВОРИТЕ ОТКРЫТО И СМЕЛО ПРЯМО В ЛИЦО! is, а не check!
Добрый день! Прекрасно, что вы стараетесь разбраться, как использовать криптографию.
Увидел проблемы:
из-за разницы в использовании nonce в зависимости от размера файла и из-за использования AEAD (шифртекст больше открытого текста на размер тэга -- 16 Б), файл, зашифрованный в режиме non-streaming (размером (100 МБ - 8 Б)) будет расшифровываться в режиме streaming. Nonce при зашифровании и расшифровании не совпадет.
заявленная отказоустойчивость недействительна, потому что расшифрование файла зависит еще и от франимых в метаданных nonce, а файл с метаданными сохраняется после зашифрования всех файлов.
Предложил бы использовать AI в том числе в качестве ревьюера. Он нашел больше проблем, чем я увидел своими глазами, например:
зашифрование в поточном режиме не работает, потому что последовательно делаются два цикла
for chunk in reader.iter_chunks()(второй цикл сразу выйдет);verify несовместим со streaming: делает
cipher.decryptвсего файла, независимо от размера.Считаю, что за префикс check нужно бить больно и беспощадно, особенно если методы с этим префиксом возвращают bool. Императив "сходи проверь" слишком многозначен. checkValidity может иметь поведение isValid (почему бы так не назвать), а может иметь поведение isNotValid (или это должно называться checkInvalidity?) или isValiditySpecified, isValidityConsisent. Единственное хотя бы немного оправданное поведение для функции/метода check -- бросать исключение, когда очевидно, что из-за значения Validity дальше все точно пойдет не так, но это тоже неочевидно, особенно что конкретно проверяла эта check-функция.
ГОВОРИТЕ ОТКРЫТО И СМЕЛО ПРЯМО В ЛИЦО! is, а не check!