id: Гость   вход   регистрация
текущее время 16:13 23/02/2020
Автор темы: unknown, тема открыта 04/04/2010 15:35 Печать
Категории: разное, сообщество, офф-топик
https://www.pgpru.com/Форум/Офф-топик/УведомлениеяОСменеКлюча
создать
просмотр
ссылки

2010-07-26 истекает неоднократно продлеваемый срок действия моего "красно-коричневого" ключа 4BD12C40.


Не дожидаясь этой даты в ближайшее время мой ключ на форуме будет 80585959, а цвет отображения выходит фиолетово-серый :)


Полный отпечаток:
EE1E 6772 92A7 F9F1 F1DE 326B 9153 691B 8058 5959


Можно скачать с серверов.


Ключ основной подписи в формате OpenPGP DSA3 3072 бита, вполне согласуется с рекомендациями криптографов вывести 1024-битные ключи из обращения в 2010 году.
Подписи сообщений будут использовать хэш SHA-512.


В выборе такого ключа есть некоторая избыточность в ущерб совместимости и возможным багами в реализации нововведений, это больше подходит для экспериментов.


Пока дата действия ключа до 2012-03-06, дальше будет продлеваться по мере надобности, но поскольку ожидается внедрение массы новых стандартов на хэши, асимметрику и пр., то возможно и этот ключ будет действителен недолгое время.


 
На страницу: 1, 2 След.
Комментарии
— Гость (07/04/2010 08:18, исправлен 07/04/2010 09:49)   <#>

Не любит административная http-прокси серверы ключей, поэтому пришлось взять отсюда. Однако, на этом сюрпризы не кончились:
Недолгое "вр". Отображаемый текст отличается от подписанного? Или это тонкий side-эффект от перекодировки из utf-8 в koi8-r? Очень странно. И почему сообщение о подписи есть в начале текста и в середине, хотя обычно идёт только в конце? Значит ли это, что не весь предоставляемый текст подписан ключом? Если да, то почему сайт показывает, что подписано якобы всё сообщение? Вот ещё для диагностики:

— Гость (07/04/2010 08:27, исправлен 07/04/2010 09:50)   <#>
И почему сообщение о подписи есть в начале текста и в середине, хотя обычно идёт только в конце?

Имелась в виду вот эта команда (хотя, вероятно, это тонкий эффект на пайпах):

— unknown (07/04/2010 09:48, исправлен 07/04/2010 10:10)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Выкладывалось именно через тот самый http-proxy, но есть дополнительные хитрости: опции broken-http-proxy и принудительный таймаут на 10 мин.


Там не подписан только заголовок темы, но при сохранении файла это видно как отдельный текст перед подписью. При отображении сообщения в форуме этот заголовок и не появляется.


М. б. команда называется iconv?


При её работе действительно возникали глюки при перекодировании именно при работе с utf-8.


Судя по тому, что сообщение "перебивает текст", возможно сначала gnupg проверяет RSA-подпись подлюча ID 42065DBD и только спустя время успевает сверить правильность того, что этот подключ правильно подписан основным ключом 4BD12C40.


Кстати, настоятельно рекомендую при расшифровке текста в консоли перенаправлять его в файл и затем смотреть просмотрщиком (достаточно через less), чтобы от кого-нибудь не пришли какие-нибудь странные комбинации символов, которые случайно или намеренно портят вывод команды. Т.е. при отдельном просмотре начала вывода, а затем текста таких глюков быть не должно и будете уверены, что не задействована какая-нибудь неизвестная уязвимость с хитрым форматированием. Хотя возможно неудобно два раза набирать несколько разные команды.


Представляю, какие будут глюки при использовании DSA-3, если ещё UTF-8 плохо обрабатывается во многих системах и утилитах :-(


P. S. вырезайте собаку из мэйлов.

— Гость (12/04/2010 00:09)   <#>
Выкладывалось именно через тот самый http-proxy, но есть дополнительные хитрости: опции broken-http-proxy и принудительный таймаут на 10 мин.
У меня когда-то работало и без хитростей. Выше был тест без Tor'а, вот с Tor'ом:
С опциями играться пока лениво.

М. б. команда называется iconv?
Да, конечно, просто когда правил алиасы в командах на общепринятые, ошибся :=)

Кстати, настоятельно рекомендую при расшифровке текста в консоли перенаправлять его в файл и затем смотреть просмотрщиком (достаточно через less), чтобы от кого-нибудь не пришли какие-нибудь странные комбинации символов, которые случайно или намеренно портят вывод команды. Т.е. при отдельном просмотре начала вывода, а затем текста таких глюков быть не должно
Тогда глюк "исчезнет", т.к. текст самого сообщения и проверка подписи идут в разные потоки. Можно было бы воспользоваться стандартным трюком с перенаправлением потоков типа 1>&2 2>/path/to/file, но там в команде 2 пайпа, и эффект в консольном выводе, видимо, возникает из-за того, что часть попадает от 1го пайпа, а часть от второго, в то время как перенаправление работает только с текущим потоком. Можно поиграться поставив перенаправления на обоих потоках, но уже лениво.

P. S. вырезайте собаку из мэйлов.
Извиняюсь, не подумал.
— unknown (12/04/2010 13:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
— Гость (12/04/2010 20:07)   <#>
На 8118 – privoxy, которая непосредственно смотрит в инет (Tor'а нет), при этом авторизация на административной http-прокси происходит методом Basic путём включения в файл user.action строчки
где строка X... X получается командой
(В Linux-консли надо как-то по-другому вычислять X... X). В настройках браузера при этом прописывается IP:порт для http и https-проксей. Короче, пространство для программы "почему не работать" широкое, но в целом большая часть программ дружат с такой настройкой.
— Гость (23/09/2013 12:41)   <#>

Заметил, что в вашей связке был временный RSA-подключ для подписи, созданный на несколько месяцев. К чему бы это?
— unknown (23/09/2013 15:05, исправлен 23/09/2013 15:07)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Я и сам не помню :) Одно время была идея регулярно использовать кратковременные подключи, чтобы гипотетический противник мог успевать поломать только главный ключ, которым подписываются подключи, что для него было бы более заметно и менее применимо в попытках вмешаться в переписку.

— Гость (23/09/2013 18:04)   <#>
Unknown, а чем обусловлен ваш выбор для главного сертифицирующего ключа? Почему именно DSA, а не RSA? Чем, по-вашему, RSA-4096 хуже для подписи?
— Гость (23/09/2013 18:15)   <#>

Хм... каскад перестраховочная криптография?? ;)
— SATtva (23/09/2013 18:18)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4092
Время жизни ключа — общепринятый, легко формализуемый параметр.
— unknown (24/09/2013 10:26, исправлен 24/09/2013 10:27)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Я где-то здесь уже отвечал, что выбрал тот вариант, который хуже и не советовал мой выбор повторять.
На тот момент в стабильной ветке Debian в GnuPG не было поддержки RSA-4096 для подписи главного ключа, а поддержка DSA-3072 и больших хэшей SHA-2 уже была. Хотя, может были ещё какие проблемы, уже не помню.

— Гость (25/09/2013 00:22)   <#>

А если бы такой ключ был сгенерирован на другой системе и импортирован в Debian, GnuPG поняло бы его? Если сделать все три ключа (главный [C], подключ шифрования [E] и подключ подписи [S]) типом RSA-4096, насколько вероятно возникновение несовместимости с немного устаревшими версиями GnuPG (ну там года 3 назад вышедшими)? Они будут мой ключ понимать?
— SATtva (25/09/2013 10:16)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4092
Будут. Сомневаюсь, что проблемы возникнут даже с версиями 5-8-летней давности.
— Гость (18/10/2013 18:25)   <#>

Кажется, я когда-то видел на сайте статью с рекомендациями по выбору типов ключей, но не могу нагуглить. Часть аргументов уже озвучивалась и разобросана по сайту, но было бы удобно, если б кто-то составил таблицу плюсов и минусов каждого алгоритма. Например, RSA проще в реализации (а поэтому меньше вероятность ошибки) и более стоек при уязвимых ГСЧ, но уязвим к реализации паддинга. DSA сразу был свободным, в отличие от RSA, но уязвим к плохому ГСЧ, что теоретически позволяет восстановить приватный ключ. Т.е. какие-то такие аргументы хотелось бы увидеть, особенно с учётом последних новостей.

Как-то возник разговор на тему Elgamal vs RSA для шифрования. Аргументы против RSA были:
  1. Алгоритм был когда-то запатентован, поэтому не так хорошо анализировался сообществом, Elgamal же появился как свободный сразу.
  2. Доказано, что Elgamal не слабее RSA. Обратное не доказано (речь о сводимости одной трудной задачи к другой).
  3. Сложность реализации RSA и Elgamal примерно одинаковая.
  4. DSA+Elgamal долгое время были дефолтным выбором в GnuPG при генерации ключей.
  5. Асимметрика на дискретном логарифме появилась лишь чуть-чуть позже RSA, поэтому нельзя сказать, что дискретный алгоритм сильно хуже проанализирован сообществом.

Насколько эти аргументы ошибочные? Есть ли какие-то веские аргументы в пользу выбора RSA для шифрования?
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3