• RSA-рандом на блокчейне
    0

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

  • RSA-рандом на блокчейне
    0

    Так

  • RSA-рандом на блокчейне
    0

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


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

  • RSA-рандом на блокчейне
    0

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

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

    Гениально.

  • RSA-рандом на блокчейне
    0

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


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


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

  • Cлучайный оракул на основе цифровой подписи в блокчейне
    0

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


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

  • Cлучайный оракул на основе цифровой подписи в блокчейне
    0

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


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


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

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

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


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


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

  • Лучшие VPN-решения для пользователей Linux
    +1

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

  • TLS 1.2 и новый ГОСТ
    0

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

  • TLS 1.2 и новый ГОСТ
    +4

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


    Однако это станет возможным только по завершению всех согласований на уровне ТК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

  • Unifi Controller + Nginx. HTTP & HTTPS
    0

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


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


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

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


    image


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

  • Домашний хостинг сайтов с динамическим IP
    0

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


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


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


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

  • ПО для шифрования VeraCrypt подверглось аудиту
    +1

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


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

  • Открытая трибуна для разработчиков opensource-проектов
    0

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


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


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


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


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


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


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

  • Универсальный https c использованием ГОСТ сертификата
    0
  • Пастильда — открытый аппаратный менеджер паролей
    +2
    Я атакующий.

    На мой honeypot приходит пользователь с аккаунтами sberbank, bankofchina, JPMorgan_Chase, citibank и т.д.

    Берём пользователя в оборот!
  • Пастильда — открытый аппаратный менеджер паролей
    0
    Спасибо за ещё один вектор атаки на устройство.
  • Пастильда — открытый аппаратный менеджер паролей
    0
    Так точно, конкретному сайту должны быть предоставлены только две сущности, логин и пароль. Так делают все менеджеры паролей.

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

    Аппаратное шифрование, как правило, требуется для обеспечения защиты высокого класса. Ваша концепция, в текущем виде, выглядит как гаджет поиграться.
  • Пастильда — открытый аппаратный менеджер паролей
    0
    Хорошо, пользователь (и сайт) увидит звёздочки, мастер-пароль всё ещё у нас.

    Но всё остальное, что видит пользователь, потенциально видит и враг. По названиям записей вас могут, например, идентифицировать.

    Идея с вводом данных в поле без дополнительных организационных мер (например отключение скриптов на сайте) пока слабовата.
  • Пастильда — открытый аппаратный менеджер паролей
    0
    Есть большая дыра в безопасности, которая зияет так, что пользоваться вашим устройством в текущей реализации нельзя.

    Сами сайты, а особенно прикрученная аналитика (Яндекс.Метрика точно умеет), записывают всё, что делает пользователь.

    Ввели мастер-пароль — прощай мастер-пароль.