вот взял ты и переустановил себе линукс вместе с кошельком, скачал весь блокчейн с нуля, а он оказался поддельным с ключом от АНБ, что тогда?

Ну ССЗБ значит.

Ты какое-то опенайди придумал, только с другого боку.

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

3. Удостоверяем в УЦ (либо в любом его проявлении) соответствие между зарегистрированным в «любой надежной DNS» именем и реальным субъектом.

Не вижу принципиальной разницы между предложенным и существующими схемами.

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

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

А документы ты как подписывать будешь? От xxxVASYANxxx? Кому они нужны такие?

Ну мне было бы интересно подумать обо всем этом со стороны шифрования html тела и контента на сервере и дешифровке его на клиенте (пусть на js), т.е. прямо поверх http. Клиент получает кашу и строит из неё страницу. Для каждого клиента ессно каша своя.

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

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

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

Да, сделать нечто вроде неофициальной URI-схемы, например httpe (HTTP Encrypted). Пусть реализуемой плагином для браузера, на первое время.

Не вижу причины почему это быть хуже каких-то там «реальных имен»

Никакой юридически значимый документооборот на этом не построишь.

Смотря что понимать под юридической значимостью. Да, сейчас, в конкретной стране может и не построишь.

Да, сейчас, в конкретной стране может и не построишь.

Ни в какой ты стране не построишь таким образом. Чтобы нельзя было сказать «я это не подписывал» должно быть что-то, что будет устанавливать взаимно-однозначное соответствие между множеством ключей и множеством субъектов (конкретным людям).

Устанавливать соответствие между людьми вовсе не обязательно. Вооюще за что это людям такие привелегии?

Устанавливать соответствие между людьми вовсе не обязательно.

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

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

Публикуем открытый ключ или его хэш в любой надежной DNS: Namecoin, Emercoin, Ethereum, etc;

А гебня публикует еще сотню ключей. Как узнать кто настоящий?

Куда она опубликует, если имя уже будет занято тобой?

Публикует в «Namecoin, Emercoin, Ethereum, etc;»

Что мешает мне прямо сейчас занять ник consensus?

Ничто не мешает. Я предполагаю что ты сначала занимаешь имя, а потом используешь, а не наоборот.

Тогда это нужно делать при выдачи свидетельства о рождении. Будет тот же киберсквоттинг, но более удобный т.к. регулятора которому можно пожаловаться нет.

Оказывается, анонiмус еще и по криптографии специалист.

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

Можно тебя игнорировать? Я не пойму, почему я должен читать оффтоп написанный модератором. Абсолютно ничего не имею против, чтобы обсуждать по теме. Но тут приходит модератор, и пытается превратить техническую тему в хохлосрач.

Можно тебя игнорировать?

Только органолептически.

тут приходит модератор, и пытается превратить техническую тему в хохлосрач.

Это не техническая тема. Кстати, ей пора в Talks.

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

без доверенного обмена ключами возможна

В описанном тобой варианте всё-ещё есть обмен открытыми ключами, от осуществляется через «любой надежной DNS» и предполагает доверие этому «надёжному DNS».
Emercoin и Ethereum не интересовался, но в случае с Namecoin это означает «доверие 50%+1 майнеру».

Да это лучше чем ничего, и лучше чем централизованные способы обмена ключами (УЦ, хранилища ключей), но принципиально схема ровно та-же. Просто в твоём случае используется другая «третья доверенная сторона».

Это техническая тема, она касается конкретной проблемы, обмена публичными ключами

Это дилетантская тема с желтым заголовком. Ты всего лишь предлагаешь механизм обмена ключами через *coin.

А если тебя смутило отсутствие конкретных примеров

Меня ничего не смутило.

В целом это так, но не совсем. Дело в том что атака 51% это такой ярлык, стереотип распространенный СМИ. В реальности дело обстоит немного иначе. А именно, если главная цепочка выбирается автоматически, и доверие к изменениям происходить по истечению нескольких блоков, то атака 51% возможна. Если же вместо, допустим 6 блоков, поставить 6000, то этого времени вполне хватит чтобы узнать об атаке 51%, так как доверие подрывается ко всей системе и затрагивает всех пользователей. В централизованных способах возможно провести индивидуальную атаку на тебя, не затрагивая других пользователей, то есть незаметно.

Ты всего лишь предлагаешь механизм обмена ключами через *coin.

Механизм публикации ключа, тогда.

Это дилетантская тема с желтым заголовком.

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

без доверенного обмена ключами
открытый ключ или его хэш в любой надежной DNS

нет противоречия?

Надежной DNS, это как раз и значит, не требующей доверия. И тогда это свойство повторяется для обмена ключами.

Речь не о конкретных атаках а конкретные системы. Ты приходишь на ЛОР и заявляешь что одна из фундаментальных систем решена, но по факту ты просто описал ещё один (в общем-то не новый) способ обхода неразрешимой (во всяком случае пока-что) проблемы.

В общем-то tailgunner кратко сказал всё что нужно сказать:
«Это дилетантская тема с желтым заголовком. Ты всего лишь предлагаешь механизм обмена ключами через *coin»

Блокчейн требует доверия как минимум к началу чейна. Если у тебя нет правильного первого блока и между тобой и сетью есть Мэлори то можно скормить тебе полностью липовый блокчейн.
А теперь сравни инициализирующий блок блокчейна с сертификатом УЦ.
Я не говорю что ситуации полностью идентичны. Я не говорю что использование блокчейна для обмена ключами полностью бессмысленно. Я говорю только что *принципиально*, так-что нечего тут делать заявления космического масштаба.

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

Если же понимать фундаментально, то тогда заголовок вообще не имеет смысла, как и сам вопрос. Это как спор о существовании Бога. Если воспринимать интуитивно, то кажется, что смысл есть, да.

• Публикуем открытый ключ или его хэш в любой надежной DNS: Namecoin, Emercoin, Ethereum, etc;
• Пользуемся зарегистрированным именем.

• Правительственный MITM подменяет это имя на другое, зарегистрированное компетентными органами.

А теперь сравни инициализирующий блок блокчейна с сертификатом УЦ.

Сравнение с УЦ не совсем корректно. Я уже выше написал, что блокчейн отличается от УЦ тем что затрагивает всех пользователей. Но рассмотрю этот вопрос иначе.

Дело в том, что проблема УЦ, это не проблема доверия к получению сертификата. Это вообще другой аспект, как надежно получать сертификаты или хеш первого блока или чекпоинты. Проблема УЦ это доверие к честной работе УЦ. УЦ в любое время может выдать фальшивый сертификат. В случае блокчейна речь идет только о полностью новых именах. Подменить старое имя, которое принадлежит кому-либо, если у тебя есть блокчейн, невозможно. Никакая атака 51% тут не поможет. Она может быть использована для попытки сокрытия смены ключа.

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

Правительственный MITM подменяет это имя на другое, зарегистрированное компетентными органами.

Да, все так. Я предполагаю что имена не подменяются. То есть что надежность на уровне того, как если использовать открытые ключи в качестве имен.

Ты

Сравнение с УЦ не совсем корректно.

Я

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

Ты

Ничего космического я тут не заявляю.

В теме начинающейся словами:

Асимметричная криптография без доверенного обмена ключами возможна
Раз и навсегда покончив с мифами, о том что это невозможно.

Хорошо хоть сейчас к вменяемому виду первопост привёл.

человекочитаемых ... хэшей

Они строго равны, если решать проблему «правильно»: 1. ECCные ключи вне так уж велики (roughly twice the security parameter), 2. хеш должен быть в несколько раз короче, 3. в читаемом алфавите много букв.

Допустим, нам достаточно 256битной сложности, ключ в 512, хеш в 8 раз меньше — легко кодируется 7ю слогами, вполне в пределах читательских способностей человека.

Сменил заголовок по причине ввода в заблуждение

Сволочь, не меняй в другой раз