Pull to refresh

Comments 18

А не проще воспользоваться популярным encfs?
Учитывая, что речь тут идёт о Windows, — не проще. (Или предлагается экспериментальный encfs4win?)
Для Windows есть boxcryptor. На работе использую linux и encfs, дома windows и boxcryptor — проблем с совместимостью не замечено.
BoxCryptor давно уже есть под Windows. Храню всё зашифрованно в дропбоксе и без всяких бубнов с батниками.
Насколько увеличивается трафик при использовании BoxCryptor + дропбокс?
Линчую:
for(int i=0; i<32; i++) AES256_Key[i] = 0;

-Мммм… memset?
-Чаво это?
-Для забивки памяти рекомендуется функция memset!

for(int i=0; i<strlen(argv[3]); i++) AES256_Key[i] = argv[3][i];

Ба-тю-шки, потенциальный срыв стека. Вы с пользователя расписку кровью берете, что ключ у него не будет длиннее 32 символов?

А еще, под такое дело есть strcpy.

void ReadBlock(FILE *inFile, uint8_t *Block, bool *eofReached);

В C++ можно передавать параметр по ссылке: void ReadBlock(FILE *inFile, uint8_t *Block, bool& eofReached);

И глаз за звездочку не запинается, и рисков меньше.

Ну и работа с файлом по байтикам — это очень медленно. Есть же fread, fwrite, которые читают/пишут блоком.

Реализация самого шифрования видимо не ваша, уже хорошо.

В целом: из явного криминала — только отсутствие проверки входных данных, ну и тормозной доступ к файлам. Гигабайты не шифровать.
Я так понимаю имена файлов больше 50 символов тоже могут вызвать переполнение стека?
char bufEncPreName[50] = ENC_PRENAME; // "pic.jpg" -> "enc_pic.jpg"
char bufDecPreName[50] = DEC_PRENAME; // "enc_pic.jpg" -> "dec_enc_pic.jpg"
Да, переподнение будет, но не в этом месте. В этом месте порядочный компилятор ругнется, если в макроподстановке слишком длинная строка. Непорядочный таки устроит переполнение.

Переполнение будет ниже, на конкатенации:
outFile = fopen(strcat(bufEncPreName, argv[1]), "wb");
Под linux-os/2 был (или есть) замечательный aefs, который шифрует каждый файл отдельно. Я так понимаю, что подобно encfs. Под винду, к сожалению нет подобного решения (если кто знает — напишите!).
После «а теперь напишем батник» пошёл читать срач в коментах. где срач?
UFO landed and left these words here
Если вы расшифровываете по тому же пути, эта версия ляжет в историю изменений.
* Шифрование AES-256 выполняется очень медленно. На моем Celeron скорость шифрования составила примерно 40 кб/с. Но вряд ли на более мощной машине можно получить сколь-нибудь удовлетворительную цифру.
Первые три проблемы вполне можно решить, если вдруг появится сильное желание.

Т.е. вы считаете, что работу AES ускорить никак нельзя?
Тогда рекомендую ознакомиться с этой статьей habrahabr.ru/post/201114/
Автор читает и пишет файлы побайтно. Ни о каком быстродействии и речи быть не может.
UFO landed and left these words here
Sign up to leave a comment.

Articles