РегистрацияШифрованные файловые системы
Здравствуйте! Праквильно я понимаю, что бесплатных/опенсорсных аналогов e-nigma или cipherwall.com окромя tahoe нету? И чем фринет отличается от tahoe? Хочецца что-то типа энигмы но опенсорсное и с установкой хранилищ данных на своих серверах, лучше не распределенное как tahoe/freenet(в целях увеличения скорости и независимости от присутсвия в сети клиентов)
комментариев: 11558 документов: 1036 редакций: 4118
Freenet в отличие от Tahoe — это система публикации. Данные во Freenet хранятся лишь до тех пор, пока на них остаётся спрос. Tahoe — это файловая система (хотя и с возможностью коллективного доступа). Цели у систем разные, разные и характеристики (пропускная способность, скажем).
Ну так поставьте свой Linux-сервер, зашифруйте файловую систему и подключайтесь к ней по NFS или даже FTP.
Я просто не очень шарю в этом. В линухах и пр. При таком решении будут удовлетворяться следующие требования?:
-данные зашифрованы и люди, обслуживающие сервер не имеют доступа к ним.
-при доступе к данным происходит шифрование/дешифрование на лету(как в трукрипте) на стороне клиента.(Если это будет на стороне сервера. то серверные работники смогут получить к ним доступ, правильно?)
-Возможен доступ к данным нескольким людям одновременно на чтение/запись(трукрипт вроде позволяет одновременно только на чтение). Идентификацию пользователей желательно по ключам.
Он бесплатный?
комментариев: 11558 документов: 1036 редакций: 4118
Вы этого в принципе не избежите: хотя бы из ОЗУ, но ключ извлечь они смогут. Например, вот так.
TrueCrypt в серверном режиме не выполняет криптооперации на стороне клиента. Вроде бы в CFS есть такая возможность при работе поверх NFS, но в деталях лень копаться. Все остальные ФС (за исключением Tahoe) выполняют криптооперации только локально на сервере.
Это зависит уже от приложений, осуществляющих доступ к файлам в данной ФС. Если доступ на чтение блокирующий, то читать может только один. А доступ на запись не бывает совместным.
комментариев: 9796 документов: 488 редакций: 5664
Поскольку разработчики кода и держатели сервиса будут одним и тем же лицом в случае обнаружения багов
в коде, о которых они будут узнавать одними из первых,
они будут теоретически иметь время для эксплуатации дырок, собирая уязвимые данные пользователей со своего же сервера, где данные для каждого пользователя храняться обычным способом (централизованно, а не распределённо).
Кому-надо, тот лучше будет использовать общераспространённый и устоявшийся код для работы с любым подходящим сервисом.
Пусть пользователь выберет сам и сервис и код, который больше подходит под его ОС и задачи.
Например encFS over SSHFS.
Решений масса. вот первый подвернувшийся пример.
На счёт возможности групповой работы – вопрос открыт. Ну кому надо, тот может дописать код и толкнуть в открытый проект, неповязанный с конкрентным коммерческим сервисом.
комментариев: 9796 документов: 488 редакций: 5664
Использование этой файловой системы предпочтительнее, чем encFS, она работает напрямую из ядра, а не через FUSE, поэтому быстрее.
Система активно развивается.
http://ecryptfs.sourceforge.net/
в случае cipherwall то сервер скоро будет доступен для скачивания... можно его будет установить где захочется – не обязательно использовать сервер разработчиков
Вы уверены? http://truecrypt.org.ua/node/51
Монтируется на стороне клиента. Значит и операции шифровки/дешифровки там же? Тогда извлекать ключ из ОЗУ на стороне сервера бесполезно и инфа скрыта от серверных работников.
И я так и не понял: в случае с шифрованной файловой системой так же или нет?
Спасибо за ваше терпение
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
А статью читали? Разумеется всё шифрование в cryptFS только на стороне клиента поверх любой другой файловой системы.
Поэтому можно примонтировать любой файловый сервер с помощью файловой системы, которая обеспечивает отображение его файлов
(smbFS, FTPFS, SSHFS), а поверх неё использовать encFS или eCryptFS.
Никакого специального ПО на сервере вообще устанавливать не нужно, поэтому подойдёт любой недоверенный сервис.
Например, можно примонтировать содержимое почтового ящика Google (он ведь большой) с помощью GoogleFS, в смонтированной директории расположить шифрованную часть eCryptFS и качать в Google свои бэкапы, использовать его как файлообменник и т.д. Правда, кажется в последнее время Google пытается вычислить таких халявщиков и бороться с ними. ;-)
Минус этих файловых систем в том, что шифрование реализовано пофайлово, а не в режиме блочного устройства, поэтому владелец сервера может проводить анализ трафика и определять количество, атрибуты, размер закачаных файлов, структуру каталогов.
Для предотвращения изменений файлов на недоверенном сервере, помимо шифрования, клиентом может быть включена опция пофайловой аутентификации, тогда для каждого фала будет сохраняться и его MAC, привязанный к ключу шифрования.
Проект FUSE-encFS вполне законченный, входит в большинство Linux-дистрибутивов, но несколько устаревший и имеющий мало шансов на дальнейшее развитие. Проект eCryptFS включен в мэйнстрим-ядро, имеет поддержку среди крупных компаний (Red Hat) для энтерпрайз-решений, динамично развивается, в т.ч. в сторону поддержки разных стандартов асимметричного шифрования, но всё ещё слишком нов и неразвит (простейшая функция шифрования названий файлов всё ещё не реализована на данный момент, хотя в encFS это было с самого начала).
Так что пока ещё выбор за encFS, но как только в eCryptFS будут стабильно реализованы основные функции, есть смысл переходить на него.
Ещё есть grid добровольцев (делишься своим местом, можешь пользоваться местом остальных), но это сложнее настраивать.