"PGP Disk под Linux" / системы шифрования
Существует простая и замечательная программка – PGP Disk, я использую версию 6.0.2i. Знает ли кто-нибудь способы монтирования *.pgd -файлов под Linux ? (хоть под какую-нибудь версию). Сейчас живу на 98-й винде, но про Линукс не раз задумывался. Переезду мешает отсутствие ряда программ, и PGP Disk в их числе. Кто что думает по этому поводу ?
комментариев: 9796 документов: 488 редакций: 5664
В 2.4 это было так:
KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
У вас два варианта: или взять исходники дистрибутивного ядра подправить Makefile и пересобрать его с полной поддержкой крипто или переходить на ядро с kernel.org.
Если скрипту не требуются исходники (в чем я сомневаюсь) можете удалить кусок проверки версии ядра.
Также я откровенно говоря сомневаюсь, что программа будет корректно работать на вашем "ванильном" аэспэшном ядре.
Мне лично кажется использование Truecrypt под Linux неоправданным решением.
Можно использовать стандартные средства монтирования с шифрованием через dmcrypt/losetup, а Truecrypt, как я понимаю, только служит оболочкой к ним.
С помощью него вы можете открыть шифроконтейнеры в win (вот там он наверное более уместен), а под Lin – это сомнительное удобство для необученных пользователей. Тем более, что проблем с установкой crypto-функций он не решает.
Проще один раз и надолго выучить синтаксис пары комманд, зато все будет надежнее. А то в один не очень прекрасный день окажется, что ядро или sysutils у вас изменились, а truecrypt с новыми версиями временно не работает.
А я ведь предупреждал!
комментариев: 9796 документов: 488 редакций: 5664
И положите исходники ядра в /usr/src/linux, а то что у вас эта директория девственно чистая, как будто в ней ядро еще ни разу не компиляли?
Или ASP рекомендует исходники для этого дела засовывать в более нестандартное место? ;-)
комментариев: 5 документов: 0 редакций: 0
В конце концов мне порекомендовали запостить описание своей проблемы на http://asplinux.net/modules/ne.....opic_id=654&forum=54, что и было сделано (увидите там пост от Constаntine). Сказали, что будут пинать по этому поводу разработчиков. Ждем-с :))
Насчет целесообразности использования TC под Линух: если бы не приходилось работать под форточками, рабтоал бы с зашифрованными разделами. Но, т.к., похоже, нет под Вынь средств работы с крипторазделами Линуха, ТС – самый подходящий выбор.
Если такие средства есть (нормальные, адекватные) – плз ссылки.
М.б. кто-нибудь пнет разработчиков ТС на этот счет? Чтобы встроили также и поддержку подобного? Я не смогу (пока :)), т.к. не знаю аглицкий, да и не программер (вдруг предложат самому реализовать этот модуль :).
комментариев: 9796 документов: 488 редакций: 5664
В Linux вы можете работь с контейнерами и разделами средствами самой ОС (crypto-ядро+sysutils+FAT32).
TrueCrypt под Linux для этого вам не нужен. Он, насколько я понимаю, лишь оболочка для всего этого
(или дает какие-то дополнительные сомнительные возможности?)
А то что вы насоздаете в шифрованном виде под Linux, то можете открывать в Windows при
помощи виндового Truecrypt или FreeOTFE.
Так надежнее. И по-моему даже проще.
В вашем дистрибутиве в ядре включена по умолчанию поддержка crypto? Что у вас показывает комманда cat /proc/crypto ?
комментариев: 5 документов: 0 редакций: 0
[root@localhost /]# cat /proc/crypto
name: sha1
module: kernel
type: digest
blocksize: 64
digestsize: 20
name: md5
module: md5
type: digest
blocksize: 64
digestsize: 16
Из-под форточек с помощью ТС можно открывать зашифрованные (crypto-ядро) разделы? Есди да, то в таком случае ТС действительно не нужен...
комментариев: 5 документов: 0 редакций: 0
Замечу что TC работает только с собственными контейнерами, FreeOTFE понимает как контейнеры в своем формате так и dm-crypt/LUKS
FreeOTFE имеет модульную архитектуру и создан на основе библиотеки компонет. В документации упомянут компонент OTFETrueCrypt, возможно планируется реализация поддержка TC (кто разбирается в Delphi ?)
комментариев: 9796 документов: 488 редакций: 5664
Я просто не знал, что в ядре конкретно вашего дистра по умолчанию поддержка шифров отключена, включены только хэши, хотя и предполагал, что это так. Все-таки для экспериментов с криптографией советую пользоваться оригинальным ядром и самому компилировать с поддержкой нужных опций.
комментариев: 5 документов: 0 редакций: 0
:)) Теперь надо разбираться со встроенным. Но это уже к саппорту...
Скажите, при управлении правами доступа для разных пользователей какой хеш используется? Насколько мне известно для этих целей используется gpg или нет?
Где тогда используется md5, который уже основательно взломан?
комментариев: 9796 документов: 488 редакций: 5664
Почти везде. В /etc/shadow например, а в управлении в пакетах совместно с SHA-1. И в ближайшее время менять никто ничего не собирается.
Для вычисления HMAC для IPSEC – а именно для этого он включен в ядре его тоже менять в ближайшее время не будут.
В большинстве случаев атаки на нахождение коллизий здесь не практичны, проверенных альтернатив нет.
Вы хотите сказать, что использование md5 в Linux в большинстве случаев не угрожает безопасности?
комментариев: 9796 документов: 488 редакций: 5664
Пока нет общепринятого стойкого хэша менять в Линуксе ничего не будут. В большинстве случаев случаев это действительно не угрожает безопасности.
Единственное, что потенциально опасно – это md5 суммы пакетов. Но они заносятся в список определенного формата, от списков считается md5 и sha-1 и это подписывается ключом gpg. Пока неизвестен способ подменить что-то так, чтобы не нарушить эту схему, хотя здесь уже следовало бы отказаться от md5 побыстрее.
комментариев: 1515 документов: 44 редакций: 5786
Однозначно посоветуем GELI. Оно более здоровое, более функциональное, и содержит меньше _потенциальных_ уязвимостей. Для надёжности от некоторых потенциально возможных со стороны АНБ атак рекомендуется пользоваться двойной аутентификацией в GELI (там надо ещё шифровать "соль пароля" или некоторые спецфайлы для раздела – не помню) отдельным gpg-ключом, котолрый хранить раздельно с самой шифруемой информацией, например, на флэшке.
В NetBSD не плохая система – CGD.
OpenBSD пока в сильном пролёте по алгоритмамв шифровании дисков – они уязвимы для ряда потенциальных атак и очень негибки. Аналога CGD в современных версиях open нет :(((
комментариев: 1515 документов: 44 редакций: 5786
1. Вопрос про использовании md5 зависит от дистрибутива. В Gentoo Linux, как одном из наиболее профессиональных, никаких дефолтов в этом плане нет, насколько мнеизвестно: выбираете сами какой хеширующий алгоритм вам лучше использовать. В частности, у меня при установке NetBSD также предлагался выбор для master.passwd. Я выбрал sha-1.
2. А какая разница собственно что там стоит? Обычный пользователь не имеет прав рута. И прочитать тот файл не сможет. Если же пользователь получит эскалацию прав до рута, то единственной целью декодинг passwd будет иметь атаку с помощью узнанных паролй на другие серверы. Если же ваш диск изымут, то права доступа не имеют никакого смысла, как и то что там в passwd. Вопрос будет только в одном: что у вас лежит на криптофс, в чём при условии разных паролей passwd не помощник.
3. md5 не взломан. Просто приведены примеры коллизий. Но для подделки вам нужно не просто коллизию (например для подделки md5 какого-либо пакета с программой), вам нужно уметь сделать нужную вам программу с полезным кодом, дополненную мусором, такую, чтоб md5 её совпадал с md5 исходной программы. А этого делать не умеют :)
4. gpg используется для шифрования отдельных файлов и сообщений, особенно пересылаемых кому-либо, где и проявляется вся суть идеологии с _асимметричным_ шифрованием.