Подписи, основанные на криптографических хеш-суммах #2

Мы уже писали, что кроме цифровых подписей, основанных на асимметричной криптографии, существуют и другие алгоритмы — например, «подпись Лэмпорта», которая использует всего лишь один криптографический примитив, хеш-сумму.

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

Недавно набрели в сети на хорошую иллюстрированную статью, подробно раскрывающую тему таких «нетрадиционных» механизмов цифровой подписи.

#literature

Безопасный логгинг

Уж казалось бы, насколько логирование распространенная и очевидная практика, но сколько в ней нерешенных и нерешаемых вопросов! Один из сложнейших – безопасность. А точнее угроза конфиденциальности через утечки чувствительных данных в лог. В чем сложности?

Первая – что считать конфиденциальным. Ну, логин/пароль или данные банковских карт – само собой. Но ведь бывают ситуации, что адрес какой-то структуры/функции тоже становится конфиденциальным, если используется ASLR защита (как, например, в недавнем случае с Samsung).

Вторая – как не допустить утечки. Из подходов на уровне кода есть паттерн типа read-once/read-twice/read-X-times, когда для объекта вы контролируете счетчик чтений и ставите такой максимум, чтобы «лишние» чтения (в том числе в лог) не состоялись. Другой вариант — использовать отдельное хранилище для секретов, чтобы в памяти процесса plain-ом чувствительные данные в принципе не фигурировали. Также подходы уровня кода можно разнообразить расширением процессов — например, более строгие процессы code review, или CI с сервисами, проверяющими на типичные секреты, типа snyk.io.

Третья – как проверить. Для полноценных проверок нужна высокая степень покрытия (юнитами и фаззингом), приправленная прогоном утилит, которые бы искали уже утекшие секреты в логе (DLP-alike). Однако системы, оперирующие сенситивными данными, не должны писать в лог; а если уж писать, то очень боязливо. Хотя лучше никому в лог не писать вообще, потому что неясно, какие данные сенситивные. Но здесь security сталкивается с debugability, удобством отладки. А к debugability прилегает скорость расследования инцидента, которая тоже про безопасность.

В общем, логи нужны, логи важны, но не забывайте правильно их обезопасить.

#digest

Легкий рабочий стеб над собственными стеками становится для нас традиционным – раньше мы уже осмысливали архитектуру пива в Haskell и придумывали язык будущего с оператором «Fuck you, Rust!». Теперь пришла очередь типов переменных в Python, JavaScript и C++ :)

#fun

Код, как известно, может служить не только силам добра – продуктам, фичам, компонентам и вот этому вот всему – с его помощью можно, увы, создавать и вредоносы :(

Этот хабрапост написал профессиональный исследователь угроз и реверсер. В нем он подробно рассказал о своем «взгляде с обратной стороны»: как он разбирает самплы и читает двоичный код на реальных, «боевых» примерах. Очень полезно для всестороннего понимания разработки.

#digest

Homebrew CPUs

Хотели ли вы когда-нибудь сделать процессор с собственной архитектурой? Начать с простых вентилей и закончить полноценным устройством, способным выполнять произвольные программы? Для этого уже давно не нужно устраиваться на полупроводниковое производство с современным фотолитографом, достаточно запастись хорошей литературой, например книгой «Цифровая схемотехника и архитектура компьютера», и платой с FPGA.

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

Обратите внимание на такие проекты, как BMOW (Big Mess of Wires) и MyCPU. Кажется, что это уже не совсем игрушечные вычислительные машины, на которых можно выполнять какую-то реальную работу. Например, компьютер на базе MyCPU вполне может хостить сайт о себе любимом.

Ну и на закуску — не совсем традиционные проекты: например, FORTH-машины или даже вычислители без арифметико-логического устройства!

#digest

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

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

#fun

Топ-10 докладов FOSDEM-2023

Каждый год в Брюсселе проходит FOSDEM (Free and Open source Software Developers' European Meeting) — встреча, где собираются разработчики (и не только) свободного и открытого ПО со всего мира.

Предыдущие два года мероприятие по причине пандемии проходило онлайн, а в этом феврале наконец-то состоялось очно. Мы смогли побывать там и составили список самых, на наш взгляд, интересных выступлений и докладов. Смотрите по этой ссылке.

Спойлер: доклад Дрю Деволта, основанный на его собственном ЯП Hare – просто огонь!

#digest

Почти как Rust, только проще, или Пишем свой компилятор

Новые языки программирования появляются постоянно. Только популярных современных проектов масса: Go, Rust, Nim, Zig, Crystal, Swift, Kotlin, Pony. Кроме того, есть проекты и поменьше. Ну а любительские — так вообще появляются каждую неделю!

Конечно, не во всех новых языках программирования присутствует какая-то техническая или научная новизна, некоторые пытаются быть просто удобным инструментом, заботятся о том, чтобы программисту были доступны привычные концепции, но в более удачной упаковке (Go, Kotlin, Swift).

Однако бывает и так, что язык программирования приносит в массы какую-либо серьезную концепцию, коренным образом влияющую на то, как мы вообще воспринимаем программирование. Таким языком стал, например, Rust.

Продолжение 👉 ЗДЕСЬ

P.S. Ставьте палец вверх, если вам интересна эта тема! Наберем 10 лайков — посоветуем вам еще больше проектов, туториалов и книг :)

#digest

Вчера заспорили между собой о том, кто как пришел в сеньоры. Точнее, сами пути споров не вызывали – спорили главным образом о том, какой из них проще. Выделились два основных способа: линейно расти на одном проекте, или же сменить работу с повышением.

Большинство, как оказалось, уходило-переходило. Но были и совершенно нетипичные истории. Так, сестру одного из наших авторов взяли из науки – и сразу старшим аналитиком.

А как стали сеньором вы? Ждали? Уходили? Или может, как-то совсем по-иному? А если вы еще не сеньор, какой способ вам кажется проще?

👇

Пример качественной документации

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

Для нас, авторов этого канала, образцом качественной документации по проекту стала книга Genode Foundations. В действительности это постоянно обновляемая документация по внутренностям Genode Operating System Framework — конструктора операционных систем, построенного для работы над целой плеядой различных микроядер.

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

Что еще желать?!

А можете ли вы привести пример документации, которая вам нравится?

#literature

Ода предметно-ориентированным языкам

Хороший DSL (Domain Specific Language, предметно-ориентированный язык) бывает на вес золота и помогает элегантно решать довольно сложные проблемы. Часто такие мини-языки применяют там, где требуется много работать с бизнес-логикой и необходимо привлекать эксперта из предметной области, причем этот эксперт может плохо владеть программированием. Здесь подобные языки хорошо себя зарекомендовали, и причины для их применения абсолютно ясны.

Но DSL-и способны помочь и с совершенно иной точки зрения.

Продолжение 👉 ЗДЕСЬ

#digest

Технологии или польза?

Одна из статей Джеймса Хага (James Hague) поднимает важнyю тему в мире программирования. Многие из нас занимаются своей профессией именно потому, что любят технологии. Какой кайф пощупать что-нибудь новенькое, а главное использовать в своей работе (или, на худой конец, в хоббийном проекте)! Оттого на форумах и в профильных сообществах часто звучит вопрос: «Мне нравится язык X, что бы мне такое на нем написать?» Или: «Мне нравится ОС Y, какой бы проект мне сделать на ее основе?»

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

Не надо переписывать Photoshop на Rust, просто потому что любите Rust, особенно если вы профессионально не пользуетесь графическими редакторами! Да, вы получите удовольствие от кодирования, но результат, скорее всего, получится не очень. Ведь первичным окажется инструмент, язык программирования, а не польза. Лучше всего, заявляет Джеймс, подумать над своими непосредственными задачами и проблемами, а потом попробовать решить их наиболее удобным для вас способом. В том числе, применяя полюбившийся инструментарий.

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

А что вы думаете на этот счет?

#literature

Синтез гитарного звука миниатюрной программой на C

Цифровая обработка сигналов (DSP, Digital Signal Processing) — область знания немного магическая, поскольку достаточно простые алгоритмы порой выдают очень интересные результаты. Как и в этом случае: в небольшом GitHub gist приведен пример банальнейшего кода на C (обернут shell-скриптом), вывод которого проигрывается аудиокартой.

Звучит почти как гитара!

(Если вдруг вы не хотите запускать скрипт, послушайте mp3 примеры, идущие в комплекте.)

#fun