Дмитрий Пичулин deemru

Если придираться, то ваш вариант лучше, да.

Так

В предложенной схеме я вижу достаточность 2 транзакций на игру (одна от пользователя и одна от условного казино).

Можете рассказать как в 2 транзакции сделать commit-reveal про который вы говорите?

Да, действительно, многое зависит от предварительного кодирования сообщения (в основном есть ли там фиксированный паддинг или нет), но попросили именно детерминированную схему проверки, поэтому получили на уровне блокчейна набор s"${digestPrefix}withRSA", который гарантирует проверку на EMSA-PKCS1-v1_5.

Любой злоумышленник, имеющий доступ к "подписывалке", может заранее узнать подпись

Гениально.

Вы ошибаетесь.

Сама подпись RSA всегда была и остаётся детерминированной, разница только в схеме padding-а, которая может быть рандомизирована или нет.

Если само сообщение содержит рандомизированную часть, то padding может быть без ущерба для схемы детерминирован.

Хорошая статья размышление. Готовых решений, а тем более внедрений, ни в одном блокчейне пока нет.

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

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

Если вам интересна данная тема, в тексте проставлены ссылки для погружения.

Останутся вопросы — задавайте по существу.

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

Потому что никому в отечестве NSS для TLS не нужен.

В Chromium на Linux через NSS ключи перечисляются, да, но TLS работает через BoringSSL.

А доля Firefox упала до состояния неактуальности.

Есть вариант получше — NeoRouter Free, свой сервер в бесплатной версии, никаких привязок к кому-либо, пользуюсь активно и перманентно с 2009 года.

NSS завязан на PKCS11, а рабочая группа по этому стандарту в ТК26 гораздо менее активна, да и NSS всё менее актуален, поэтому доработки в любом случае планируются, но с минимальным приоритетом. Даже так: если нас не пинать, вряд ли будет выхлоп.

Планируется. Как только, так сразу.

Однако это станет возможным только по завершению всех согласований на уровне ТК26 и определению номеров сюит, например 0xFF88 и 0xFF89 для Магмы и Кузнечика соответственно.

Тогда можно начать вносить необходимые изменения в основную ветку OpenSSL: https://github.com/openssl/openssl/blob/26a7d938c9bf932a55cb5e4e02abb48fe395c5cd/ssl/s3_lib.c#L2660

Как только в OpenSSL появятся все необходимые идентификаторы, сразу выкатим обновлённую engine: https://www.cryptopro.ru/forum2/default.aspx?g=posts&m=84584#post84584

Слишком тяжело. Вы слышали про caddy?

Вот пример конфигурации для домашнего Unifi (сертификат получается и обновляется автоматически):

unifi.deem.ru {
    gzip
    header / Strict-Transport-Security "max-age=31536000"
    proxy / https://10.173.3.15:8443 {
        insecure_skip_verify
        transparent
    }
}

Данный конфиг даёт вот такой результат:

Пруф: https://www.ssllabs.com/ssltest/analyze.html?d=unifi.deem.ru

Тоже в итоге перешёл на pdd.yandex.ru — Яндекс надёжен и разрешает 90 секунд TTL.

Написал для этих целей генератор и сервер DDNS-ссылок — secq.ru/ddns (код на GitHub)

Достаточно после смены IP-адреса зайти по сгенерированной ссылке и получить 200 OK.

Для Mikrotik-ов, например: tool fetch url=$ddnsLINK keep-result=no

В VeraCrypt есть более актуальный шифр — «Кузнечик», и, кстати, хеш — «Стрибог».

Поэтому удаление поддержки ГОСТ 28147-89 не наносит ущерба отечественной криптографии.

Хотелось бы привлечь внимание к теме высокопроизводительного защищённого ESP-туннеля.

Данный opensource-проект основан на фреймворках netmap, soque и espio, приложение esptun живёт в форке netmap.

netmap — известный фреймворк по работе с кольцевыми буферами сетевых адаптеров, позволяющий добиваться высоких скоростей при минимальных накладных расходах, разрабатывается, в основном, силами сотрудников Пизанского университета, не требует внимания.

soque — фреймворк и очередь многопоточной обработки элементов без переупорядочивания, входит в состав данного проекта, требует внимания.

espio — фреймворк ESP-шифрования, входит в состав данного проекта, требует внимания.

esptun — приложение, создающее туннель на основе приведённых выше фреймворков, требует внимания.

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

А также сборка Chromium с поддержкой ГОСТ