LINUX.ORG.RU

Сгенерированы GnuPG-ключи с одинаковым коротким идентификатором

 , , ,


0

0

Asheesh Laroia разработал инструмент, позволяющий сгенерировать пару совместимых с GnuPG 4096-битных RSA-ключей с наперед заданным коротким (32-битным) идентификатором. Полный отпечаток ключа не совпадает. Процедура занимает три часа на старом ноутбуке. В отличие от старых атак на короткие ID ключей, новая атака создает RSA-ключи с общеупотребительной длиной и произвольным наперед заданным именем владельца.

Исходный код инструмента в открытый доступ не выложен, поскольку это привело бы к наводнению серверов «полудубликатами» ключей влиятельных людей.

Попутно в программе GnuPG обнаружен баг, приводящий к использованию только короткого ID вместо более полного отпечатка (если он известен) при запросе ключа с сервера. Пример: gpg --keyserver pgp.mit.edu --recv-key 0xEC4B033C70096AD1 получает еще и ключ 0x37E1C17570096AD1. При редактировании ключей или проверке подписей, аналогичного бага нет. Планов по выпуску исправленной версии тоже нет.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Исходный код инструмента в открытый доступ не выложен

Ну и зря

Chaser_Andrey ★★★★★ ()

:)

Свежий материальчик для SLOR

vilisvir ★★★★★ ()

Кстати кто в теме, если создать (с помощью модифицированного GPG) ключик 8192 или 16384 бит, и ей подписать им другой ключ с длинной 4096 бит.

Как на второй (4096 бит, но с подписью сделанной ключом нестандартного размера) будут реагировать другие GPG клиенты?
Что подпись проверить они не смогут это понятно, но интересно примут ли они вообще такой (подписанный 8192/16384 битным ключом) мой ключ?

Просто хотелось бы иметь один «сверх надежный» ключик, и уже им подписывать остальные, менее стойкие.

winddos ★★★ ()

как теперь жить?

anonymous ()

Проясните для идиота, теперь нельзя доверять только цифровым подписями, или растшифровать файлы, зашифрованные gnupg теперь так же возможно?

anonymous ()

Планов по выпуску исправленной версии тоже нет.

Ну и как это понимать? Баг вообще не будут исправлять?

power ()
Ответ на: комментарий от metawishmaster

Вторая бага что то может и значит, а первая по сути ничего не значит.
Но позволяет «зафлудить» SKS фейковыми ключами, по сути.

winddos ★★★ ()

Что такое этот короткий ID, и насколько все плохо?

loz ★★★★★ ()
Ответ на: комментарий от anonymous

Просто нужно проверять не только Key ID, но и полновесный отпечаток.

winddos ★★★ ()
Ответ на: комментарий от loz

8636799B
Например, это короткий ID ключа оставленного мной в профиле.

winddos ★★★ ()
Ответ на: комментарий от winddos

ЕМНИП rsa это пара ключей - закрытый чтобы шифровать и подтверждать подлинность и открытый чтобы расшифровывать и проверять подлинность. Так зачем этот короткий ID нужен?

loz ★★★★★ ()
Ответ на: комментарий от loz

Очевидно, этот ID нужен, чтобы получивший шифрованное почтовое сообщение смог слить нужный открытый ключ с привычного ему сервера ключей.
Т.е проблема в том, что злоумышленник может отослать с твоего почтового адреса сообщение которое подписано ключем имеющим такой же ID как и у твоего настоящего ключа.
И если он на сервер ключей адресата положит тоже этот фейковый ключ, то адресат будет думать, что он общается с тобой.
Естественно это не работает если у адресата уже есть твой ключ, который естественно не совпадает с ключем злоумышленника.

winddos ★★★ ()

Вроде прояснили вопрос, и хорошо, а то от написания новости меня как раз удерживало недопонимание сути)

pianolender ★★★ ()

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

lucentcode ★★★★★ ()
Ответ на: комментарий от metawishmaster

Пришло время тем, кто орет решето взять в руки вим, емакс и включить мозг.

AiFiLTr0 ★★★★★ ()
Ответ на: комментарий от anonymous

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

Лично я в своих приложениях всегда использую только полный идентификатор (fingerprint) чего и вам советую.

UncleAndy ★★★ ()

«Как и предполагалось, короткий ID слишком короток». Кто бы сомневался.

sv75 ★★★★★ ()

Сгенерированы GnuPG-ключи

а вот обновленную версию стоило б выпустить

kychyk7 ()
Ответ на: комментарий от lucentcode

Уязвимы опять люди, которые смотрят только на short-id. Ну и поведение по обновлению ключей и поиску. В случае проверки ключа по fingerprint-у всё работает отлично, ни подпись, ни шифрование не скомпрометированы.

zink ★★ ()
Ответ на: комментарий от anonymous

доверять «стандартной» крипте вообще нельзя.

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

ckotinko ☆☆☆ ()

Вывод - короткие идентификаторы не нужны. Еще бы, 32 бита... кто додумался?

segfault ★★★★★ ()
Ответ на: комментарий от ckotinko

доверять «стандартной» крипте вообще нельзя.

У тебя есть альтернативы?

жаку патарану к примеру много лет тупо не давали напечатать свою книгу.

Погуглил, увидел кучу желтых статей с его именем и ничего более. По-моему, его тупо кто-то попиарил.

segfault ★★★★★ ()

Черт, хорошо что я не пользуюсь всеми этими гнупг.

Ok ()
Ответ на: комментарий от power

Ну и как это понимать? Баг вообще не будут исправлять?

Прочти внимательнее. Это не программный баг, а идейный. Его фикс сводится разве что к выпиливанию short ID как понятия.

segfault ★★★★★ ()
Ответ на: комментарий от Ok

А какая есть хорошая альтернатива ассиметричного шифрования совмещённого с понятием WoT ?

zink ★★ ()

Исходный код инструмента в открытый доступ не выложен, поскольку это привело бы к наводнению серверов «полудубликатами» ключей влиятельных людей.

Специалисты по ИБ этих сервисов - такие специалисты...

segfault ★★★★★ ()
Ответ на: комментарий от zink

совмещённого с понятием WoT

World of Tanks? Web of Trust? What???

segfault ★★★★★ ()
Ответ на: комментарий от segfault

GPG и World of Tanks это конечно было бы вин. Не знаю как, но было бы. Контекст-то парсить можно. Web of trust и подобные сети, где доверие к ключу определяется по цепочке доверенных (выбранных самим пользователем) людей.

zink ★★ ()
Ответ на: комментарий от zink

Ок, теперь хотелось бы знать, какими особенностями должен обладать криптоалгоритм, чтобы быть «WoT-совместимым»?

segfault ★★★★★ ()
Ответ на: комментарий от winddos

И если он на сервер ключей адресата положит тоже этот фейковый ключ, то адресат будет думать, что он общается с тобой.

Только если адресат сравнивает ключи по 32-битовому ID (который представляет собой нижние 32 бита 160-битового отпечатка).

liberte ()
Ответ на: комментарий от liberte

Адресат их может вообще не сравнивать, увы...
Вопрос в том, есть ли в софте дополнительная проверка по полному отпечатку.

winddos ★★★ ()
Ответ на: комментарий от segfault

Ну у меня есть подозрение, что такой идентификатор придумали использовать в момент создания оригинального PGP, т.е в то время когда «32 бита хватит всем».

Мы все куда дольше будет отхлебывать из за не предусмотрительности разработчиков IPv4.
Так что идентификаторы в GPG это не самое эпичное решение ушедших годов.

winddos ★★★ ()
Ответ на: комментарий от winddos

Ну, от того, что «бывает и хуже», никому не легче. Да, тот же фейл с 56-битным ключом ДЕС куда поэпичнее будет.

segfault ★★★★★ ()
Ответ на: комментарий от segfault

Ну ты ведь понимаешь, что люди которые используют шифрование привыкли мериться с некоторыми его ограничениями и сопутствующими проблемами.
Я уверен что если примут новый стандарт, то все шустренько на него перескочат, просто нужен повод.
Это ведь не виндузятников с IE6 пересаживать.

winddos ★★★ ()
Ответ на: комментарий от winddos

люди которые используют шифрование привыкли мериться с некоторыми его ограничениями и сопутствующими проблемами.

Да, но когда эти проблемы касаются безопасности - это уже ни в какие ворот не лезет!

segfault ★★★★★ ()
Ответ на: комментарий от segfault

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

Поэтому этих людей будет не (!!) сложно перевести на новый протокол, т.к люди (или их работодатели, в случае всего все ещё жестче) беспокоятся о своей безопасности.

winddos ★★★ ()

Эмм. По ссылке не ходил, в вопросе не шарю. Но, тем не менее вопрос. Решето?

Delirium_veritas ()
Ответ на: комментарий от winddos

Я уверен что если примут новый стандарт, то все шустренько на него перескочат,

Прочёл как «подрочат».

anonymous ()
Ответ на: комментарий от Delirium_veritas

Если ты не юзер GPG, то тебя это никак не касается.
Вроде как в репозиториях уже очень и очень давно не используются короткие идентификаторы, по крайней мере в PPA убунты.

winddos ★★★ ()
Ответ на: комментарий от segfault

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

zink ★★ ()
Ответ на: комментарий от zink

Так в том-то и дело, что проверка подписи пакетов в Ubuntu/Debian построена на short-id, кажется в arch тоже.

lucentcode ★★★★★ ()
Ответ на: комментарий от lucentcode

проверка подписи пакетов в Ubuntu/Debian построена на short-id

Это как?!

MrKooll ★★★ ()
Ответ на: комментарий от MrKooll

По short-id менеджер пакетов получает ключ с сервера ключей , и запрашивает добавление его в список доверенных ключей. После этого идёт проверка подписанного данным ключом пакета. Не подписанные пакеты, и пакеты с сомнительной подписью, опасно использовать - они могут содержать трояны, и прочую гадость. Даже пакеты с исходниками могут содержать бэкдор, внедрённый туда левым сопровождающим пакета. Да, PKGBUILD в Arch Linux не зря рекомендуют изучить в текстовом редакторе, а только потом начинать сборку пакета. В нём тоже могут быть инструкции по сборке совсем не того, что вы ожидаете получить. Откуда скачиваются исходники(официальная репа от разработчика ПО, или левак), не качается ли ещё что-то - это можно увидеть только изучая такие файлы. К сожалению, многие используют тот же AUR бездумно. А возможность выдать свой ключ на ключ известного разработчика, это возможность создать пакеты с ПО, которые будут иметь доверие даже у сведущих людей(id то знакомый, как имя и мыло автора).

lucentcode ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.