OpenPCC — это open-source фреймворк, обеспечивающий доказуемо приватный вывод для моделей искусственного интеллекта. Проект фокусируется на защите конфиденциальности данных при выполнении инференса, позволяя организациям использовать ИИ без компромиссов в безопасности. Фреймворк реализует криптографические протоколы, гарантирующие, что исходные данные пользователей остаются защищенными даже при обработке на сторонних серверах.

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

• Обсуждение вращается вокруг конфиденциального вычисления: участники обсуждают, какие именно гарантии предоставляет Apple и другие решения, и какие уязвимости остаются.
• Поднимается вопрос, что именно подразумевается под "конфиденциальностью" и какие именно угрозы мы пытаемся предотвратить.
• Участники спорят, насколько критично важно иметь открытый исходный код и возможность самостоятельно собрать бинарник, чтобы убедиться, что в нем нет бэкдоров.
• Обсуждается, что на практике может означать "открытый исходный код" и почему это важно для безопасности и конфиденциальности.
• Некоторые участники высказывают мнение, что в конечном счете важно не столько само решение, сколько доверие к провайдеру, и что в конечном счете доверие к провайдеру может быть важнее, чем к конкретному техническому решению.

Alfred Menezes, автор известного "Руководства прикладной криптографии", запустил образовательную платформу Cryptography 101 с курсами по всем областям прикладной криптографии. Платформа включает семь специализированных курсов: решеточная криптография, алгоритмы Kyber и Dilithium, редукция решеточных баз, схемы подписей на основе хеш-функций, фундаментальные криптографические примитивы и их практическое применение, а также коды исправления ошибок. Курсы сочетают видеолекции, конспекты и упражнения, причем некоторые уже доступны, а другие запланированы на 2024-2025 годы.

Особое внимание уделяется постквантовой криптографии: курс по Kyber и Dilithium (стандартам NIST) уже доступен, а запланирован курс по редукции решеточных баз на основе алгоритма LLL. Для преподавателей подготовлены отдельные ресурсы. Платформа дополняется исследовательскими материалами, публикациями и профессиональной деятельностью Менезеса, что делает ее комплексным ресурсом как для начинающих, так и для опытных специалистов в области криптографии.

• Современные криптографические библиотеки (libsodium, Tink) берут на себя выбор алгоритма, оставляя разработчику только выбор уровня безопасности и удобства использования.
• Для большинства задач достаточно использовать готовые решения, но для специфических задач нужно изучать документацию и выбирать алгоритм вручную.
• Надёжные источники информации включают "Handbook of Applied Cryptography" и "Cryptographic Right Answers".
• Для подписи и аутентификации используйте Ed25519, для шифрования — XChaCha20-Poly1305.
• Не пытайтесь реализовывать криптографию самостоятельно, используйте готовые библиотеки.

Регистр текста существенно влияет на размер QR-кодов. Алгоритм кодирования интерпретирует смешанный регистр как бинарные данные (8 бит на символ), а верхний регистр — как алфавитно-цифровые данные (5.5 бит на символ). Это связано с тем, что QR-коды используют специальный алфавит из 44 символов (цифры, заглавные буквы и несколько знаков), где два символа кодируются в 11 битах. Любой символ вне этого алфавита, включая строчные буквы, переключает режим кодирования на 8-битный.

Практический пример демонстрирует разницу: QR-код для предложения "The quick brown fox jumps over the lazy dog" в смешанном регистре занимает 33×33 пикселя (1089), а в верхнем регистре — всего 29×29 (841 пикселя), что составляет сокращение примерно на 30%. Этот принцип применяется в криптографии: Bech32-кодирование Bitcoin-адресов (32 символа) требует меньше пикселей в QR-коде, чем Base58 (58 символов), несмотря на меньший алфавит, так как использует только строчные буквы, которые перед кодированием преобразуются в заглавные.

• Обсуждение показало, что QR-коды изначально создавались для автомобильных деталей, а не для URL, и что регистр в URL не влияет на размер QR-кода, но может влиять на его читаемость.
• Участники обсуждали, что большинство URL-адресов используют строчные буквы, и что это может быть проблемой для QR-кодов, которые не поддерживают строчные буквы.
• Было отмечено, что использование URL сокращений может быть решением для длинных URL, но что это может быть проблемой для безопасности и конфиденциальности.

Автор написал новую реализацию ML-DSA — постквантового алгоритма подписи NIST на Go, но столкнулся с проблемой: функция Verify постоянно отвергала действительные подписи. Уставший после четырех дней работы, он решил попробовать Claude Code для отладки. ИИ мгновенно обнаружил сложную ошибку: при верификации высокие биты w1 брались дважды из-за неправильного повторного использования функции, объединяющей HighBits и w1Encode. Claude Code загрузил код в контекст и сразу нашел проблему без предварительных исследований, затем написал тест для подтверждения гипотезы.

Второй эксперимент с синтетическими ошибками подтвердил эффективность Claude Code: он нашел ошибку в вычислении констант в Монтгомери и проблему с длиной значения в подписи (32 бита вместо 32 байт), потратив меньше времени, чем автор. Хотя Claude Code иногда сдавался после частичного исправления, его способность быстро находить сложные ошибки в низкоуровневой криптографии впечатлила. Автор признал, что до сих пор не понимает, когда лучше использовать ИИ-инструменты, но этот опыт стал отличным кейсом для скептиков.

• LLM-агенты эффективно находят баги, но не всегда предлагают корректные фиксы; важно помнить, что их роль — это инструмент для поиска и понимания проблемы, а не окончательное решение.
• Используйте LLM как «запахивающий» инструмент: он укажет, где копать, но не копает за вас.
• Стоит ли доверять LLM-агентам доступ к вашей системе и данным — вопрос безопасности и приватности.
• Стоит ли доверять LLM-агентам, которые могут запускать код или команды, зависит от вашего уровня доверия к провайдеру и от того, насколько вы уверены в их намерениях.
• Не стоит полагаться на LLM-агентов для критически важных систем безопасности или криптографии.

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

Протокол использует криптографические методы для проверки владения email без необходимости отправки подтверждающих писем. Это потенциально может сократить количество спама и повысить эффективность регистрации на сайтах. Разработка находится на ранней стадии и открыта для обсуждения в рамках веб-сообщества.

• Предложение стандарта Email Verification API вызвало оживленную дискуссию, но критики указывают, что он не решает реальную проблему, а лишь усложняет процесс регистрации и может быть использован для сбора данных пользователей.
• Участники обсуждения подчеркнули, что вместо улучшения приватности, предложенный стандарт может привести к утечке данных, поскольку браузер передает информацию о сайте, который запрашивает токен.
• Было отмечено, что вместо того, чтобы упростить процесс регистрации, новый стандарт может усложнить его, поскольку требует от пользователя дополнительно подтверждать свой email через сторонний сервис, что может быть неудобно и небезопасно.
• Некоторые участники выразили обеспокоенность тем, что новый стандарт может быть использован для сбора данных пользователей и что он не предлагает никаких реальных преимуществ по сравнению с существующими решениями.
• Было также отмечено, что вместо того, чтобы предотвратить спам, предложенный стандарт может быть использован для отправки нежелательной почты, что может привести к дополнительным проблемам.

Современные электронные паспорта представляют собой встроенные устройства с файловой системой, контролем доступа и криптографической защитой, соответствующие стандартам ICAO Doc 9303. Их файловая структура включает три типа файлов: основные (MF) как корневой каталог, специализированные (DF) как приложения и элементарные (EF) с данными. Основное приложение eMRTD содержит персональные данные (DG1) и биометрическую информацию (DG2 с фотографией), а также дополнительные опциональные группы данных для цифровых штампов и виз.

Эти документы используют короткодействующий RFID (ISO 14443) и защищены от несанкционированного чтения, прослушки, подделки и копирования. Модель угроз разделяет атакующих по физическому доступу: без паспорта нельзя прочитать данные или отследить его перемещения, а с паспортом - скопировать цифровую копию или получить доступ к биометрическим данным (отпечатки пальцев DG3, радужка DG4). Несмотря на современные протоколы, поддержка устаревших механизмов создает дополнительные риски для владельцев.

• Вашингтонский "Enhanced ID" стал первым документом, одобренным DHS в 2005 году, но уже тогда исследователи нашли уязвимости, включая возможность удалённого клонирования и отключения чипа, а ведь с тех пор технологию так и не обновили.
• Паспорт как технология контроля движения людей: от крепостных до наших дней.
• Электронные паспорта и ID-карты не решают проблему подделки документов, а лишь переносят доверие с бумаги на криптографию, что в условиях коррупции в гос. органах не имеет значения.
• Почему в 2024 году нельзя сделать паспорт, который нельзя было бы подделать? Потому что это не позволит контролировать потоки мигрантов.
• Паспортизация как способ контроля миграции.

В статье Джеймса Миккенса критикуется сложный и непонятный язык, используемый в исследованиях по безопасности. Автор приводит примеры абсурдных названий докладов вроде "Vertex-based Elliptic Cryptography on N-way Bojangle Spaces", которые начинаются посередине сложной темы без должного контекста. Миккенс сравнивает исследователей безопасности с триатлетами, тренирующимися для маловероятных сценариев, утверждая, что они сосредоточены на теоретических проблемах, а не на практических решениях.

Автор также критикует PR-навыки специалистов по безопасности, сравнивая их с "надменными подростками, слушающими готическую музыку", которые сосредоточены на потенциальных катастрофах, но не дают практических рекомендаций. Миккенс выражает разочарование, что сообщество безопасности изучает экзотические угрозы (например, управление кардиостимуляторами через банку Pringles), вместо решения более распространенных проблем, таких как создание запоминающихся, но надежных паролей.

• Обсуждение началось с цитаты из статьи Mickens о том, что если противник — это Mossad, то «вы уже мертвы» и ничего не поделаешь.
• Участники обсудили, насколько реалистично представленный сценарий, где противник — это государственная разведка, и какие угрозы реальны для обычных людей.
• Поднялась тема, что даже если Mossad не заинтересован в большинстве людей, то есть ли смысл в чрезмерной паранойе, и какие именно угрозы стоит считать реальными.
• Обсуждались примеры, когда разведки разных стран использовали вредоносное ПО или оборудование для слежки, и как это влияет на дискуссию о безопасности.
• В комментариях также поднялись темы, связанные с недавними событиями, включая взрывы пейджеров и телефонов, и обсуждалось, как это соотносится с обсуждаемыми темами.

• @mrasong отметил, что несмотря на отсутствие опыта работы с ассемблером, получил много полезной информации из статьи.
• @jmspring поделился опытом работы с ассемблером в прошлом (включая inline-оптимизации для криптоопераций), но сейчас предпочитает использовать ИИ для решения задач.
• @indyjo привел примеры необычных современных применений ассемблера: программирование для Atari ST в 2025 году и обучение роботов игре в DOOM.

В начале 2025 года исследователи обнаружили криптографические уязвимости в реализации FourQ от Cloudflare в библиотеке CIRCL. Проблемы были сообщены через HackerOne в марте и напрямую в Cloudflare после слабого ответа команды. FourQ — эллиптическая кривая с 128-битной безопасностью от Microsoft Research, работающая над расширением простого поля и подходящая для систем с ограниченными ресурсами.

Уязвимость связана с атаками на недействительные точки, когда сервер выполняет вычисления без проверки валидности точек на кривой. В протоколе ECDH это позволяет атакующему использовать точки с гладким порядком подгруппы, значительно упрощая восстановление секретного ключа. Cloudflare признала проблемы и исправила их после уведомления.

• Пользователи обсуждают, что Cloudflare не смогли должным образом проверить и исправить уязвимость в библиотеке CIRCL, что вызывает вопросы о надёжности их кода и процессов.
• Обсуждается, что баг-баунти программы не предоставляют достаточной мотивации для исследователей, особенно если речь идёт о сложных технических проблемах, что может отпугнуть исследователей от отчитывать о найденных проблемах.
• Участники обсуждают, что компании должны быть более открыты к внешнему аудиту и тестированию, особенно для критически важных систем как криптографические библиотеки.
• Участники также обсуждают, что вместо того чтобы полагаться на внутренние ресурсы, компании должны нанимать независимых экспертов для аудита и тестирования их систем, особенно если они не имеют внутрених экспертов по криптографии.
• Участники также обсуждают, что вместо того чтобы полагаться на внутренние ресурсы, компании должны нанимать независимых экспертов для аудита и тестирования их систем, особенно если они не имеют внутрених экспертов по криптографии.

Пол Хадсон создал приложение Hacktivate, чтобы научить детей 13+ основам кибербезопасности через формат игры "захвати флаг". В отличие от современных компьютеров, которые слишком защищены для экспериментов, приложение предлагает 240 уникальных заданий по SQL-инъекциям, взлому хэшей, стеганографии и другим практическим навыкам. "Я хочу вернуть тот же опыт, который был у меня, новому поколению", — объясняет автор, стремясь сделать обучение одновременно увлекательным и структурированным.

Приложение использует безопасную песочницу, где все действия происходят внутри игры, не затрагивая реальные системы. Задания варьируются от базовых вопросов о представлении данных (hex, binary, ASCII) до сложных криптографических задач с современными алгоритмами. "Моя цель — не превратить всех в опытных пентестеров за один день, а вдохновить новое поколение хактеров на эксперименты и обучение в безопасной среде", — подчеркивает Хадсон. Приложение уже доступно на iPhone, iPad и Mac.

• Пользователи обсуждают, как раннее влияние нехватки ресурсов в странах третьего мира сформировало их навыки и мотивацию к самообучению и творческому подходу к решению проблем.
• Поднят вопрос о том, что микротранзакции в приложениях могут быть неэтичными, особенно для детей, и что существует альтернативная версия приложения без них.
• Упомянуто, что разработчик приложения, Paul Hudson, ранее преподавал автору Swift и UIKit, что подчеркивает его вклад в обучении сообщества разработчиков.
• Участники обсуждают, что важно сохранять баланс между монетизацией и доступностью образования, и что существует версия приложения без микротранзакций.

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

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

• Выпущена библиотека rs-merkle-tree — высокопроизводительная, модульная реализация Merkle-дерева с фиксированной глубиной и строго аппенд-онли.
• Пользователи отметили её применимость в криптографических и блокчейн-сценариях, а также попросили рекомендации по обучающим материалам для новичков в этой области.
• Сообщество отметило, что документация и примеры кода помогут новичкам лучше понять, как использовать Merkle-деревья в сертификатах прозрачности и других примерах.

После 350 лет секретное дипломатическое послание, отправленное Уильямом Первичем из двора Людовика XIV в 1670 году, наконец расшифровали двумя независимыми группами. Ключевую роль сыграли криптографы Мэтью Браун и команда доктора Джорджа Ласри, профессора Норберта Бирманна и Томокио Сато, известные ранее расшифровкой писем Марии Стюарт. Шифр оказался сложным - требовалось определить 20 столбцов и случайным образом переставлять их, а также идентифицировать "нулевые" буквы, которые следовало отбросить.

Расшифровке помогла частота букв - необычное количество "Q" (8 штук), из которых 6 находились у правого поля, указывая на дополнение строк. Для взлома использовали специальное ПО и ручную работу, так как отправитель ошибочно пропустил несколько букв. В тексте остались числовые коды вместо имен и мест, которые невозможно расшифровать без ключа, но содержание уже доступно: жалобы солдат на охлаждение короля к армии и влияние его фавориток.

• Обсуждение началось с предупреждения, что квантовые компьютеры могут расшифровать сегодняшние шифры, и государства-участники уже сейчас собирают зашифрованный трафик для будущего расшифровки.
• Участники обсудили, как в 18 веке шифротекст был вскрыт, и как в статье не упомянули, что именно использовал второй кодовый ломщик, чтобы расшифровать его.
• Была затронута тема, что даже если бы текст был расшифрован, дальнейшие шифры внутри сообщения все еще оставались бы защищенными.
• Участники также обсудили, что в будущем может потребоваться 300 лет, прежде чем квантовые компьютеры смогут быть использоваными на практике.
• И наконец, обсуждалось, что даже 250 лет назад шпионство и манипуляция были обычным делом, и что религиозные предлоги часто использовались для оправдания вторжений и грабежа.

• Сторонники раскрытия решения считают, что знание должно быть доступно всем, в то время как Санборн нуждается в деньгах на лечение и поэтому не может позволить себе бесплатно опубликовать его.
• Покупатель, выигравший аукцион, получит право владения решением, но не право его раскрытия; это вызывает споры о том, что именно он купил и какова ценность этой покупки.
• Покупатель может быть не в состоянии опубликовать решение, потому что это может быть нарушением авторских прав Санборна.
• Вопрос о том, что именно покупатель приобрел, остается открытым: право владения решением или само решение.
• Покупатель может быть не в состоянии раскрыть решение, потому что это может быть нарушением авторских прав Санборна.

Telegram’s end-to-end encryption is vulnerable to sophisticated attacks that could enable large-scale surveillance. Researchers demonstrated that an attacker can exploit weaknesses in Telegram’s MTProto2.0 protocol to recover encryption keys with high probability using relatively few queries. This attack leverages the protocol’s padding mechanism, highlighting a critical design flaw. While official clients may be safer due to open-source scrutiny, third-party clients could be compromised, making this a significant threat. The study also proposes a simple fix to the padding mechanism that would mitigate this risk, suggesting that Telegram’s current encryption needs urgent revision to prevent potential state-level exploitation.

• Обсуждение охватывает уязвимости и риски безопасности в Telegram, особенно в отношении шифрования и возможных бэкдоров.
• Подчеркивается, что атаки требуют скомпрометированного клиента, что значительно снижает непосредственную угрозу для большинства пользователей.
• Отмечается, что сквозное шифрование (E2E) в Telegram по умолчанию отключено для большинства чатов, что увеличивает риски.
• Указывается, что существуют критические уязвимости в реализации шифрования Telegram (MTProto), делая его менее надежным по сравнению с конкурентами.
• Подчеркивается, что даже при использовании E2E, архитектура "клиент-сервер" и зависимость от доверенного сервера представляют фундаментальные риски.

RSA-алгоритм изначально использовал функцию Эйлера φ(n), но со временем её заменили на функцию Кармайкла λ(n). Это изменение незаметно для пользователей, но оно важно: λ(n) делит φ(n) и может уменьшить приватный ключ в 2-3 раза, что ускоряет расшифровку. Однако экономия невелика, так как gcd(p-1, q-1) почти всегда равен 2 или 4.

• Обсуждение поднял вопрос о том, что многие курсы и преподаватели обучают RSA без должного фундамента в теории чисел, что может привести к неправильной реализации.
• Участники обсудили, что вместо того, чтобы вводить студентов в детали реализации RSA, включая использование функции Кармайкла и алгоритма Гарнера, часто вместо этого преподают поверхностное понимание алгоритма, что может в будущем привести к небезопасной реализации.
• Также было отмечено, что вместо того, чтобы обучать эллиптическим кривым, которые более современны и просты в реализации, продолжают преподавать RSA, который требует более глубокого понимания теории чисел.
• Несколько участников выразили обеспокоенность тем, что студенты, обучающиеся по таким курсам, могут в будущем реализовывать небезопасные системы, из-за недостаточного понимания криптографических основ.
• В конце обсуждение сошлось на то, что вместо того, чтобы пытаться упростить обучение криптографии, следует требовать от студентов, что они выучат необходимые математические основы, так как в отсутствии этого они не смогут правильно реализовать безопасные системы.

Автор поднимает тревожный вопрос о возможности намеренного ослабления криптографических стандартов через процесс стандартизации в IETF. Он предполагает, что атакующие, включая государственные структуры вроде АНБ, могут лоббировать принятие уязвимых алгоритмов, маскируя это под законную стандартизацию. Это создаёт риски для безопасности данных, особенно в контексте постквантовой криптографии и гибридных схем.

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

• DJB и другие критикуют предложение NSA отказаться от гибридного постквантового шифрования в пользу только PQ, видя в этом попытку ослабить стандарты безопасности.
• Участники выражают глубокое недоверие к NSA, ссылаясь на прошлые случаи ослабления стандартов (Dual EC, DES) и грязные методы агентства.
• Поднимаются вопросы о реальных целях NSA, поскольку технически подкованные цели и так используют гибриды, а за остальными можно следить через PRISM.
• Отмечается, что формальная жалоба DJB в IETF была отклонена, а процесс стандартизации подвергся критике за грубость и возможную ангажированность.
• Обсуждается, что даже частичное внедрение ослабленного стандарта выгодно разведке, так как увеличивает вероятность перехвата данных со временем.

Седьмой выпуск журнала Paged Out! знаменует расширение его физического присутствия: печатные версии теперь распространяются на кибербезопасностных конференциях и демопати, а также доступны для покупки через print-on-demand сервисы. Редакция перешла на скриптовое оформление обложек для единообразия, сохраняя приверженность работе с художниками-людьми. Выпуск включает разнообразные технические статьи — от анализа уязвимостей в PDF и аппаратных модулей безопасности до экспериментов с WebAssembly и криптографией, включая даже исследование квантовой передачи ключей BB84. Особый акцент сделан на практических решениях, таких как создание самодостаточного распознавателя рукописных цифр и обход ограничений в системах вроде Wayland. Журнал остается бесплатным и открытым для распространения, включая аудиоверсии для слабовидящих.

• Участники высоко оценили журнал Paged Out!, отметив его интересный контент, качественное исполнение и ностальгические отсылки к старым технологиям.
• Обсуждалась конкретная статья о взломе камеры через звуковую волну (стр. 55/58), которая вызвала восхищение и напомнила о загрузке программ с аудиокассет.
• Были подняты вопросы о возможности печатной подписки и получении печатных копий, на которые создатели ответили, что это в планах, но технически сложно из-за параметров печати.
• Один из пользователей сообщил о получении спам-письма от Google Group, на что автор проекта отреагировал просьбой предоставить details для выяснения и решения проблемы.
• Некоторые пользователи выразили желание иметь печатную версию журнала, находя чтение PDF неидеальным, хотя другие отметили его высокое качество.

SSH3 — это новая реализация SSH, построенная поверх HTTP/3 и QUIC вместо традиционного TCP. Она обещает значительно более низкую задержку установки соединения, многопоточность и встроенную поддержку мультиплексирования. Это позволяет ускорить интерактивные сессии, особенно в условиях нестабильных сетей.

Проект также включает улучшенные возможности, такие как передача файлов через HTTP и использование современных криптографических алгоритмов. Уже есть черновик IETF и техническая статья на arXiv, демонстрирующая производительность и совместимость. SSH3 может стать практичной альтернативой для DevOps и удалённого управления.

• Скептицизм по поводу заявлений о скорости: некоторые участники сомневаются в значительном преимуществе SSH3, отмечая, что основная задержка часто связана не с установкой соединения, а с настройкой сессии (PAM и т.д.).
• Критика имени "SSH3" и интеграции в HTTP: многие считают название неудачным и выражают сожаление по поводу поглощения прикладных протоколов HTTP, что увеличивает сложность и потенциальные риски безопасности.
• Обеспокоенность безопасностью и аудируемостью: новая, не испытанная в боях реализация вызывает опасения; участники подчеркивают необходимость тщательного аудита перед использованием в production.
• Вопросы к практической полезности и статусу проекта: обсуждается отсутствие commits за последний год, целесообразность поддержки OAuth для входа на сервер и необходимость таких функций, как миграция соединений.
• Технические аспекты и потенциальные преимущества: отмечается возможность решения проблемы head-of-line blocking за счёт мультиплексирования в QUIC/HTTP3, а также преимущества скрытия сервера за HTTP-прокси.

Dreamwidth Studios использует CAPTCHA для проверки пользователей, чтобы предотвратить автоматизированные запросы и защитить платформу от спама и злоупотреблений. Пользователям предлагается пройти проверку перед выполнением действий, таких как вход в систему или публикация контента. Это стандартная мера безопасности, распространённая на многих веб-сайтах для обеспечения честного использования ресурсов.

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

• Рекомендации по обращению в правоохранительные и государственные программы по борьбе с киберпреступлениями (Калифорния, ФБР) и к юридическому совету компании-владельца сервиса подписания.
• Обсуждение уязвимостей и недостатков цифрового подписания PDF-документов, включая возможность подделки метаданных и необходимость встроенной криптографической проверки.
• Предложения по юридическим действиям: от требования возврата депозита до подачи гражданского иска или уголовного дела за подлог документов.
• Важность наличия нескольких заверенных копий документа (в т.ч. цифровых) на случай спора, по аналогии с традиционной практикой у нотариусов.
• Отсутствие финального разрешения ситуации с агенством на момент обсуждения; автор составляет жалобу в государственный департамент.

PolyGerrit — это веб-интерфейс для работы с системой контроля версий Gerrit, требующий активации JavaScript в браузере для полноценного функционирования. Без него страница не загрузится корректно, и пользователь увидит только это сообщение с просьбой включить скрипты и обновить страницу. Это стандартное требование для современных веб-приложений, обеспечивающее динамическое взаимодействие, такое как просмотр изменений кода, комментарии и код-ревью.

• Добавлена поддержка Valgrind в Go для тестирования криптографического кода на постоянное время выполнения и отслеживания инициализации памяти.
• Обсуждаются преимущества Valgrind для обнаружения утечек памяти и тонких ошибок, несмотря на наличие других инструментов, таких как ASan/MSan.
• Подчёркивается важность аннотаций для корректного анализа неинициализированной памяти, особенно при использовании unsafe-кода или CGO.
• Высказываются опасения, что эффективность зависит от повсеместного использования инструмента всеми пакетами, чтобы избежать большого количества ложных предупреждений.
• Некоторые пользователи выражают скептицизм, считая необходимость в Valgrind признаком недостатков языка, в то время другие видят в этом мощное дополнение к инструментарию.

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

Протокол не навязывает идеологию «свободы слова», вместо этого позволяя каждому ретранслятору устанавливать свои правила модерации, а пользователям — выбирать, что и откуда читать. Nostr поддерживает разнообразные применения: от микроблогов и обмена медиа до децентрализованных рынков, систем совместной работы и даже стриминга. Экосистема активно развивается, предлагая инструменты для создания собственных ретрансляторов и клиентов.

• Критика криптографической безопасности протокола Nostr: уязвимости в аутентификации ключей и проверке подписей, что может позволить атаки типа "человек посередине".
• Отсутствие единой модели федерации релеев: клиенты должны подключаться к множеству релеев для обмена сообщениями, что усложняет пользовательский опыт и разработку.
• Проблема спама и злоупотреблений: отсутствие механизмов противодействия массовой генерации ключей и автоматизированному спаму, а также распространение незаконного контента.
• Смешение философских и технических аспектов: сложность восприятия из-за сочетания политических заявлений ("аполитичный", "про-цензура") с техническими деталями протокола.
• Фрагментация стандартов (NIP) и клиентов: множество реализаций и отсутствие строгой стандартизации затрудняют adoption и создают путаницу для пользователей.

В Unicode существует больше символов, обозначающих «латинскую заглавную букву A», чем букв в английском алфавите. Это наблюдение вдохновило на создание «шифра крика» — замены каждой буквы на один из вариантов A с диакритическими знаками. Например, фраза «SCREAM CIPHER» превращается в «ǠĂȦẶAẦ ĂǍÄẴẶȦ», что выглядит как набор кричащих символов.

Функции SCREAM и unscream реализуют прямое и обратное преобразование, сохраняя при этом регистр и игнорируя не-буквенные символы. Такой подход демонстрирует игривое использование Unicode для создания визуально эффектного, но семантически тривиального шифрования.

• Представлена кодировка zalgo256 с использованием комбинирующих символов Unicode для создания "кричащего" шифра, аналогичного моноалфавитной замене.
• Обсуждаются юмористические и практические аспекты шифра, включая сравнение с ROT13, отсылки к XKCD и потенциальное применение для обхода ограничений длины строк.
• Участники делятся своими реализациями на разных языках (Python, JS, Racket) и идеями по скрытию данных с помощью невидимых символов или эмодзи.
• Поднимаются вопросы безопасности, указывается на отсутствие криптостойкости и обсуждаются технические детали работы с графемными кластерами в Unicode.
• Шифр вызвал оживлённую реакцию, включая шутки о "песчаных людях" из Star Wars и создание чат-ботов для кодирования.

UUIDv47: приватность v4 + производительность v7

Навигационное меню

Платформа:

• GitHub Copilot
• GitHub Spark
• GitHub Models
• GitHub Advanced Security
• Actions
• Codespaces
• Issues
• Code Review
• Discussions
• Code Search

Ресурсы:

• AI
• DevOps
• Security
• Software Development

Open Source:

• GitHub Sponsors
• The ReadME Project
• Topics
• Trending
• Collections

Enterprise:

• Enterprise platform
• GitHub Advanced Security
• Copilot for business
• Premium Support

Поиск кода, репозиториев, пользователей, проблем, pull requests...

Включите мой email для связи

Отмена Отправить отзыв

Сохраненные поиски для быстрой фильтрации результатов

Имя Запрос

Отмена Создать сохраненный поиск

Войти Зарегистрироваться

• Предложены методы маскирования UUIDv7 для скрытия временных меток при внешнем использовании, сохраняя их внутренние преимущества (сортировка, индексация).
• Обсуждается использование шифрования (Speck, AES) или хеширования (SipHash) для обратимой конвертации между внутренним UUIDv7 и внешним UUIDv4-видным идентификатором.
• Рассмотрены альтернативные подходы: разделение на внутренний и внешний ключ, использование ULID, Sqids (ранее Hashids) или кастомного кодирования.
• Подняты вопросы о практической необходимости скрытия временных меток и рисках (безопасность, корреляция данных для деанонимизации).
• Отмечены проблемы совместимости, сложности реализации и потери некоторых преимуществ UUIDv7 для потребителей API.
• Затронуты технические аспекты: генерация на клиенте, визуальное сравнение UUID, необходимость отдельного поля с временем для клиента.
• Упомянуты связанные проекты и алгоритмы: uuidv47, ULID, Speck, метод из blog.notdot.net.

Зачем «перефразировать телеграмму»?

Во Второй мировой на американских телеграммах встречается пометка:
«This telegram must be closely paraphrased before being communicated to anyone».

Смысл не в «размывании» содержания, а в криптографической безопасности.
Если дословно цитировать текст, противник, перехвативший шифр-телеграмму, получает известный открытый текст («crib»). Сравнивая его с шифртекстом, криптоаналитикам легче подобрать ключ.

Поэтому требовалось переформулировать каждую фразу, сохраняя смысл, но меняя слова и порядок. Это лишало врага «ключевых подсказок» и затрудняло взлом.

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

• Британцы использовали «саженые» открытые тексты в карманах погибших немцев для known-plaintext атак на Enigma.
• Повтор одних и тех же фраз («weather…», «Heil Hitler») и «сообщения в глубину» (in depth) позволяли взламывать и Enigma, и более сложный Lorenz/Tunny.
• Ключевое правило: нельзя повторять один и тот же текст ни в открытом, ни в зашифрованном виде; при перефразе лучше сокращать, чем расширять.
• Современные шифры устойчивы к таким атакам благодаря IV, CBC и другим приёмам; изучать старые методы помогают военные руководства и книги вроде «Between Silk and Cyanide».

Почему квантовые компьютеры всё ещё не разложили 21 на множители?

В 2001 году удалось разложить 15, но к 2025-му 21 остаётся «недоступным». Это не из-за отсутствия прогресса, а из-за взрывного роста сложности схемы.

• Схема для 15 требует всего 21 запутывающий двух-кубитный гейт (6 CNOT/CPHASE + 2 Toffoli, каждый из которых эквивалентен 6 CNOT).
• Схема для 21 содержит 191 CNOT и 369 Toffoli, то есть ≈ 2405 запутывающих гейтов — в 115 раз больше.

Три причины такой разницы:

1. Большинство констант при 15 равны 1, поэтому умножения «пропускаются».
2. Первое умножение почти бесплатно, так как аккумулятор известен.
3. Оставшееся умножение на 4 по модулю 15 сводится к двум CSWAP.

Для 21 все восемь умножений нужны, и каждое требует полноценного модульного умножения. Даже после агрессивной оптимизации схема остаётся на два порядка дороже.

• Квантовые компьютеры пока не факторизуют даже 21 без «подсказок»; эксперименты с 15 обошлись лишь потому, что задача свелась к сдвигам.
• Для RSA-2048 оценивается ≈ 7 млрд Toffoli-гейтов и миллионы логических кубитов с коррекцией ошибок; RSA-1024 всё ещё вне досягаемости.
• Реальные препятствия — экспоненциальный рост шума и количества физических кубитов, а не просто масштабирование схемы.
• Основной практический путь — квантовая химия и симуляция, а не взлом криптографии; «пост-квантовые» алгоритмы уже снижают мотивацию строить «крипто-разрушители».
• Общий вывод: полезные квантовые вычисления в XXI веке возможны, но факторизация крупных RSA-ключей остаётся гипотетической.

Сертификаты для onion-сервисов

Onion-сервисы изначально не нуждаются в TLS-сертификатах, так как Tor уже обеспечивает шифрование и аутентификацию. Однако при доступе через HTTPS-прокси или при желании показать «зелёный замок» можно выпустить сертификат.

Возможные варианты

1. DV от публичного CA

   • Let’s Encrypt, DigiCert и др. поддерживают домены .onion.
   • Потребуется подтвердить владение onion-доменом через ACME (HTTP-01 или DNS-01).

2. Собственный CA

   • Генерируем корневой сертификат и подписываем им конечные.
   • Подходит для внутренних или тестовых сервисов; клиенты должны добавить корень в доверенные.

3. Self-signed

   • Быстро, но вызывает предупреждение браузера.
   • Использовать только для разработки.

Практика с Onionspray

• Встроенный модуль onionspray-cert автоматизирует выпуск Let’s Encrypt.
• Для собственного CA:

  onionspray root-ca init
  onionspray cert issue <onion-address>
  

• Готовые сертификаты складываются в ./certs/.

Проверка

• Публичный DV: открыть onion-сайт в Tor Browser — замок зелёный.
• Свой CA: импортировать rootCA.pem в браузер/ОС.

Кратко

• Для публичных проектов — Let’s Encrypt.
• Для частных — собственный CA.
• Self-signed только для тестов.

• Участники спорят, нужны ли onion-сайтам сертификаты CA, ведь адрес .onion уже криптографически привязан к публичному ключу.
• Основной аргумент «за» — совместимость: браузеры и стандарты (HTTP/2, платежи) требуют TLS-сертификат, чтобы включить расширенные функции.
• RFC 9799 описывает расширения ACME для выдачи таких сертификатов, включая возможность связывать обычные домены и .onion-адреса одним ключом.
• Критики считают это «политическим» требованием: шифрование уже есть, но из-за «TLS повсюду» приходится накладывать лишний слой.
• Практический вывод: для публичных сервисов сертификат нужен, чтобы «вписаться» в экосистему; для приватных каналов достаточно TOFU или ручной проверки.

Кратко
PyPI теперь ежедневно отслеживает, не истёк ли домен, к которому привязан e-mail пользователя. Если домен переходит в «период искупления» (redemption), адрес автоматически становится «неподтверждённым», что блокирует атаку «воскрешения» домена и захват аккаунта через восстановление пароля. С июня 2025 г. таким образом аннулировано более 1 800 адресов.

Как работает атака

1. Владелец забывает продлить домен.
2. Злоумышленник выкупает домен, поднимает почту, запрашивает сброс пароля PyPI.
3. До внедрения 2FA (до 1 янв 2024) это давало полный доступ; теперь нужно ещё обойти второй фактор, но риск остаётся.

Жизненный цикл домена
Активен → дата окончания → льготный период (до 45 дней) → redemption (30 дней, высокая цена) → 5 дней «pending delete» → освобождение. PyPI проверяет статус раз в 30 дней через API Domainr и действует до момента смены владельца.

Что делает PyPI

• С апреля 2025 ежедневный мониторинг.
• При переходе в redemption статус e-mail меняется на «unverified».
• Пользователю приходит уведомление; повторное подтверждение возможно только после продления домена.

Совет пользователям

• Продлевайте домены заранее.
• Используйте надёжный почтовый сервис с авто-продлением.
• Добавьте резервный подтверждённый адрес на стабильном домене.

• Проблема повторного использования email-адресов после удаления аккаунтов ставит под угрозу цифровую идентичность и безопасность пакетов (Maven, Go).
• Google и Microsoft по-разному подходят к блокировке «мертвых» доменов и email, но единого стандарта нет.
• URI-импорты и доменные namespace кажутся хрупкими: домен может истечь, а пакет — подмениться.
• Сильная криптографическая идентичность (PGP, Keybase, SigSum) технически решена, но не взлетела из-за UX, потери ключей и репутационных проблем крипто-мира.
• Участники сходятся во мнении: нужно что-то простое, децентрализованное и без единой точки отказа, но пока нет рабочего массового решения.

XR2000 — новый программистский квест в жанре научной фантастики.
Он объединяет бинарные протоколы, криптографию и развёрнутый сюжет, который пока охватывает лишь первую главу. Дальнейшее зависит от интереса участников.

Вдохновение дали:

• TIS-100 — псевдоассемблер в игровой форме.
• Space Traders — космическая торговля через REST API.
• Protohackers — челленджи по сетевым протоколам.

Старт:

nc clearsky.dev 29438

Приятного погружения!

• Участники делятся ссылкой на похожий Sci-Fi-контест 2006 года, где нужно писать собственную VM.
• Появился новый TCP-пазл на clearsky.dev:29438; при подключении требуется отправить 0-байт + «XR2K» для документации.
• Сервер перегружен HN, поэтому текст иногда не выводится или после команды ничего не происходит.
• Некоторые пробуют использовать LLM для упрощения игры.
• Один из игроков ждёт ответа «Colonel Arhci» по atlantiamail.