Шифрование бэкапов
Здравствуйте!Как лучше всего зашифровать резервные копии содержащие личные данные, для их последущего помещения в облачные сервисы?
Пытаюсь выбрать между тремя вариантами
1) Программа BCArchive – своего рода "криптоархиватор", удобна в использовании но, пропиетарная и с закрытым исходным кодом
2)Gpg4win – в графическом интерфейсе "Kleopatra" не разобрался как зашифровать папку ПАРОЛЕМ, а не сертификатом. В Gpg вобще такая возможность есть? Чтобы еще и сертификат от похищения не защищать.
3) Самый, на мой взляд, не внушающий доверия:архивация 7zip\rar с паролем и шифрованием имен файлов.
Во всех вышеперечисленных случаях будут применятся случайносгенерированые пароли максимально возможной, для данной программы, длины.
Ссылки
[link1] https://www.pgpru.com/faq/zaschitadiska#h42-14
[link2] https://www.pgpru.com/comment45000
[link3] http://netbsd.org/docs/guide/en/chap-cgd.html
[link4] https://www.pgpru.com/comment39520
[link5] https://www.pgpru.com/forum/prakticheskajabezopasnostj/shifrovannyefajjlovyesistemy
[link6] https://www.pgpru.com/comment52521
[link7] https://www.pgpru.com/faq/obschie#h46-13
[link8] https://www.pgpru.com/comment17906
[link9] https://www.pgpru.com/comment48651
Вы документацию по pgp/gpg читали? Создайте открытый ключ, зашифруйте им свой файл, залейте в сеть. Пока закрытая часть ключа хранится только у Вас, никто файл не прочитает. Нет ничего проще.
Под юниксами рекомендую полюбоваться на duplicity – инкрементальные бэкапы, интеграция с gpg, некоторыми облачками и общеупотребимыми протоколами типа sftp, ftp, webdav...
в графическом интерфейсеgpg -c
Ещё можно синхронизировать с облаками TrueCrypt (и подобные им) криптоконтейнеры.
Очень удобно создавать криптоконтейнер в виде файла, ведь это даёт возможность легко делать резервные копии на различных носителях, просто скопировав этот файл. Также его легко отправить на сервер для пересылки или хранения. Почему однако не рекомендуется делать копии контейнеров таким образом?[link1]
Почему?
Вариант с критоконтейнером TrueCrypt
был бы хорош если облачные сервисы позволяли удаленное монтирование таких контейнейров.
А так помещение данных в труекриптовый контейнер с последующей выгрузкой оного в облако, в принципе ничем не отличается от помещения этих данных в любой другой "контейнер", но неудобство состоит в том что на комьютере должны быть права админа для монтирования этого контейнера. (вопрос: контейнер какой програмы нельзя идентифицировать как криптоконтейнер? у TrueCrypt а вроде с этим какието проблемы были ? )
В случае "зашифровать открытым ключем" гдето нужно хранить ключевую пару. А симетричных криптопрограмм, наподобии BCArchive, но с открытым исходным кодом не существует?
Задачи инкрементного обновления и синхронизации копий не ставятся: информация будет сохранена один раз.Нужен своего рода "бронесейф",
обеспечивающий защиту уровня от "любопытного админа google решившего пару тройку часиков потестить на моем криптоархиве новый кластер" с учетом всех переодических "удвоений вычислительных мощностей" лет так на 100-300.
Не могу ничего сказать про TC, там вроде авторы стремились сделать отрицаемость за счёт так называемых «скрытых контейнеров», так что как там с заголовками — без понятия. Дело в том, что заголовок криптоконтейнеру всё равно нужен, вопрос остаётся лишь в том где его хранить — в каком-то отдельном (можно шифрованном) файле, или в начале криптотома. Скорей всего DiskCryptor позволяет (если это вообще не поведение по умолчанию) не писать хидер. Есть старый интерфейс к LUKS[link2], при котором хидеры не будут создаваться, то же касается CGD[link3] и, возможно, ряда других opensource-систем шифрования дисков. В конце концов, есть универсальный способ[link4] с помощью OpenSSL.
Есть Tahoe[link5].
Это было бы удобно для противника, осуществляющего криптоанализ, основанный на несовершенстве режимов шифрования контейнеров, которые не предназначены для такого использования.
Если он будет бэкапиться на сервер это будет заметно статистическим анализом изменений блоков шифртекста.
А если если ssh, запилить sshfs, примонтировать папку с удаленным трукрипт-контейнером и уже с ним работать локально? Есть возражения?
Заголовок контейнера TC бессигнатурный, неотличим от случайного потока.
/comment52521[link6]
А меня вот другое интересует, есть ли такие облачные хранилища, которые позволяют заливать файлы через браузер, а не синхронизировать из с помощью неизвестно какого и вовсе не нужного на моем компьютере клиента.
И чего? Я не предлагаю копировать контейнер, а открыть его локально с помощью TC, хотя сам файл будет доступен через sshfs. Или я чего-то не догоняю?
С другой стороны, есть TChunt
http://16systems.com/TCHunt/index.php
По факту, он ищет не контейнеры TC, а любые бессигнатурные файлы с псевдослучайным содержимым, кратные по длине 512 байтам (выход dd if=/dev/urandom bs=512 сойдёт за контейнер). Последнее свойство, на мой взгляд, палит сильнее всего, а в остальном никто никогда не утверждал, что файлы с псевдослучайным содержимым необнаружимы на диске.
Все сервисы (Яндес диск,Google диск, и прочие ) позволяют загружать\выгружать файлы через веб интерфейс. Установка программ клиентов вовсе не обязательна: на том-же Яндекс диске, после получения 3х гигабайт за установку клиента, этот клиент можно смело сносить. Точнее сервисы которые НЕ ПОЗВОЛЯЮТ работать через веб интерфейс мне не известны :)
А вот чтобы "запилить sshfs", может подскажет кто сервис с таким функционалом?
Противник будет иметь доступ к одним и тем же данным, немного по-разному шифрованным. Это даёт некоторую потенциальную утечку об открытом тексте.
Любой хостинг, где вам дают ssh или просто free shell.
При этом противник, если он сам владелец недоверяемого сервера, будет знать и закрытый ssh-ключ и размещаемый шифртекст в виде, незакрытом слоем ssh поверх. Ssh-логин и sshfs — это разве что дополнительная защита от человека посредине, пытающегося перехватить логин.
А что тогда более безопасно (с теоретических потенциальных позиций взлома) – монтировать sshfs, монтировать оттуда контейнер и работать с данными как бы локально, или все же каждый раз заливать копию контейнера. Мне кажется во втором случае будет меньше меняемых данных = меньше данных для анализа.
Подумалось, а если еще и EncFS запилить поверх sshfs? Нивелируется ли проблема анализа изменения шифрованных данных?
Нет.
Шифровать данные каждый раз новым ключом (не путать с паролем) и заливать их на сервер. При шифрованнии архива с данными через PGP так будет получаться автоматически (ключ каждый раз генерится случайно).
Есть несколько уровней рационально обоснованной паранойи.
В первом приближении — можно использовать любой рассмотренный вариант, этого хватит с избытком и контейнеры спокойно монтировать удалённо, никаких реальных практических атак против этого нет и неизвестно насколько актуальны теоретические.
Во втором приближении — например, за сколько лет до практических взломов теоретики (причём явное их меньшинство) предупреждали, что хэш-функции MD5 и SHA-1 спроектированы недостаточно правильно и теоретически дефектны? За 15 лет до того как это было продемонстрировано на практике.
Что-то похожее с режимами шифрования. Изначально был непредназначенный для дисков CBC. Переставив местами два блока в шифртексте оказалось можно определить без знания ключа, являются ли они одинаковыми или разными и проводить массу других тестов на утечку.
В новых режимах шифрования ESSIV, XTS это снова пофиксили на новом уровне, но доказательства стойкости опять нет. Какую информацию можно извлечь при наблюдении за контейнером, который не перешифровывается весь целиком, а в котором меняются только блоки и какие атаки на основании этого можно построить — вопрос открытый. Это ведь всё проектировалось не для облаков и даже не для побитовых бэкапов, а только для локального использования.
С точки зрения теории стойкое шифрование должно быть или рэндомизированным (каждый раз уникальный непредсказуемый вектор инициализации) или с блоком, равным размеру изменения (сектору диска — Wide Block Encryption). Ни того, ни другого не достигнуто. Стойкое дисковое шифрование обосновано гарантируется, если противник захватывает одну копию контейнера за один раз, а не несколько копий того же контейнера в разное время (multiscan).
WinRar
В нем 256 битный AES. Плюс сжатие.
Он не оупенсорс, корректность реализации никто не проверял (даже если всё так), потому недоверяем.
"Он не оупенсорс, корректность реализации никто не проверял (даже если всё так), потому недоверяем."
Вы проверяете все open source проекты перед использованием?
-Мы не можем опираться в науке на религию, т.к. не можем проверить или опровергнуть существование бога.
-А вы все эксперименты, описанные в учебниках, поставили, чтобы утверждать истинность научных теорий?
"-А вы все эксперименты, описанные в учебниках, поставили, чтобы утверждать истинность научных теорий?"
Ну я не утверждаю истинность каких то теорий.
Просто я так понимаю, что раз Вам важен опен сурс, то Вы видимо изучаете исходники используемых продуктов на наличие закладок (уязвимостей) и самостоятельно их компелируете?
Нет, вы не верно понимаете. Оупенсорс важен тем, что мировое сообщество может проверять исходники, и всегда находятся те единицы, которые лезут в них по каким-то своим целям, что-то находят, а потом публикуют ошибки. Многие важные баги в оупенсорс-продуктах были найдены сторонними программистами, и только благодаря открытости кода. Важность последней обсуждалась в /faq/obschie#h46-13[link7].
Просто опенсорс проверяется легче, и поэтому больше шансов, что там будет обнаружена "недокументированная функция" или просто ошибка. А принципиальной разницы, конечно, тут нет, можно и машинный код изучать, ну разве что переход количества (байт кода) в качество (необозримости) наступит в этом случае гораздо раньше.
Поскольку исходники разархиаатора (UnRAR) открыты, то для утечки пароля остаётся не так уж много битов, и вот тут[link8] пришли к выводу, что достаточно длинный случайный пароль даст RAR'у гарантированную стойкость.
Вроде в каком-то ещё здешнем обсуждении говорилось, что при использовании в RAR'е пароля двойной длины можно быть уверенным, что стойкость не будет меньше, чем при использовании одинарного в открытых реализациях.
Я лично, как человек небогатый, бэкапы делаю на съемных HDD, с крипторазделами LUKS.
В WinRARе также при развертывании пароля в ключ используется увеличенное количество итераций в хеш функции, что резко уменьшает скорость перебора (несколько паролей в секунду).
А вот если выйдет новая версия этого RAR'а, в которой автору придётся реализовать предложение, "от которого он не смог отказаться" – как скоро это заметят?
Говорили уже, что исходники UnRAR открыты
Вы так говорите, как будто это некая эксклюзивная функция именно RAR'а.
Наивно думать, что это поможет от размещения нужной информации в бинарных данных на выходе RAR. UnRAR как и прежде покажет лишь то, что вам положено видеть. Нет даже уверености в том, что UnRAR обрабатывает каждый байт файла. И даже это ни чего не докажет.
Ну я иговорю, что тогда надо компилить их исходников собственноручно (желательно и компилятор тоже). Т.к. используя уже скомпиленные бинарники нет уверенности.
Если серьезно, то появилась мысль сделать свою программу с симметричным шифрованием и юзать ее после RARа, можно и в консольном варианте из батников. Вот здесь будет полная уверенность.
П*ц. А что с gnupg не так?
NIH-синдром.
взломан. и взломано все что с ним связано.даже буквы в gnupg...
"П*ц. А что с gnupg не так?"
Тут выше писали, что вроде он с паролем не шифрует?
SATtva, что за NIH-синдром такой?
Кто такое сказал?
https://en.wikipedia.org/wiki/NIH_syndrome
Для шифрования:
что-то я делаю не так...
D:\gnupg>gpg2.exe --no-emit-version -c --cipher-algo
rijndael256 "D:\f.txt"
D:\gnupg>gpg2.exe -v -d "D:\f.txt.gpg"
gpg: ─рээ√х чр°шЇЁютрэ√ рыуюЁшЄьюь AES256
gpg: чр°шЇЁютрэю ё 1 ЇЁрчющ-ярЁюыхь
gpg: юЁшушэры№эюх шь Їрщыр='f.txt'
adsasdasdsadadsaddasda
sadasdasdasdasdasdsadasd
asdasdasdsdadasdas
при шифровании gpg спросил пароль.
расшифровал не спрашивая пароля.
Возможно, пароль закешировал gpg-agent.
Ой, опять либители русских интерфейсов. Там, между прочим, cp866 в виндосовском терминале, ЕМНИП, только вот русификаторы gpg об этом, видимо, не знают.
Кэширование пароля в современных гуйных
pinentryприблудах?"Кэширование пароля в современных гуйных pinentry приблудах?"
В командной строке запускал.
У вас 2ой gpg, а у него дурная слава[link9], на эту тему было много постов. Лучше поставить 1ую версию.
А из скрипта (в одной строке, без диалога) пароль в GPG можно вводить? Ну что-бы автоматизировать шифрование и расшифровку.
См. ман на предмет опций --passphrase*.
Не имеет значения, gpg всё равно найдёт запущенный gpg-agent,если он есть, и поделится с ним паролем.
поставил 1-ю версию GPG.
Как сделать, чтобы при расшифровании расшифрованный файл не выводился в консоль, а сохранялся рядом на диск?
P.S.: Если путь к файлу содержит пробел, его надо взять в двойные кавычки.