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

Ну и зря

:)

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

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

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

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

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

странно, не видно криков «ришито» %)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну и чо? P_P

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

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

Пичаль пичальная...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дебианокапец?

enlarge your key!!!

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

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

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

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

Решето

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

решето

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

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

Это как?!

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