РегистрацияШифрование бэкапов
Здравствуйте!
Как лучше всего зашифровать резервные копии содержащие личные данные, для их последущего помещения в облачные сервисы?
Пытаюсь выбрать между тремя вариантами
1) Программа BCArchive – своего рода "криптоархиватор", удобна в использовании но, пропиетарная и с закрытым исходным кодом
2)Gpg4win – в графическом интерфейсе "Kleopatra" не разобрался как зашифровать папку ПАРОЛЕМ, а не сертификатом. В Gpg вобще такая возможность есть? Чтобы еще и сертификат от похищения не защищать.
3) Самый, на мой взляд, не внушающий доверия:архивация 7zip\rar с паролем и шифрованием имен файлов.
Во всех вышеперечисленных случаях будут применятся случайносгенерированые пароли максимально возможной, для данной программы, длины.
комментариев: 15 документов: 2 редакций: 1
Все сервисы (Яндес диск,Google диск, и прочие ) позволяют загружать\выгружать файлы через веб интерфейс. Установка программ клиентов вовсе не обязательна: на том-же Яндекс диске, после получения 3х гигабайт за установку клиента, этот клиент можно смело сносить. Точнее сервисы которые НЕ ПОЗВОЛЯЮТ работать через веб интерфейс мне не известны :)
А вот чтобы "запилить sshfs", может подскажет кто сервис с таким функционалом?
Противник будет иметь доступ к одним и тем же данным, немного по-разному шифрованным. Это даёт некоторую потенциальную утечку об открытом тексте.
Любой хостинг, где вам дают ssh или просто free shell.
комментариев: 9796 документов: 488 редакций: 5664
При этом противник, если он сам владелец недоверяемого сервера, будет знать и закрытый ssh-ключ и размещаемый шифртекст в виде, незакрытом слоем ssh поверх. Ssh-логин и sshfs — это разве что дополнительная защита от человека посредине, пытающегося перехватить логин.
Подумалось, а если еще и EncFS запилить поверх sshfs? Нивелируется ли проблема анализа изменения шифрованных данных?
Шифровать данные каждый раз новым ключом (не путать с паролем) и заливать их на сервер. При шифрованнии архива с данными через PGP так будет получаться автоматически (ключ каждый раз генерится случайно).
комментариев: 9796 документов: 488 редакций: 5664
В первом приближении — можно использовать любой рассмотренный вариант, этого хватит с избытком и контейнеры спокойно монтировать удалённо, никаких реальных практических атак против этого нет и неизвестно насколько актуальны теоретические.
Во втором приближении — например, за сколько лет до практических взломов теоретики (причём явное их меньшинство) предупреждали, что хэш-функции MD5 и SHA-1 спроектированы недостаточно правильно и теоретически дефектны? За 15 лет до того как это было продемонстрировано на практике.
Что-то похожее с режимами шифрования. Изначально был непредназначенный для дисков CBC. Переставив местами два блока в шифртексте оказалось можно определить без знания ключа, являются ли они одинаковыми или разными и проводить массу других тестов на утечку.
В новых режимах шифрования ESSIV, XTS это снова пофиксили на новом уровне, но доказательства стойкости опять нет. Какую информацию можно извлечь при наблюдении за контейнером, который не перешифровывается весь целиком, а в котором меняются только блоки и какие атаки на основании этого можно построить — вопрос открытый. Это ведь всё проектировалось не для облаков и даже не для побитовых бэкапов, а только для локального использования.
С точки зрения теории стойкое шифрование должно быть или рэндомизированным (каждый раз уникальный непредсказуемый вектор инициализации) или с блоком, равным размеру изменения (сектору диска — Wide Block Encryption). Ни того, ни другого не достигнуто. Стойкое дисковое шифрование обосновано гарантируется, если противник захватывает одну копию контейнера за один раз, а не несколько копий того же контейнера в разное время (multiscan).
В нем 256 битный AES. Плюс сжатие.
Вы проверяете все open source проекты перед использованием?
-А вы все эксперименты, описанные в учебниках, поставили, чтобы утверждать истинность научных теорий?
Ну я не утверждаю истинность каких то теорий.
Просто я так понимаю, что раз Вам важен опен сурс, то Вы видимо изучаете исходники используемых продуктов на наличие закладок (уязвимостей) и самостоятельно их компелируете?
Вроде в каком-то ещё здешнем обсуждении говорилось, что при использовании в RAR'е пароля двойной длины можно быть уверенным, что стойкость не будет меньше, чем при использовании одинарного в открытых реализациях.