GnuPg для Delphi
Уважаемые форумчане. Подскажите плиз не видел ли кто на просторах инета компоненты или каких нибуть исходников для реализации (с реализацией) доступа к функциям GnuPG для Дельфи?
Ссылки
[link1] http://www.pgpru.com/comment71157
[link2] http://www.pgpru.com/comment74305
[link3] http://www.gnupg.org/related_software/gpgme/
[link4] https://github.com/Hitwise/gpglib
[link5] http://www.pgpru.com/novosti/2013/vypuskkriptograficheskojjbibliotekilibgcrypt160
[link6] http://en.wikipedia.org/wiki/Hardware_security_module
[link7] http://kuraev.ru/smf/index.php?topic=98973.0
[link8] http://www.pgpru.com/comment72570
[link9] http://www.pgpru.com/comment72850
[link10] http://www.pgpru.com/comment73746
[link11] http://www.netbsd.org/images/NetBSD-old.jpg
[link12] http://www.csmonitor.com/var/ezflow_site/storage/images/media/content/2013/4-27-13-iwo-jima-flag-raising/15650567-2-eng-US/4-27-13-Iwo-Jima-flag-raising_full_600.jpg
[link13] http://mail-index.netbsd.org/netbsd-advocacy/2002/03/13/0010.html
[link14] https://ru.wikipedia.org/wiki/Демон_(программа)
[link15] http://ei.cs.vt.edu/~history/Daemon.html
[link16] http://www.pgpru.com/comment73733
[link17] http://www.pgpru.com/comment76863
Нашел в документации как генерить ключи через файл.
но никак не могу понять что это за команда:
gpg --batch --gen-key foo
[...]
gpg --no-default-keyring --secret-keyring ./foo.sec \
перывая понятно запустили файл описалово и он нам сгенерил ключь. (по доке foo.sec и foo.pub) но вот след. команда не понятно как вообще набирать.
В строчечку. Учитывайте специфику Линукс ;) и пишите с поправкой на Win32.
Ясно. а как
gpg --no-default-keyring --secret-keyring ./foo.sec \
--keyring ./foo.pub --list-secret-keys
/home/wk/work/gnupg-stable/scratch/foo.sec
с поправкой на Винды выглядит?
Господи, да просто указывайте пути, как это принято в Виндоуз, т.е. с именем диска, слэши обратные, а не прямые. А саму команду в одну строчку.
Спасибо.
Та же проблема. Последовал рекомендации[link1], чтобы сгенерить ключ большего размера, чем 4096 бит. Что ни припишу в Key-Usage, ничего не принимает. По ссылке прозрачный намёк на то, что ничего и не должно сработать:
Мне нужно создать главный RSA-ключ с одной-единственной capability — certification. Я правильно понял, что no way, да? Гугл перерыт вдоль и поперёк. Гляньте кто-нибудь в сырцы, действительно ли никак иначе. Ошибка пишется такая:
Перепробовал всё, что приходило в голову: опции с минусами, none, NONE, default, пустое поле. Всё бесполезно. Не принимает.
У уже сгенерированного ключа capabilities вроде как тоже поменять нельзя. ☹
Кто в GnuPG главный кодер? Можно радикально проголосовать против шифрпанка и быдлокодерства биткоинами? Проект принимает пожертвования[link2]?
http://gnupg.org/misc/donations.html
http://g10code.com/gnupg-donation.html
Все никак не пойму, почему было не сделать GPG в виде динамической библиотеки с соответсвующим интерфейсом??
Загрузил в процесс и пользуешся функциональностью. Зачем все эти запуски с передачей параметров через командную строку.
Доходит до того, что, например, в плагине GPG для Miranda, для шифрования и расшифрования сообщений создается отдельный файл, в него записывается сообщение, запускается GPG с передачей параметров, файл зашифровывается, потом читается оттуда текст, потом файл удаляется. И это все для каждого (!) сообщения.
Почему не подгрузить один раз DLL и вызывать функции, передавая и получая данные?
Зачем этот линукс-стайл с командной строкой в винду то тащить?
Вообще, есть библиотека gpgme[link3], но некоторые XMPP-клиенты (тот же Psi) предпочитают ей не пользоваться. Есть gpglib[link4].
Про libgcrypt[link5] тоже можно вспомнить.
Небезопасно это. Все криптографические операции в этом случае будут выполняться в контексте того же процесса, и он будет иметь доступ к ключам, парольной фразе и т.п.
Файлы делать вообще говоря не обязательно, можно в потоки данные отдавать. Вернее даже нужно.
gpgme всё тот же gnupg в качестве бэкенда использует. Но с ней должно быть проще.
Ничего, что этот процесс изначально имеет доступ к исходным plain-text данным и к расшифрованным, т.к. именно для него выполняется шифрование?
Ничего, потому что компрометация каких-то одних данных — это полбеды, а компрометация секретного ключа — это компрометация вообще всего, что когда-либо кем-либо было зашифровано этим ключом. Уровень урона совершенно разный.
Т.е. по Вашему, например TrueCrypt небезопасно устроен, тем что не использует отдельный процесс для шифрования, а пароли и ключи доступны в его процессе?
Ваша аналогия неверна,
слишком толсто троллите.Я не троллю и аналогия вполне уместная.
1. Если процесс вызывает другой процесс GPG для шифрования и расшифрования определенной информации, то он может так же расшифровать любую другую ранее зашифрованную информацию, зашифрованную этим ключом.
2. Если вызывающий процесс и процесс GPG выполняются с одним уровнем привилегий, то:
А. вызывающий процесс имеет доступ ко всему, к чему имеет доступ GPG, т.е. к его ключам.
Б. вызывающий процесс имеет доступ к памяти процесса GPG
Это имело бы смысл если GPG выполнялся бы в контексе службы и имел повышенные привилегии по отношению к вызывающему процессу.
А по большому счету, это имеет смысл, если шифрующий код и ключи находятся на отдельной изолированной платформе, c ограничением физического доступа, например Hardware Security Module.[link6] Тогда да, есть разграничение доступа и есть в этом смысл. А в текущем варианте это к безопасности отношения не имеет.
Это уже вопросы к среде, в которой это всё исполняется. В любом случае необходимо, чтобы к ключам имел доступ только одно приложение -> т.е. по любому отдельный процесс в любой ОС. И уж конечно, никто не должен иметь возможность читать его память – а это вопрос к ОС.
В версии 2.1 вроде будет ещё архитектурная правка, закрытые ключи будут обрабатываться исключительно gpg-agent.
TC — не сетевое приложение в отличие от GnuPG, которое не только часто вызывается автоматически всякими джабберами и мейлерами, но ещё и обычно используется для расшифрования информации от недоверенных источников. Например, атакующий может затроллить по сети джаббер, найдя ошибку в его коде, а раз джаббер имеет доступ к закрытому ключу, получить и сам ключ. Если GnuPG работает в отдельном процессе, это усложняет жизнь атакующему. Как-то так.
То, о чём пишет sentaus, т.е. изоляции, — стандартная вещь, которая считается архитектурно правильной. Например, в браузере Chrome всё важное вынесли в отдельное ядро. В ядре Linux тоже вроде крипто — отдельный модуль. Это позволяет сделать критическую к безопасности часть кода более компактной, легче анализируемой и более безопасной, при этом контакты нужных модулей с остальным кодом чётко регламентированы. А когда всё вместе без разбору намешано в одну кучу, любая из ошибок во всей массе кода может оказаться фатальной.
Винда головного мозга?
Только в этом причина?
В ТС (и других программах) почему нет этой стандарной вещи. Потому что, если пользователь предоставляет процессу ключ и пароль к нему, значит от этого пользователя бессмысленно изолировать ключ.
Я не в курсе как сервисы называются в линуксах. В винде – это фоновый процесс, работающий в отдельной сессии, обычно с правами system.
Изоляция – это ключи, хранящиеся в токене и шифрование, выполняющееся там же.
Линакс дьявольская ось. И вообще свободное ПО от лукавого[link7].
В винде есть иконки и служба, а в линаксе демоны и зомби.
Исходя из этого легко запоминать термины.
Нет. Я же написал про модульность.
14 пунктов против использования TC: 13[link8]+1[link9]. И ещё:
Основная претензия: TC — это шифрпанк, как ни крути. Зря вы его как хороший пример приводите.
Строго говоря — да, но правильная архитектура позволяет снизить вероятность ошибки, облегчить поиск ошибок и, если они всё же случатся, уменьшить фатальность последствий.
Линуксу далеко до флагмана[link11]. Если кто не в курсе, то оригинал — вот[link12], это американцы водружают флаг в японском Перл Харборе. А вот[link13] винтажный срач 12-летней давности на эту тему. Никакой толерантностью даже не пахнет.
UNIX-демоны были уже в 1963-ем (где была винда и Гейтс в это время?), они придуманы физиками в MIT исходя из физических аналогий, восходящих к демонам Макселла, кои обсуждаются и поныне[link16], но уже в контексте квантовой термодинамики и абсолютных границ на расход энергии при брутфорсе ключей[link17]. Видите, как всё глубоко и тесно связано?
А винда — это просто кусок говна.Службы — это действительно демоны, но иконки не имеют никакого отношения к зависшим в ядре процессам (зомби).
Конечно, такая изоляция лучше, но это не отменяет вышесказанных аргументов.