AsymmetricFS – An Asymmetric, Encrypting Filesystem for Userspace
Overview
asymmetricfs exposes an encrypting file system in userspace with FUSE. Encryption is performed with gpg, as to leverage existing public/private key infrastructure.In write-only mode, the mounted filesystem permits appending to existing files and creating new files. Other filesystem operations, such as (complete) truncation and deletion are permitted as well.
In read/write mode, stored files are decrypted on-the-fly with gpg as needed. Arbitrary file modification is possible.
Building
asymmetricfs depends on boost and make at compile time. At runtime, gpg must be available in the path.Limitations
For security-sensitive applications, the functionality of asymmetricfs may easily be insufficient. This filesystem primarily allows weakly trusted computers to handle sensitive, transient data while reducing the unencrypted time-in-flight. If a system is compromised before data is flushed to disk (and ultimately any remnant data cleared from system memory), an attacker will have access to the plaintext contents of the filesystem.Metadata is not protected by asymmetricfs.
As with any use of encryption, keeping good backups is crucial.
Future Work
asymmetricfs currently uses string buffers to store dirty data before encrypting and flushing to disk. In the future, these buffers will be maintained in a page-aware container as to permit copy-free transfers into gpg.
Наткнулся на просторах GIT'а, Ваши мнения, господа. Стоит пробовать или нет?
Сайт автора
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 1079 документов: 58 редакций: 59
unknown Это то, что в процессе установки предлагает опцию "зашифровать раздел /home"?)
Вообще мне просто стало интересно своим же ключем зашифровать раздел или просто важные данные. Понятное дело, что фильмы и прочую лабуду шифровать бессмысленно, да и медленно будет. А автоматически зашифровывать указанную папку при выключении и расшифровывать при включении – мне было бы очень даже удобно, чтобы не "плодить сущности" и расширить границы применения GPG, кроме как переписки.
EncryptFS вполне подошел бы, если бы можно было автоматизировать монтирование, при этом прикрутить к нему GPG.
Под "автоматизировать" подразумеваю:
Ну или что-то в этом духе.
Да и к тому же ты сам однажды где-то писал, что нужно кроме "внешнего" крипта – делать акцент еще и на внутренний.
Может конечно это лишнее, т.к. как сказал SATtva – я действительно четко не сформулировал себе модель угрозы. Но тем не менее, просто интересно использовать GPG.
комментариев: 11558 документов: 1036 редакций: 4118
Не будет.
комментариев: 1079 документов: 58 редакций: 59
Странно, я думал, что если шифровать файлы GPG – их для начала нужно сжать, например:
(могу ошибаться, т.к. пока только на начинающем любительском уровне застрял) Соответственно – пока все файлы сожмутся 7z, а потом по ним пройдется GPG.
Ну ладно, это все мои догадки, твоим словам я верю больше, если не будет медленно – значит не будет. Тогда как организовать это в виде скрипта?
Значит мы создаем /etc/rc.local, в который пишем:
А что писать в шифрующий скрипт, кроме пресловутого 7z -c -f- /home/enrypt_folder | gpg -e > file.7z, и как сделать так, чтобы он еще и зашифровывал при выключении, а монтировал при запуске – это уже мой вопрос...
Ну я так понимаю, что-то в духе:
А дальше?)
комментариев: 11558 документов: 1036 редакций: 4118
Я говорил об обычном дисковом шифровании.
комментариев: 1079 документов: 58 редакций: 59
А моя мысль имеет право на жизнь или с ней совсем плохо все в техническом плане?
комментариев: 9796 документов: 488 редакций: 5664
Сжатие и архивирование — это два разных процесса, которые изначально (70-е годы), и в какой-то мере это разделение прослеживается до сих пор (что правильно), делались разными программами. Архивирование без сжатия по умолчанию делает tar. А в GnuPG по-умолчанию реализовано своё сжатие (которое при желании можно отключить).
Тормозной избыточно сжимающий 7zip здесь вообще ни при делах. Также как и сжатие с пофайлово шифрующей ФС м.б. необязательным и опциональным.
Абсолютно точно можно сказать, что так делать нельзя. В пофайлово шифрующей ФС это делается с каждым файлом прозрачно и открытый текст поверхности диска (файловой системы, ФС) не касается. Асимметрика имеет смысл при работе со смарткартой, в которой хранится дешифрующий RSA-ключ, без которого нельзя расшифровать симметричные ключи для симметричных алгоритмов соотвественно, которыми всё и шифруется.
комментариев: 1079 документов: 58 редакций: 59
Смотри, ну ок, если так делать – как это реализовать посредством стандартного GPG? Про то, что 7z не нужен – я понял, спасибо, но как тогда зашифровать каталок с помощью GPG через консоль? Это все я задаю к тому, что все-таки хочу понять, можно написать небольшой скрипт, шифрующий заданный каталог, и дешифрующий его при подключении флешки, на которой находится нужный кейфайл. т.е. можно же сгенерировать отдельный ключ под это дело,скрипт будет постоянно мониторить подключенные устройства на предмет наличия кейфайла. Или глупая затея?
комментариев: 11558 документов: 1036 редакций: 4118
Вы гвозди тоже пассатижами забиваете? Всё-таки у каждого инструмента своё предназначение.
Бессмысленная.
комментариев: 1079 документов: 58 редакций: 59
Если вы про то, как зашифровать всю директорию для последующей отправки получателю, то
комментариев: 1060 документов: 16 редакций: 32
Лучше так, без промежуточного файла: