id: Гость   вход   регистрация
текущее время 03:04 20/09/2019
Автор темы: Гость, тема открыта 17/12/2010 17:00 Печать
Категории: анонимность, инфобезопасность, политика
http://www.pgpru.com/Форум/РаботаСGnuPG/GPGВНедружественнойСреде
создать
просмотр
ссылки

GPG в недружественной среде

Здравствуйте!
Вопрос: Имеет ли возможность отправитель данных узнать сессионный ключ в самом банальном случае
gpg -e -r someoneelse somedata
с целью уличить получателя gpg сообщения в нечестности, если он "отказывается" расшифровывать ваше сообщение, под предлогом "испорченности сообщения".
Спасибо!


 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— SATtva (17/12/2010 17:12)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Если сообщение было зашифровано только для -r someoneelse — нет. Если же оно было зашифровано и ключом отправителя (опция default-recipient-self в gpg.conf), то возможно:

— Александр (17/12/2010 18:16)   <#>
Спасибо,
К сожалению, такой вариант не подходит, так как в данном gpg используется как анонимизатор. Чуть подробнее: хочется придумать процедуру апелляции для системы анонимного опроса мнений, построенной
на стандартных функциях gpg. Нежелательна генерация нового ключа исключительно с целью пересылки единственного сообщения, к тому же это невозможно сделать в batch-mode.
Упрощенно система выглядит следующим образом:
Отправитель берет 2 публичных ключа: key1, key2, составляет сообщение
[[[message]crypted_key2]crypted_key1]signed_user
и отправляет на host1.
host1 аккумулирует, авторизует, расшифровывает и передает набор сообщений от всех пользователей на host2
{[message]crypted_key2}->host2.
host2 расшифровывает и производит подсчет.
Требуется процедура апелляции, на случай если host1 или host2 отказываются расшифровать сообщение.
Ограничения на систему:
Максимальная простота использования для отправителей (*).

Поэтому следующий вопрос:
правильно ли я понимаю, что Symmetric Ciphers, не работают в batch mode?
как написать скрипт который скормит им passphrases, или их нужно обязательно вводить вручную?
(что нежелательно по причине *)
— SATtva (17/12/2010 18:28, исправлен 17/12/2010 18:28)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Нежелательна генерация нового ключа исключительно с целью пересылки единственного сообщения, к тому же это невозможно сделать в batch-mode.

Вторая половина фразы не соответствует действительности.


правильно ли я понимаю, что Symmetric Ciphers, не работают в batch mode?
как написать скрипт который скормит им passphrases, или их нужно обязательно вводить вручную?

Целых три варианта (помимо ручного ввода):


— Александр (17/12/2010 19:26)   <#>
Огромное спасибо! Типа тупо пропустил при чтении.
Тогда еще один вопрос, состоящий из двух:
1. для некоторого сообщества, регулярно участвующих в опросах, хочется поставить "локальный"
кей-сервер с веб интерфейсом, то есть такой в который авторизованные ключи можно было бы добавлять руками, а возвращать через веб. Другими словами как сделать видимым public-key-ring на host1 через веб? Наверное, есть удобная реализация?
2. Насколько скомпрометирована (идентифицируема) будет личность отправителя если сообщение закриптовано комбинацией опций
gpg -e --default-recipient-self --hidden-recipient key2 message
при условии доступности информации с public-key-ring
— SATtva (17/12/2010 20:26, исправлен 17/12/2010 20:28)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
для некоторого сообщества, регулярно участвующих в опросах, хочется поставить "локальный" кей-сервер с веб интерфейсом, то есть такой в который авторизованные ключи можно было бы добавлять руками, а возвращать через веб. Другими словами как сделать видимым public-key-ring на host1 через веб? Наверное, есть удобная реализация?

Либо полноценный SKS, либо писать собственную веб-морду с бэк-эндом в виде GPG (примерно как сделано на нашем сайте). Вероятно, второй вариант Вам больше подойдёт.


Насколько скомпрометирована (идентифицируема) будет личность отправителя если сообщение закриптовано комбинацией опций
gpg -e --default-recipient-self --hidden-recipient key2 message
при условии доступности информации с public-key-ring

Она будет скомпрометирована полностью, т.к. --default-recipient-self впишет в пакет сообщения его собственный keyID. Вместо --default-recipient-self используйте в данном случае --hidden-encrypt-to senderKeyID.


Вообще в Вашем случае желательно проверять, какие метаданные утекают через поля OpenPGP-пакетов. /Сервисы/PacketDump Вам в помощь.

— unknown (17/12/2010 21:13)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Помните как криптографы международной криптологической ассоциации спорили из-за Java в своей системе анонимного голосования? Лучшие, так сказать, умы в области криптографии долго пытались построить эту систему для своих нужд. А недавно оказалось, что эта система Helios дырява на уровне протокола. И что они парятся? Может им просто надо gpg посоветовать и будет всё также легко?
— Александр (17/12/2010 23:50)   <#>
По 1му понятно, по второму пункту понял, что он мне не подходит, так как если скомпрометирован user's private key, то скомпрометировано и его сообщение, что не так в случае симметричного криптования.

Незнакомцу, кажется в Вашей реплике сквозит сарказм, но все равно спасибо за ссылки. Если же Вы к тому же потрудились прочитать, что написано по второй, то должны были поразиться необычайной глубине криптографической мысли авторов, которая позволила им обойти ими же идентифицированную проблему дупликатов голосов:
The ballots replayed in this attack can be identified by checking for duplicates, and these ballots can be rejected.
— Гость (18/12/2010 00:53)   <#>
Так это просто фикс.
— Гость (18/12/2010 00:58)   <#>
Если сообщение было зашифровано только для -r someoneelse — нет.
SATtva, вам не трудно было бы пояснить почему нет? Давайте посмотрим на схематическом уровне как это работает: отправитель генерит случайный пароль для AES (по умолчанию), оным сообщение шифруется, затем сам пароль шифруется публичным ключом адресата. Теперь результат шифротекст, соответствующий как тому паролю, так и сообщению, вместе упаковываются в PGP-формат и отсылаются. И кто ж теперь запретит получателю разгласить тот самый пароль, раз он его сам же и генерит? Если я не ошибаюсь, то он и есть "сессионный ключ", не так ли?
— Гость (18/12/2010 01:00)   <#>
s/запретит получателю/запретит отправителю/
— SATtva (18/12/2010 10:38)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Давайте посмотрим на схематическом уровне как это работает: отправитель генерит случайный пароль для AES (по умолчанию), оным сообщение шифруется, затем сам пароль шифруется публичным ключом адресата.

Генерируется сеансовый ключ, который зашифровывается открытым ключом получателя. Подумайте, каким образом отправитель теперь может восстановить этот сеансовый ключ, не имея доступа к закрытому ключу получателя? Мы же говорим об асимметричном шифровании, это односторонняя функция.
— Гость (18/12/2010 22:44)   <#>
Генерируется сеансовый ключ, который зашифровывается открытым ключом получателя. Подумайте, каким образом отправитель теперь может восстановить этот сеансовый ключ, не имея доступа к закрытому ключу получателя?
А восстанавливать и не надо — достаточно вовремя слить. Раз я, отправитель, сам генерирую сеансовый ключ, я его могу куда надо сохранить перед тем как шифровать открытым ключом адресата. Затем этот сеансовый ключ предъявляется кому надо, и он читает PGP-шифрованное сообщение, не имея ключа адресата. Профит?
— SATtva (18/12/2010 22:58)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Если модифицировать GPG — да. Но, как я понял, задача не допускает такого решения, нужна именно стандартная реализация.
— Гость (18/12/2010 23:08)   <#>
Понятно. Я имел в виду, что сам стандарт (как протокол) это делать позволяет, ну а реализация — вопрос вторичный, ибо важен концепт.
— Гость (19/12/2010 02:41)   <#>
GPG в недружественной среде

Вопрос: Имеет ли возможность отправитель данных узнать сессионный ключ в самом банальном случае gpg -e -r someoneelse somedata с целью уличить получателя gpg сообщения в нечестности, если он "отказывается" расшифровывать ваше сообщение, под предлогом "испорченности сообщения".

Ну вот никто как бы не мешает этому самому "недружественному отправителю данных" пропатчить свою gpg так, чтобы всегда иметь на руках сессионный ключ. Получатель данных (адресат) при этом ничего даже не заподозрит (стандарт будет полностью соблюдён), пока в момент X отправитель ВНЕЗАПНО не предъявит сессионный ключ.

P.S.: Такой ответ, имхо, уточняет SATtva'овский, если я правильно тут всех понял.
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3