Алиса, Боб и Клара лучше Отправителя и Получателя по нескольким причинам:
Использование «Отправитель» в общем случае некорректно вообще, так как на каждом проходе протокола отправитель и получатель различны. Можно было бы заменить «Инициатором», а как назвать второго? Проще для всех протоколов заменить их какими-то общими обозначениями. Но вместо использования «участник 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 (предъявление сертификата => установление связи), но это всё-таки не совсем бизнес-задача.
Русская школа криптографии существует, но вот с придумыванием своей терминологии у неё не очень. Вплоть до того, что появляются термины вроде «дешифровать», который, с точки зрения некоторых специалистов, вовсе не «расшифровать» (а провести успешную атаку на шифртекст).
Были и попытки использовать Андрея / Бориса в качестве экземплификантов, но не прижились.
Единственное место, где Шнайер пытается исторически или методически связать разные протоколы — это последний абзац в описании протокола Нидхема-Шрёдера (стр. 80), да замечание о том, что базовый протокол Керберос — это вариант протокола Н.-Ш. (стр. 81). Описание остальных протоколов содержит общие слова о плюсах или способах использования, но не сравнение с другими протоколами.
В данном случае все верно — пар допустимых абонентов много. Все легальные абоненты образуют пару — и каждая из этих пар может исопользовать одну соответствующую пару «сертификатов».
Не могли бы вы описать, как эта схема работает в случае роста числа участников (как Трент выбирает, кому что посылать), или как называется? Есть подозрение, что в этой схеме размер пересылаемых данных должен будет расти с увеличением общего числа абонентов. Следовательно нарушится одно из требований к протоколам.
Если бы речь шла про традиционные процессоры, то на них попытка распараллелить операции в рамках одного раунда привела бы только к замедлению вычислений. Возможно, что подобная «векторизация» вычислений и сработает на описываемой архитектуре. Но что-то мне кажется, что это не то, что имел ввиду автор.
Не уверен, что автор даже разобрался в AES, так как вот такие фразы вызывают большие вопросы:
каждый раунд состоит из дискретных шагов. Их тоже можно раскидать, ещё больше увеличив скорость такта
Тут явно идёт речь не про векторизацию шага внутри раунда, а про попытку раскидать сами шаги между потоками. Насколько я понимаю AES, это невозможно.
«Нельзя просто так взять и...» распараллелить блочное шифрование (AES). В большей части режимов сцепления блоков (OFB, CFB, etc.) входной следующий блок недоступен до окончания шифрования предыдущего.
Что ещё раз доказывает — не стоит браться за самостоятельное реализацию «простых и известных алгоритмов», пока не узнаешь хотя бы, что такое timing и вообще side-channel атаки.
Ну, если вы сможете научить эти суперкомпьютеры решать задачу полного перебора быстрее, чем обычные (см. алгоритм Гровера), то да, атака 51% возможна.
Но я бы рекомендовал в этом случае не решать задачу в 51%, а просто по тихому взломать ECDSA и перечислять на свой кошелёк деньги. См. Quantum computing attacks on ECC
Чтобы генерировать новые блоки или создавать новую транзакцию не обязательно иметь у себя весь журнал. Даже для майнера достаточно некоего "snapshot'а" состояния сети + последние 2016 блоков (для учёта изменения сложности). Кроме того есть много мобильных клиентов, "кошельков", у которых база транзакций централизованно хранится на сервере, а они только осуществляют переводы.
С размером базы не всё так просто. Нужно ещё учесть, что её размер не может расти быстрее, чем 1 Мб / блок (т.е. на 10 минут). Даже если увеличить размер блока за счёт SegWit и других технологий, принципиальные ограничения останутся. Размер блока мы уже достигли (в среднем все блоки заполнены), поэтому скорость роста останется примерно одинаковой, скачкообразно меняясь только при вводе принципиально новых технологий формирования блоков в строй.
Речь про оценку снизу. Если брать и другие символы, а также удлинить адрес, вариантов ещё больше. Но...
Спасибо за комментарий, подумаю, как переформулировать понятнее.
Свойства 16-20 для приведённых протоколов просто неактуальны. G1 уже подразумевает G16, G17-G19 на формальном уровне не закреплено (то есть никто не сертифицировал данные протоколы на эти задачи), ну а G20 это цель прикладного уровня. Хотя в каком-то смысле TLS можно отнести к выполняющим одну задачу по G20 (предъявление сертификата => установление связи), но это всё-таки не совсем бизнес-задача.
Были и попытки использовать Андрея / Бориса в качестве экземплификантов, но не прижились.
У меня только одна версия: прошлый хостинг был настолько плох, что его Гугл понизил в выдаче.
Спасибо, поправил!
Не могли бы вы описать, как эта схема работает в случае роста числа участников (как Трент выбирает, кому что посылать), или как называется? Есть подозрение, что в этой схеме размер пересылаемых данных должен будет расти с увеличением общего числа абонентов. Следовательно нарушится одно из требований к протоколам.
Не уверен, что автор даже разобрался в AES, так как вот такие фразы вызывают большие вопросы:
Тут явно идёт речь не про векторизацию шага внутри раунда, а про попытку раскидать сами шаги между потоками. Насколько я понимаю AES, это невозможно.
Что ещё раз доказывает — не стоит браться за самостоятельное реализацию «простых и известных алгоритмов», пока не узнаешь хотя бы, что такое timing и вообще side-channel атаки.
Но я бы рекомендовал в этом случае не решать задачу в 51%, а просто по тихому взломать ECDSA и перечислять на свой кошелёк деньги. См. Quantum computing attacks on ECC
блоковузлов.Чтобы генерировать новые блоки или создавать новую транзакцию не обязательно иметь у себя весь журнал. Даже для майнера достаточно некоего "snapshot'а" состояния сети + последние 2016 блоков (для учёта изменения сложности). Кроме того есть много мобильных клиентов, "кошельков", у которых база транзакций централизованно хранится на сервере, а они только осуществляют переводы.
С размером базы не всё так просто. Нужно ещё учесть, что её размер не может расти быстрее, чем 1 Мб / блок (т.е. на 10 минут). Даже если увеличить размер блока за счёт SegWit и других технологий, принципиальные ограничения останутся. Размер блока мы уже достигли (в среднем все блоки заполнены), поэтому скорость роста останется примерно одинаковой, скачкообразно меняясь только при вводе принципиально новых технологий формирования блоков в строй.