The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск GnuPG 2.2.17 с изменениями для противостояния атаке на серверы ключей

10.07.2019 11:06

Опубликован релиз инструментария GnuPG 2.2.17 (GNU Privacy Guard), совместимого со стандартами OpenPGP (RFC-4880) и S/MIME, и предоставляющего утилиты для шифрования данных, работы с электронными подписями, управления ключами и доступа к публичным хранилищам ключей. Напомним, что ветка GnuPG 2.2 позиционируется как развивающийся выпуск, в котором продолжают добавляться новые возможности, в ветке 2.1 допускаются только корректирующие исправления.

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

Игнорирование сторонних цифровых подписей регулируются опцией "self-sigs-only", которая допускает загрузку для ключей только собственных подписей их создателей. Для восстановления старого поведения в gpg.conf может добавить настройку "keyserver-options no-self-sigs-only,no-import-clean". При этом если в процессе работы фиксируется импортирование числа блоков, которое вызовет переполнение локального хранилища (pubring.kbx), GnuPG вместо вывода ошибки автоматически включает режим игнорирования цифровых подписей ("self-sigs-only,import-clean").

Для обновления ключей c использованием механизма Web Key Directory (WKD) добавлена опция "--locate-external-key", которую можно использовать для пересоздания хранилища сертификатов на основе проверенных открытых ключей. При выполнении операции "--auto-key-retrieve" механизм WKD теперь является более предпочтительным, чем серверы ключей. Суть работы WKD заключается в размещении открытых ключей в web c привязкой к домену, указанному в почтовом адресе. Например, для адреса "[email protected]" ключ может быть загружен через ссылку "https://example.com/.well-known/openpgpkey/hu/183d7d5ab73cfceece9a5594e6039d5a".

  1. Главная ссылка к новости (https://lists.gnupg.org/piperm...)
  2. OpenNews: Разработчики GnuPG предупредили о трудноустранимой атаке на серверы ключей
  3. OpenNews: Выпуск GnuPG 2.2.16
  4. OpenNews: Доступен NeoPG 0.0.6, форк GnuPG 2
  5. OpenNews: В Libgcrypt/GnuPG выявлена уязвимость, позволяющая воссоздать RSA-ключи
  6. OpenNews: Критическая уязвимость в генераторе случайных чисел GnuPG и Libgcrypt
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51067-gnupg
Ключевые слова: gnupg, gpg
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (27) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:27, 10/07/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    вот так весь этот web-of-trust и накрылся женским половым органом.

    "self-sigs-only", ага.

    Интересно, за "атакой" не стояли ли те самые атакованные три разработчика?

     
     
  • 2.3, Аноним (3), 15:11, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В нём и раньше смысла особого не было. Давно пора.
     

  • 1.2, Leo (??), 12:59, 10/07/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    То есть по умолчанию он не загрузит все подписи.. а как посмотреть если на ключе подпись конкретного человека, сертификат которого у меня есть? если я правильно понимаю, то чтобы это посмотреть, нужно включить старое поведение и, выходит, на актакованных уже не проверишь подписал ли кто-то конкретный, так?
     
     
  • 2.28, Аноним (28), 18:08, 04/08/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > а как посмотреть если на ключе подпись конкретного человека, сертификат которого у меня есть?

    gpg --list-keys --with-sig-check

     

  • 1.4, Аноним (4), 15:40, 10/07/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Вот скоты и похерили Gnupg!

    Объясняю что произошло, для тех кто не в теме.

    С помощью серверов ключей можно верифицировать локальное хранилище ключей. Работает оно по такому алгоритму: Вася дал тебе в руки свой публичный ключ, ты ключу Васи веришь и подписываешь его ключ своим ключом; Вася, встретил Вову (не Того, а хорошего) и Вова передал ему свой открытый ключ, Вася верт ключу Вовы и подписывает ключ Вовы; ты с сервера ключей импортирует ключ Вовы, чтобы верифицировать подписанную ключом Вовы прогу или зашифрованное к тебе письмо.... Так вот, импортированный ключ Вовы у тебя не доверительный, ты Вову не встречал и он тебе свой ключ не давал. Есть в gpg серверов такая киллер фича, как проверка базы доверительных ключей:

    gpg --check-trustdb

    Именно с помощью верификации базы доверительных ключей, ввиду того, что ты подписал ключ Васи, а Вася подписал ключ Вовы товарищу майору не удастся подменить при импорте ключ Вовы, а если товарищ майор и предпримет такую попытку (для MitM атаки), то этот факт легко обнаруживается тобой при помощи верификации базы ключей:

    gpg --check-trustdb

    В чем была создана искусственная проблема: максимальное количество подписей одного публичного ключа на серверах - 150 000, а в проге gnupg меньше, что вызвало проблемы только в gnupg. И следовало просто увеличить максимальное количество подписей одного ключа ТОЛЬКО В GNUPG до 150 000, как на серверах.

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

     
     
  • 2.5, пох. (?), 17:01, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну, в принципе, было б чего терять, конечно.

    > Вася, встретил Вову (не Того, а хорошего) и Вова передал ему свой открытый ключ, Вася верит
    > ключу Вовы и подписывает ключ Вовы

    вот в этом и проблема всего этого web-of-shittytrust.
    Вася _возможно_ встречал Вову. Не ты. _Вася_ поверил что Вова - не Тот (или его агент). Не ты. И фиг его знает, не был ли он в тот момент бухой или под веществами. А возможно у Васи давно уже отжали все ключи и пароли, и провернув через мясорубку скормили того  рыбкам, и подписывал вообще уже не он - ты это проверить можешь только при личной встрече.

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

    А по факту доверять можно только и исключительно фингерпринту ключа. Если я уже пять раз расшифровал вовиным ключом вовину подпись, и в полученных исходниках ужасов не оказалось (или оказались но я не заметил) - вероятнее всего и в шестой раз это делать почти безопасно. Если ключ внезапно поменялся - снова начинаем все с самого начала - выясняем, жив ли Вася, точно ли Вову он видел, проверил ли у того паспорт с пропиской, не завербовали ли его с тех пор ФСБ...

    А если этим ключом подписан ключ Пети - мы вообще никаких выводов сделать не можем, потому что даже вовино существование все еще не доказано.

    И относимся к подписанному ключом Пети - как к неподписанному - опять же, до тех пор, пока не наберем статистику - что петей обычно подписано что-то хорошее.

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

     
     
  • 3.8, Аноним (8), 17:59, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А по факту доверять можно только и исключительно фингерпринту ключа. Если я уже пять раз расшифровал вовиным ключом вовину подпись...

    Нет, тупо верить фингепринту нельзя, необходима верификация доверительной базы. Иначе получишь классический MitM в исполнении товарищем майора. Где криптографическая гарантия что у тебя публичный ключ Вовы? Ты 5 раз расшифровал письмо от товарища майора и думаешь что это от Вовы! Только если есть промежуточное звено -Вася, который подписал ключ Вовы и ключ Васи подписан тобою -- есть криптографическая гарантия что ты имеешь публичный ключ Вовы, а не товарища майора.

    > А вот _иерархии_ доверия - в исходном pgp как и во всех его поздних клонах предусмотрено не было...

    Будет иерархия, к главному придет товарищ майор и попросит так, что отказать не получится. Вся соль именно в отсутствии иерархии, когда нагибать майору пару Спиваков смысла нет!

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

    Все что надо сделать в данной системе -- увеличить максимально возможное количество подписей одного ключа. И больше никчему не прикасаться!!!

     
     
  • 4.9, пох. (?), 18:11, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Только если есть промежуточное звено -Вася, который подписал ключ Вовы и ключ Васи подписан
    > тобою -- есть криптографическая гарантия что ты имеешь публичный ключ Вовы, а не товарища майора.

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

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

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

    > Будет иерархия, к главному придет товарищ майор и попросит

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

     
     
  • 5.11, Аноним (8), 18:20, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ни малейшей.

    В первом своём посте описал работу матмодели на трёх пальцах. Это математическая модель и алгоритмы, логических изъянов в ней нет!

    Проблема в твоей голове: майор с паяльником, который кого-то поймал, пытал, узнал пароль секретного ключа и убил... Это проблема милиции, прокуратуры, а не математиков и программистов.

     
     
  • 6.12, пох. (?), 18:28, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну то есть математики-программисты создали совершенно бесполезную в реальном мире модель.

    Потому что если вокруг только единороги пукающие радугой - от кого ты вообще шифруешься? И зачем тебе васина подпись на петином ключе - петя ж клянется мамой, что он петя, как ты можешь ему не верить? (васе ж веришь?)

    А если в мире действует злой волш...товарищмайор, умеющий подделывать подписи - то и имперсонировать условного вову - он тоже прекрасно умеет.

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

    > Это проблема милиции, прокуратуры, а не математиков и программистов.

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

     
     
  • 7.20, Аноним (20), 12:03, 11/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    1. подпись не обязана быть одна, ты можешь например требовать что бы у ключа было 3 подписи от людей которым ты доверяешь
    2. gpg не накладывает ограничения на тип используемой модели, можно вообще отключить web of trust
     
     
  • 8.21, пох. (?), 12:39, 11/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    так блин, не в ограничениях суть - в отсутствии правильных инструментов примерн... текст свёрнут, показать
     
  • 4.17, Аноним (17), 21:09, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я понял, система работает так, что она постоянно проверяет все возможные сертификаты, пока не найдёт лично доверенный. Поправьте, потому что от этого я строю теорию.

    Имея один ключ, который нам нужно проверить, мы должны пробежаться по огромному количеству клиентов, чтобы добежать до своего сертификата. Каждый клиент имеет в свою очередь тоже кучу подписей, и в итоге мы получаем дерево, которое растёт в неприлично быстрых масштабах. Для этого нужно а) много ресурсов б) много памяти. В самом алгоритме недочётов нету, согласен, но мне кажется такая огромная база сертификатов просто бессмысленна на текущий момент времени. На клиентском уровне нужно ограничивать глубину погружения доверия, т.к. это не целесообразно на текущих железках да и просто выглядит утопично, поскольку чем дальше от личного уровня доверия мы отходим, тем меньше качество проверки. Стопяцотый в цепочке Миша может быть реально отбитым и подписывать чё угодно, не спрашивайте, как его ключ подписали, и он может реально подписать своим ключём какого-нибудь Петю с его фирменным .exe, и смысл в такой жёсткой проверке так удалённых людей просто отпадает. Это нужно учитывать при использовании ключей сертификации и банально не засорять всякий шлак, ручное управление тут определённо необходимо. Для менее значимых целей, таких как скачать с гитхаба исходники, вам хватит и проверки исходников на вшивость, ну вы же взрослый человек, сами знаете, куда не надо пальцы совать.

     
     
  • 5.23, Аноним (23), 17:32, 11/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Для этого нужно а) много ресурсов б) много памяти.

    Да ресурсов жрёт...

    Тебе не надо каждый день верифицировать базу! Ты же каждый день новые ключи не добавляшь.

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

    Для повседневной работы с gpg наличие каких либо серверов, интернатов вообще не нужно.

     
  • 5.24, Аноним (23), 17:38, 11/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > На клиентском уровне нужно ограничивать глубину погружения доверия, т.к. это не целесообразно на текущих железках да и просто выглядит утопично, ...

    Не бойся, все работает! Ресурсов вполне хватает. Необходима достаточно большая глубина, чтобы ты с РФ мог верифицировать ключ кого-то с Бразилии или Австралии. Система успешно справлялась на железе 20-летней давности. И если туда спец сильно палок в колёса не вставлять все будет работать нормально.

    ГЛАВНОЕ НЕ ОБНОВЛЯТЬСЯ.

     
  • 3.14, Аноним (17), 20:36, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У вас в самом начале наихудшая ситуация, которую вы только могли придумать, но она вполне решаема, даже уже существующими инструментами. Если вы не доверяете тому, что Вася подписывает этим ключём только реально полезные ключи, то что этот ключ делает в вашей доверительной базе данных? Если Вася подписывает этим ключем всё, что под руку попало, значит данный ключ - недоверительный. ОДНАКО. Ключ, как набор символов, не имеет свойства привязываться к какой-то конкретной личности, следовательно Вася может иметь сколько угодно ключей, включая те, которыми он "по пьяни" Вову не подпишет. Если вы усомнились в действиях Васи, то просто проведите мини-расследование: спросите Васю о Вове, сделайте выводы, свяжитесь с Вовой и спросите о Пете, и т.д. Это если случай реально странный либо если таки в мире установилась абсолютная анонимность, чего, к сожалению, сейчас сделать почти невозможно, с подводной лодки не убежишь.
     
     
  • 4.15, Аноним (17), 20:45, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    P.s.: Короче говоря вы изначально неправильно используете криптографию. Вы должны доверять лицу не по биологическим фактам (гугл кстати уже может рисовать несуществующих людей, не говоря уже о существующих, а отпечатки пальцев скопировать вообще проще простого), а по факту владения секретом. Вы никогда не сможете доверять даже Васе, т.к. Вася может вообще не умеет пользоваться криптоключами, может это кто-то другой назвался Васей и вы ему сливаете все данные, а Вася всё это время был в запое (вы же позволяете себе такие ситуации в примерах :3). Терморектальный брутфорс до сих пор считается самым действенным способом узнать все тайны, так что ваш выбор - доверять человеку, или вообще вести дела одному.
     
  • 4.16, пох. (?), 20:51, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Если вы не доверяете тому, что Вася подписывает этим ключём только реально полезные ключи

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

    > Если Вася подписывает этим ключем всё, что под руку попало, значит данный ключ -
    > недоверительный.

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

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

    Но в pgp и его наследниках эти вещи _не_разделяются_ - ключ либо доверенный, либо нет.

    А учитывая сложившуюся практику использования - подписи по цепочке кем попало чего попало или вон "ключ репозитория поставляется на диске с дистрибутивом, диск? Диск скачал бесплатно без смс" - вся эта игра в web-of-trust давно потеряла смысл.

     
     
  • 5.18, Аноним (17), 21:21, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Смысл она не потеряла, она работает. Просто вы слишком много от неё хотите. Цепь подписей даёт вам возможность автоматически проверить засланность казачка, т.к. конкретно ваш web вашей общей (!) trust подтвердил его подлинность. Однако она не проверяет вашу систему на вшивость, т.к. работает внутри неё. Если случается аномалия, то это звоночек того, что ваша сеть ключей была в каком-то месте скомпроментированна. Выход из этой ситуации банален - отрезать гниющую конечность, откуда выходит аномальная активность. Если Вася подписывает своим секретом то, что он не удосужился проверить - то земля пухом Васе, а не цепочке подписей. Здесь как раз таки должен быть задействован какой-то механизм отзыва своей подписи либо явный способ сообщить, что данный ключ довереннм не является, дабы абсолютно вся сеть не рушилась из-за одной поломки. Ну банально сертификат должен иметь какой-то короткий срок службы либо быть совокупностью критериев, при которых он работает, иначе мы ключём подписываем что-то навсегда.
     
  • 3.19, Crazy Alex (ok), 10:37, 11/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так, вроде же, всегда можно было и управлять уровнем доверия, даваемым подписью конкретного Васи, и рекомендовалось получить как можно больше подписей различных людей? Если у ключа пять подписей, каждой из которых я умеренно доверяю, и я имею основания полагать, что они независимы - то уже с доверием ключу попроще.
     
     
  • 4.22, пох. (?), 12:43, 11/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Так, вроде же, всегда можно было и управлять уровнем доверия, даваемым подписью

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

    ну и откуда они в реальной жизни возьмутся (доверенные, в смысле человеков, а не криптографии)?

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

    по факту их пять тыщ и хз кто все эти люди.

    > и я имею основания полагать, что они независимы - то уже

    независимы - да. Но имеют привычку подписывать что попало - именно потому что "главное - количество".

    левый ключ точно так же подпишут, вообще ничего не проверяя - появился на сервере - подписать, ok.


     
  • 2.6, Xasd (ok), 17:04, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Это умышленное вредительство товарища майора, специально для того чтобы ты не мог через сервера верифицировать импортированный ключ Вовы.

    а если Майор прикрепит 150000 своих подписей на ключ Вовы -- и таким образом исчерпает лимит?

    из-за лимита -- правильных (ожидаемых тобой) подписей уже не будет.

    как ты верифицируешь в этом случае?

    вобщем вся идея себя исчерпала на стадии отсутствия капчи :-)

     
     
  • 3.7, пох. (?), 17:41, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > а если Майор прикрепит 150000 своих подписей на ключ Вовы -- и таким образом исчерпает лимит?

    это только если ты ключ Вовы берешь с public keyserver.
    Вот с тех самых - на нескучном язычке, который его "разработчики", как выяснилось, не вполне понимают, а автор давно рыб кормит (или червяков).

    А если сервер не public - то все становится существенно лучше.

    Ну, в принципе-то, прежнее поведение можно вернуть по желанию. Только делать это, дай угадаю, никто не будет (включая разработчиков debian с их непаблик сервером, ага)

     
  • 3.10, Аноним (8), 18:12, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > таким образом исчерпает лимит?

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

    РЕШЕНИЕ: увеличить количество доверительных подписей одного ключа в клиентской программ gnupg.

    Когда число доверительных подписей одного ключа достигнет 150000 - увеличил его до 200000 и едем далее. Матмодель и алгоритмы менять нельзя.

     
     
  • 4.13, пох. (?), 18:32, 10/07/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > РЕШЕНИЕ: увеличить количество доверительных подписей одного ключа в клиентской программ
    > gnupg.

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

    > Матмодель и алгоритмы менять нельзя.

    так точно, товарищ майор! И сомневаться в адекватности тех кто так говорит - тоже нельзя!

     
     
  • 5.25, Аноним (25), 17:44, 11/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Последние 10000 обработанных подписей от товарищмайора (правдоподобность которых составляет 0 целых Х десятых (потому, что англицкими учонымы-архыолыгамы были найдены останки Васи и Вовы)) не добавили к доверию ни грамма! Удалить эти подписи (и не доверять им всегда (по фингер-принту)) - ОК!
    Тут только одна кнопка, с надписью "ОК!" (что бы у пользователя голова не болела).

    Тому, кому так необходимо, оставить эти подозрительные (или нет) подписи для дальнейшего использования, тот должен будет включить режим "Эксперта" (или залезть ручками в текстовые конфиги и поправить их самостоятельно ;)

     
     
  • 6.27, Аноним (27), 18:23, 11/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Верифиция, построение графа, проходит на серверах. С базы серверов давать возможность что-то выкидывает НЕЛЬЗЯ.

    Фичи не учитывать при верификации подписи с прилагаемого файла нет. Да и пользователь откуда этот файл возьмёт? Кто и как его будет создавать и поддерживать?

     
  • 5.26, Аноним (23), 17:54, 11/07/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > решение товарищмайора: напихать тебе подписей столько, чтобы память у твоего ящика лопнула.

    Это понятно.

    >> Матмодель и алгоритмы менять нельзя.
    > так точно, товарищ майор! И сомневаться в адекватности тех кто так говорит - тоже нельзя!

    Текущая мат модель гарантирует, анонимность.

    Все изменения плохи:

    1. Или уменьшить анонимность поставив дополнительные условия на подпись ключа.

    2. Или оставить анонимность, а выкидывает поврежденные ключи. А товарищ майор хитрый и будет херить связывающие ключи, пока верификация не распадётся на географические домены: между Австралией, Бразилией и Россией мало связующих ключей.

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

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру