Криптография *

Сегодня произошло событие, которое так долго ждало всё криптокомьюнити. Starknet анонсировали Early Community Member Program (ECMP)(источник - их X). Суть программы — вознаградить членов комьюнити, которые внесли свой вклад в развитие экосистемы, и речь не только про разработчиков.

На время затишья на рынке наиболее актуальным способом заработка пришёлся дропхантинг (охота на дропы - раздачи монет). То есть тестирование проектов на стадии разработки за вознаграждение в токенах этого самого проекта, когда он выйдет на рынок. Подробно об этом способе заработка мы писали ещё весной этого года. Вот наша статья на Хабре.

Причинами такой популярности дропхантинга, на мой взгляд, стали:

Вы читаете соглашения о конфиденциальности? Мало кто тратит время. Они все похожи друг на друга, скучны, и, скорее всего, не врут. Компании, особенно большие, стараются по-честному исполнять свои обязанности в отношении данных пользователей, хотя бы во избежание больших штрафов. И все же с защитой персональных данных в мире что-то не так. Что если концепция приватности сама по себе — и есть проблема.

Децентрализованные проекты обычно не говорят «приватность», а говорят, что данные «принадлежат пользователю» (data ownership). А в чем разница? Мы придумали забавную аналогию, и хотим поделиться.

Уверен, что вы хотя бы раз создавали пару ключей RSA, напримет, потому, что вам нужно было подключиться к GitHub, и вы хотели избежать необходимости вводить свой пароль каждый раз. Вы добросовестно следовали инструкциям по созданию SSH-ключей, и через пару минут всё было готово.

Но знаете ли вы, что именно вы делали? Углублялись ли вы в детали процесса?

Знаете ли вы, что содержится в файле ~/.ssh/id_rsa? Почему ssh создает два файла с разным форматом? Замечали ли вы, что один файл начинается со слов ssh-rsa, а другой — с -----BEGIN RSA PRIVATE KEY----- ? Вы замечали, что иногда в заголовке второго файла отсутствует часть RSA и просто написано BEGIN PRIVATE KEY?

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

Добро пожаловать в новый мир новых технологий вычислений!

В быту, когда мы смотрим на разные предметы, мы пытаемся понять - похожи ли они или нет, и на сколько они похожи.

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

Одним из таких критериев "похожести" является совпадение частотных характеристик этих последовательностей.

Рассмотрим вопрос, как реализовать такую проверку с использованием квантовых вычислений и напишем программку-тест на Q-sharp для проверки этих рассуждений.

Для понимания данного туториала вам потребуются базовые знания по

теории вероятности

алгебре

булевым функциям

свёртке, корреляции, скалярному произведению

квантовым вычислениям (кубиты и трансформации)

программированию на Q-sharp

Криптохомячкам посвящается ...

Алгоритм Гровера представляет собой обобщённый, независящей от конкретной задачи поиск, функция которого представляет "чёрный ящик" f: {0,1}^n to {0,1}^n, для которой известно, что EXISTS!w:f(w)=a, где a — заданное значение.

Считаем, что для f и заданного a можно построить оракул Uf: { |w> to |1>, |x> to |0> if |x> != |w> }

Алгоритм Гровера достаточно прост

1. Задаём в регистре (массиве кубитов) начальное значение H|0>
2. Повторяем несколько раз (исходя из оценки) пару трансформаций над регистром
   
   • Отражение от решения Uw: { |w> to -|w>, |x> to |x> if |x> != |w> } или Uw = I-2|w><w|
   • Отражение от s=H|0> Us = 2|s><s|-I
3. Забираем нужное решение из регистра (с большой долей вероятности, что оно правильное)

Применим этот алгоритм для решения задачи нахождения ключа шифра Цезаря ...

Стеганография - это искусство и наука передавать сокрытые данные внутри других, не сокрытых данных.

Подробнее можно прочитать здесь.

Часто, когда говорят о стеганографии, не выходят за рамки LSB в картинках (хотя и в картинках можно сделать нечто более оригинальное ). 

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

Общий принцип

Для начала на “пальцах” распишем, как это в целом работает. Любой файл можно зашифровать и представить в base64 текстовом виде. Далее его можно отправить на сервис одноразовых сообщений (например https://onetimesercet.com/ )

Отправив сообщение мы получаем ссылку вида https://onetimesecret.com/secret/jqr1s0o5bvlts8cyice71fvwv0o0ltx 

Затем мы отправляем саму ссылку на сервис сокращения ссылок, и получаем сокращённую ссылку; например для goo.su: https://goo.su/SAsb.

Как видим у нас всего 4 байта, если мы заранее знаем какой сервис используем (в реальной стеганографии разумнее использовать свой сервис), если мы заранее имеем ключ расшифрования (обмен ключей – отдельная задача), то нам достаточно переслать всего 4 байта для передачи искомого файла. 

Это и есть принцип ссылочной стеганографии – мы передаем ссылку на сообщение, а не само сообщение.

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

Что же из себя представляет NGFW (Next Generation Firewall)? Чем заменить Firewall (вариант OpenSource)?

Всем привет!

Краткое предисловие: я счастливый обладатель замечательного саундбара YAS-109 от Yamaha, на момент написания пользуюсь им уже целый год, и всё в целом хорошо. Но однажды я решил узнать: не подслушивает ли меня мой музыкальный друг? Ведь у него есть встроенная поддержка Alexa, а ещё Bluetooth, WiFi, Ethernet и другие прелести… Так и начинается история моего ресёрча.

В этой статье обзорно поговорим про грядущую фичу Internet Computer'a под названием VETKeys. Она полностью решает проблему менеджмента ключей в privacy-focused приложениях (и в Web3.0, и в Web2.0), позволяя вообще не хранить ключи шифрования пользователей, а запрашивать их on-demand из блокчейна по протоколу гарантирующему, что никто кроме самого пользователя его ключ не увидит.

MySQL научился использовать OpenSSL, чтобы шифровать трафик между клиентом и сервером году где-то в 1999. В принципе работало оно нормально, свою задачу выполняло, трафик шифровало. Но был там один фатальный недостаток. SSL в MySQL, а позже и в MariaDB, не работал сам, сразу. Его надо было настроить. И это было непросто.

Ну а что делать, сертификат-то проверять надо. Иначе это не защита, а пшик. Приходится терпеть. Так мы и терпели почти четверть века, и очень небольшое количество пользователей проходило квест настройки SSL до конца. Это должно измениться новом релизе MariaDB 11.3 (пока доступен только в виде превью тут).

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

Введение

Криптография в целом — это большая область знаний. И хотя блокчейн всегда идет с ней рука об руку, в реальных проектах на базе распределенных реестров используется лишь некоторые из достижений криптографии. В этом посте я постараюсь рассказать простым языком, что они собой представляют и как работают в рамках нашей блокчейн-платформы.

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

Сейчас мы с вами разберемся с базой!