Pull to refresh
76
0
Сергей Владимиров @vlsergey

Пользователь

Send message

Речь про оценку снизу. Если брать и другие символы, а также удлинить адрес, вариантов ещё больше. Но...


Спасибо за комментарий, подумаю, как переформулировать понятнее.

Алиса, Боб и Клара лучше Отправителя и Получателя по нескольким причинам:

  • Использование «Отправитель» в общем случае некорректно вообще, так как на каждом проходе протокола отправитель и получатель различны. Можно было бы заменить «Инициатором», а как назвать второго? Проще для всех протоколов заменить их какими-то общими обозначениями. Но вместо использования «участник 1», «участник 2» фактически используют обозначения «участник A», «участник B» и так далее (по порядку букв в алфавите).
  • Буквы A, B, C, как стоящие в начале латинского алфавита, наименее конфликтуют с другими обозначениями (Encrypt, Message, Key, etc.)
Под G15 понимается не просто исправление багов, связанных с возможностью DOS-атак, а доказательство того, что целые классы DDOS-атак становятся невозможны для данного протокола. Например, сразу все атаки, связанные с переполнением буфера. Насколько мне известно, пока что в TLS такого не делалось, т.е. никакого формального анализа на отсутствие брешей для DOS не делалось. Или есть какие-то работы на эту тему?

Свойства 16-20 для приведённых протоколов просто неактуальны. G1 уже подразумевает G16, G17-G19 на формальном уровне не закреплено (то есть никто не сертифицировал данные протоколы на эти задачи), ну а G20 это цель прикладного уровня. Хотя в каком-то смысле TLS можно отнести к выполняющим одну задачу по G20 (предъявление сертификата => установление связи), но это всё-таки не совсем бизнес-задача.
В TLS 1.3 «по табличке» стало только обязательным использование PFS (G9), или что-то ещё?
Русская школа криптографии существует, но вот с придумыванием своей терминологии у неё не очень. Вплоть до того, что появляются термины вроде «дешифровать», который, с точки зрения некоторых специалистов, вовсе не «расшифровать» (а провести успешную атаку на шифртекст).

Были и попытки использовать Андрея / Бориса в качестве экземплификантов, но не прижились.
Как ведут себя read-through и write-through в плане поддержки XA-транзакций?
Каким образом изменение хостинга привело к увеличению количества одновременных пользователей на сайте?

У меня только одна версия: прошлый хостинг был настолько плох, что его Гугл понизил в выдаче.
Единственное место, где Шнайер пытается исторически или методически связать разные протоколы — это последний абзац в описании протокола Нидхема-Шрёдера (стр. 80), да замечание о том, что базовый протокол Керберос — это вариант протокола Н.-Ш. (стр. 81). Описание остальных протоколов содержит общие слова о плюсах или способах использования, но не сравнение с другими протоколами.
В данном случае все верно — пар допустимых абонентов много. Все легальные абоненты образуют пару — и каждая из этих пар может исопользовать одну соответствующую пару «сертификатов».
А можно перечислить? Это не перевод, а оригинальная статья, в ней действительно может быть много стилистических ошибок. Ну не гуманитарии мы :-)
E_B(T_A, A, K)

Спасибо, поправил!

Не упомянуты схемы разделения ключей

Не могли бы вы описать, как эта схема работает в случае роста числа участников (как Трент выбирает, кому что посылать), или как называется? Есть подозрение, что в этой схеме размер пересылаемых данных должен будет расти с увеличением общего числа абонентов. Следовательно нарушится одно из требований к протоколам.
Если бы речь шла про традиционные процессоры, то на них попытка распараллелить операции в рамках одного раунда привела бы только к замедлению вычислений. Возможно, что подобная «векторизация» вычислений и сработает на описываемой архитектуре. Но что-то мне кажется, что это не то, что имел ввиду автор.

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

Тут явно идёт речь не про векторизацию шага внутри раунда, а про попытку раскидать сами шаги между потоками. Насколько я понимаю AES, это невозможно.
Пока не придумает («создаст») имеющий поддающийся [смотрящим] чтению смысл танец. Как-то так.
«Нельзя просто так взять и...» распараллелить блочное шифрование (AES). В большей части режимов сцепления блоков (OFB, CFB, etc.) входной следующий блок недоступен до окончания шифрования предыдущего.

Что ещё раз доказывает — не стоит браться за самостоятельное реализацию «простых и известных алгоритмов», пока не узнаешь хотя бы, что такое timing и вообще side-channel атаки.

image
Ну, если вы сможете научить эти суперкомпьютеры решать задачу полного перебора быстрее, чем обычные (см. алгоритм Гровера), то да, атака 51% возможна.

Но я бы рекомендовал в этом случае не решать задачу в 51%, а просто по тихому взломать ECDSA и перечислять на свой кошелёк деньги. См. Quantum computing attacks on ECC
Кроме хвостов у них должно быть и «тело» — snapshot состояния всех кошельков
Gorthauer87, а ваш алгоритм («модифицированный алгоритм византийского консенсуса») описан где-нибудь?
… от соседних (в сети Echo) с вами блоков узлов.

Чтобы генерировать новые блоки или создавать новую транзакцию не обязательно иметь у себя весь журнал. Даже для майнера достаточно некоего "snapshot'а" состояния сети + последние 2016 блоков (для учёта изменения сложности). Кроме того есть много мобильных клиентов, "кошельков", у которых база транзакций централизованно хранится на сервере, а они только осуществляют переводы.


С размером базы не всё так просто. Нужно ещё учесть, что её размер не может расти быстрее, чем 1 Мб / блок (т.е. на 10 минут). Даже если увеличить размер блока за счёт SegWit и других технологий, принципиальные ограничения останутся. Размер блока мы уже достигли (в среднем все блоки заполнены), поэтому скорость роста останется примерно одинаковой, скачкообразно меняясь только при вводе принципиально новых технологий формирования блоков в строй.

Information

Rating
Does not participate
Location
Россия
Registered
Activity