Как организовать шифрование на уровне протокола? На самом деле тема непростая и пожалуй (имхо) это как раз та самая тема, где прийти к компромиссу почти никогда не получается. Разве что просто не передавать чувствительные данные вовсе.
Я расскажу как шифрование можно организовать на уровне протокола brec и ни в коем случае не буду затрагивать те самые принципиальные решения, влияющие на безопасность (как передавать, куда передавать, отправлять ли, и хранить ли чувствительные данные вовсе). Иными словами нас интересует инструментальная сторона вопроса.
Итак в brec есть две дополнительные возможности: crypt и PayloadContext. Если crypt — это фича, которую нужно активировать, то контекст — это встроенный инструмент, который не обязательно должен быть связан с шифрованием, но без него организовать шифрование будет весьма накладно. Поэтому вначале коротко о том, что такое контекст и зачем он нужен.
Итак вы объявили простой протокол
use brec::prelude::*; use serde::{Deserialize, Serialize}; use std::io::{Error, ErrorKind}; #[block] pub struct MetaBlock { pub request_id: u32, pub level: u8, } #[payload] #[derive(Serialize, Deserialize)] pub struct GreetingPayload { pub message: String, }
Давайте объявим примитивный контекст
#[payload(ctx)] pub struct CounterContext { pub encoded: u32, pub decoded: u32, } impl CounterContext { fn extract<'a>(ctx: &'a mut crate::PayloadContext<'_>) -> std::io::Result<&'a mut Self> { match ctx { crate::PayloadContext::CounterContext(ctx) => Ok(ctx), crate::PayloadContext::None => Err(Error::new( ErrorKind::InvalidInput, "GreetingPayload expects PayloadContext::CounterContext", )), } } fn inc_encoded<'a>(ctx: &'a mut crate::PayloadContext<'_>) -> std::io::Result<()> { Self::extract(ctx)?.encoded += 1; Ok(()) } fn inc_decoded<'a>(ctx: &'a mut crate::PayloadContext<'_>) -> std::io::Result<()> { Self::extract(ctx)?.decoded += 1; Ok(()) } }
Объявляем контекст мы с помощью макроса payload(ctx), который говорит brec — сделай из этой структуры контекст для всех моих Payload. Да, тут стоит упомянуть что контекст это про Payload, но не про Blocks.
Вот этот взявшийся ниоткуда «тип» crate::PayloadContext будет сгенерирован brec и включать наш контекст как crate::PayloadContext::CounterContext(ctx), то есть вы можете иметь несколько разных контекстов.
Теперь стоит обратить внимание на то как мы объявили чуть выше GreetingPayload. Если вы посмотрите на эту статью, то увидите разницу: вместо payload(bincode), мы указали лишь payload. Тем самым мы сказали brec — не применяй никаких встроенных кодеков (bincode — как раз ссылка на кодек), мы имплементируем его самостоятельно. Ниже я всё равно использую bincode внутри ручной реализации, но для brec это уже не встроенный кодек, а просто наш собственный код.
Это не сложно.
impl GreetingPayload { fn to_bytes(&self) -> std::io::Result<Vec<u8>> { bincode::serde::encode_to_vec(self, bincode::config::standard()) .map_err(|err| Error::new(ErrorKind::InvalidData, err)) } fn from_bytes(buf: &[u8]) -> std::io::Result<Self> { let (payload, _): (Self, usize) = bincode::serde::decode_from_slice(buf, bincode::config::standard()) .map_err(|err| Error::new(ErrorKind::InvalidData, err))?; Ok(payload) } } impl PayloadEncode for GreetingPayload { fn encode(&self, ctx: &mut Self::Context<'_>) -> std::io::Result<Vec<u8>> { // Увеличим счётчик CounterContext::inc_encoded(ctx)?; // Кодируем наш Payload self.to_bytes() } } impl PayloadEncodeReferred for GreetingPayload { fn encode(&self, _ctx: &mut Self::Context<'_>) -> std::io::Result<Option<&[u8]>> { // Это можно имплементировать опционально, если хотим "дешёвый" доступ к нашим данным, что // увы не всегда возможно Ok(None) } } impl PayloadDecode<GreetingPayload> for GreetingPayload { fn decode(buf: &[u8], ctx: &mut Self::Context<'_>) -> std::io::Result<GreetingPayload> { // Увеличим счётчик CounterContext::inc_decoded(ctx)?; // Декодируем наш Payload Self::from_bytes(buf) } } impl PayloadSize for GreetingPayload { fn size(&self, _ctx: &mut Self::Context<'_>) -> std::io::Result<u64> { // Реализуем возможность узнать размер Payload Ok(self.to_bytes()?.len() as u64) } } impl PayloadCrc for GreetingPayload { // Это зачастую не нуждается в собственной имплементации. // Достаточно дефалтного } // Всё готово, вызываем генератор, который подвезёт // - `Block` // - `Payload` // - `Packet` // - `PayloadContext<'a>` // - `PacketBufReader` // - `Reader` / `Writer` brec::generate!();
Думаю, что из этого кода теперь ясно видно за что именно отвечает контекст. Довольно тривиальная задача — расшарить данные между итерациями кодирования/декодирования без необходимости наличия глобальных сущностей. На практике эта тривиальная задача может превратиться в огромную головную боль, brec же содержит решение уже в коробке.
И тут важная деталь: контекст не делает состояние «скрытым» или «глобальным». Наоборот, он заставляет вас явно принести это состояние в точку чтения или записи. Это удобно и для тестов, и для producer/consumer кода: если payload требует дополнительных runtime‑данных, это видно прямо в API, а не спрятано где‑то в синглтоне.
И при чём тут шифрование? А как же нам ключи хранить? Не глобально же держать в памяти. Вот здесь как раз тот самый «мостик» к фиче crypt, которая активно использует контекст. Но прежде оговоримся — шифрованием покрывается только Payload. Это осознанное решение. Block'и остаются без шифрования всегда, как своего рода индекс для эффективного и быстрого поиска данных.
На первый взгляд это может казаться странным: если уж шифровать, то почему не всё сразу? Но в протоколе часто есть два разных слоя данных. Payload — это содержимое, где обычно и живёт чувствительная информация. Block'и — это метаданные, по которым удобно быстро фильтровать, маршрутизировать, искать и пропускать пакеты без полной распаковки. Если зашифровать всё целиком, то каждый такой сценарий потребует сначала расшифровать пакет, а значит потерять часть практической пользы от структуры протокола. Поэтому правило простое: чувствительное — в Payload, индексирующее и безопасное для раскрытия — в Block.
Итак добавляем фичу и вновь объявляем наш протокол
[dependencies] brec = { version = "...", features = ["bincode", "crypt"] } serde = { version = "1.0", features = ["derive"] }
use brec::prelude::*; use serde::{Deserialize, Serialize}; #[block] pub struct MetaBlock { pub request_id: u32, pub level: u8, } #[payload(bincode, crypt)] #[derive(Serialize, Deserialize)] pub struct GreetingPayload { pub message: String, } brec::generate!();
Обратите внимание как теперь мы объявили GreetingPayload, а именно через payload(bincode, crypt). Во‑первых, мы указали на использование встроенного кодека bincode, чтобы не писать кодек самим. Во‑вторых, мы указали через crypt, что GreetingPayload требует шифрования. При этом шифрование остаётся выборочным: payload'ы без crypt могут жить в том же протоколе и не требовать криптографического контекста.
Давайте посмотрим как теперь с этим работать
const EXAMPLE_PUBLIC_KEY_PEM: &str = r#"-----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY-----"#; const EXAMPLE_PRIVATE_KEY_PEM: &str = r#"-----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY-----"#; const KEY_ID: &[u8] = b"some_crypt_demo-key"; fn encode( message: String, request_id: u32, level: u8, ) -> Result<Vec<u8>, Box<dyn std::error::Error>> { // Создадим пакет. Никакого шифрования. let mut packet = Packet::new( vec![Block::MetaBlock(MetaBlock { request_id, level })], Some(Payload::GreetingPayload(GreetingPayload { message, })), ); // Теперь создадим контекст, который нам стал доступен при активации фичи `crypt` let mut encrypt = EncryptOptions::from_public_key_pem(EXAMPLE_PUBLIC_KEY_PEM)? .with_key_id(KEY_ID.to_vec()); let mut encrypt_ctx = PayloadContext::Encrypt(&mut encrypt); // Записали пакет, наш GreetingPayload внутри пакета будет зашифрован let mut bytes = Vec::new(); packet.write_all(&mut bytes, &mut encrypt_ctx)?; Ok(bytes) } fn decode( bytes: Vec<u8>, ) -> Result<Packet, Box<dyn std::error::Error>> { use std::io::Cursor; // Создаём контекст для декодирования let mut decrypt = DecryptOptions::from_private_key_pem(EXAMPLE_PRIVATE_KEY_PEM)? .with_expected_key_id(KEY_ID.to_vec()); let mut decrypt_ctx = PayloadContext::Decrypt(&mut decrypt); // Читаем пакет let mut source = Cursor::new(bytes.as_slice()); let mut reader = PacketBufReader::new(&mut source); match reader.read(&mut decrypt_ctx)? { NextPacket::Found(packet) => Ok(packet), NextPacket::NotEnoughData(_) => Err("unexpected read status: NotEnoughData".into()), NextPacket::NoData => Err("unexpected read status: NoData".into()), NextPacket::NotFound => Err("unexpected read status: NotFound".into()), NextPacket::Skipped => Err("unexpected read status: Skipped".into()), } }
Конечно для компактности примера наши ключи лежат в памяти, лежат статично. Но это лишь демонстрация. На практике вы создаёте EncryptOptions / DecryptOptions, передаёте в producer / consumer и не вспоминаете. То есть ключевой материал и политика шифрования принадлежат вашему приложению, а PayloadContext просто аккуратно доносит их до payload‑кодека в момент записи или чтения.
И здесь вполне честно возникает вопрос: а зачем вообще активировать crypt, если можно сделать payload с полем bytes: Vec<u8>, зашифровать эти байты где‑то снаружи, а потом уже передать их в brec? Это абсолютно рабочий путь. Более того, в большом количестве систем именно так и делают: протокол видит просто bytes, а криптографический слой живёт отдельно. Если у вас уже есть такой слой, он проверен, покрыт аудитом, умеет ротацию ключей, версионирование, key id, envelope‑формат и ошибки, то переход на модель brec + crypt не имеет явных предпосылок.
Смысл crypt не в том, что без него шифрование невозможно. Смысл в том, что brec берёт на себя повторяющуюся и неприятную протокольную часть: сериализовать payload, завернуть его в единый crypto envelope, записать туда версию, алгоритм, session id, RSA‑wrapped session key, nonce, ciphertext/tag и опциональный key_id, а на чтении проверить всё это в обратную сторону. Иными словами crypt убирает из прикладного кода самодельный контейнер вокруг Vec<u8>. Вы продолжаете работать с типизированным GreetingPayload, а не с «мешком байт», который надо не забыть расшифровать, проверить, распарсить и правильно сопоставить с ключом.
Да, любая встроенная криптографическая фича расширяет поверхность кода, который должен быть корректным. Это не бесплатная магия. Но альтернатива с ручным bytes тоже расширяет поле для ошибок, только уже в каждом конкретном приложении: кто‑то забудет key id, кто‑то не заложит версию envelope, кто‑то будет неочевидно переиспользовать сессионный ключ, кто‑то смешает ошибки декодирования и ошибки расшифровки. В brec этот риск концентрируется в одном небольшом и явном месте, где используются готовые примитивы (ChaCha20Poly1305 для payload body и RSA‑OAEP‑SHA256 для session key), есть формат envelope и единая модель ошибок. Поэтому выбор тут прагматичный: если вам нужен полный контроль или уже есть свой криптографический слой — используйте Vec<u8> и ручной путь. Если же вам нужно шифрование именно как часть brec‑протокола, без размазывания boilerplate по producer/consumer коду, crypt даёт более ровный и проверяемый маршрут.
Утомлять более техническими деталями и перечнем поддерживаемых методов и конфигурации для EncryptOptions / DecryptOptions я не буду, для этого есть документация, но как всегда, призываю поделиться «звездочкой» на GitHub. Для вас это просто клик, а для меня — обратная связь и мотивация не забрасывать проект, а развивать его дальше. Заранее лучи добра и света каждому, кто не пройдёт мимо. ЗЫ: каждый раз, когда прошу отметить проект звездой на GitHub, чувствую себя как onlyfuns модель ) только вот показывать кроме кода особо и нечего ) В общем поддержите, если не трудно, если трудно, то и не надо )
Спасибо.
Комментарии (12)
gerbert_MX
28.05.2026 14:22Из интереса закопался в исходный код (интересен сам алгоритм) и по состоянию на последний коммит f4228c5 вот список вопросов/фактов
не совсем понятно почему не запаковалось это все в динамические библиотеки (dll/so) раз уж начали делать интеграции, вместо этого неочевидный cli который еше может дрейфовать если продукт будет развиваться
не совсем понял за фишку с "смешанным потоком", я думал там что-то по типу "размазывания шума" что бы сами данные не были видны (очень актуально сейчас), но там классическая классика с сигнатурой+crc
так же вообще не понял за механику хранилища, я думал то такой странный кольцевой буфер для асинхронных ридеров, даже неронку зарядил на анализ, но оказалось что это просто хранилище? Зачем вшитое хранилище в потоковый криптопротокол? И я не увидел никаких ограничений на память при запуске (как параметр) то есть вполне можно убивать удаленные машины просто забив память отсылая пустые данные этим протоколом
подозрительно встречающиеся unsafe, для такой задачи (учитывая что никакой магии с байтами я не заметил) это очень похоже на костыли которые воткнули "чтоб работало" что в разрезе криптопротокола интересно смотрится, особенно если добиться колизии адресов при перезапуске тулзы(где в основном unsafe и юзается)
уязвимость прямо из учебника - берется len из полученного пакета и по этому len сразу резервируется память. Как минимум крашнуть тулзу можно и вызвать потери пакетов, как макс память выделится на всю оперативку и комп зависнет (никаких ограничений в рамках самой тулзы на лимиты памяти нет, напомню)
таки я был не прав и сделано нормально с симетричным на тело и асиметричным на обмен, но как же оно сделано! Ротация ключей сделана на лимите. Я искал другие механизмы начиная от принудительного рукопожатия по требованию и заканчивая сбросом лимита по условиям (размер, частота битости, иное) но такого нет, строго лимит и все.
в продолжение вышеперечисленного - шифрование ничего не гарантирует и ни от чего не защищает. Я выше писал что распознание по сигнатуре+CRC и это не опечатка - используется не префикс и даже не правило чтоб не палится с префиксом, а тупо тело. Незашифрованное хочу заметить тело (перепроверил нейросетью, метаданные гарантировано не шифруются)
Резюмируя - как учебный проект на поиграться очень топово и разнопланово. Все мы таким занимались когда-то в своей жизни если программирование действительно интересно.
Но как реально используемый проект/алгоритм под вопросом потому что я даже не могу придумать где такое можно было бы использовать что бы оно было прямо таки преимуществом и/или в тему.
AlexWriter Автор
28.05.2026 14:22Я благодарен вам за ответ и за то, что вы нашли время пройтись по коду. Это уже тянет не на комментарий, а на полноценное ревью, и за это правда спасибо. Оценку вроде “ученический проект” я оставлю за скобками: это, что называется, навешивание ярлыков, а не технический аргумент. Увы, в нашей среде такое встречается чаще, чем хотелось бы. Но выбранный вами тон комментария не отменяет того, что часть замечаний полезна и заслуживает отдельного разбора.
Давайте разбираться.
Вначале про контекст - это важно. Во многих местах документации, равно как и в статьях про brec упоминается наиболее подходящий сценарий его использования (по мнению автора) - логирование (логи, трейсы, метрики и вот весь этот зоопарк). Я много работал с DLT, работал с protobuf и flatbuffer, где данные собирались со множества устройств и это были гигобайты данных, которые потом приходилось анализировать и фильтровать. Собственно фильтрация была основной болью. Особенно это актуально для DLT-like протоколов, где можно (но не всегда просто) заглянуть “до” полного парсинга. Под каждый кейс приходилось пилить какой-то “особенный заглядыватель”, а если уж протокол обновился - всё, пиши пропало. Отсюда и основная идея проекта - блоки + полезная нагрузка, где блоки - это “открытый” индекс. То есть проект родился, простите, не как ученический, а как попытка обойти боль )) Причем brec не отменяет тот же DLT, protobuf, flatbuffer и прочих. Brec может быть “индексной” обёрткой - блоки как индекс, а payload может хранить хоть JSON, хоть байты DLT или protobuf.
Этим же контекстом диктовался и дизайн storage, хранящим данные по слотам для быстрого доступа к нужным участкам записей. Хочу записи от 100 000 до 100 042 - вот пожалуйста. Быстро и без магии.
Откуда фигня с шифрованием, если речь о логах? Тут просто. Компании, с которыми приходилось поработать, очень любят класть какую-нибудь гадость в логи. Говоришь им “фу! кака!”, а они всё равно кладут. И логика на самом деле ясна и проста. Во время разработки какой-нибудь приблуды, которая потом будет отвечать за работу приблуды в машине, данных нужно собрать будь здоров и как раз в режиме dev совершенно нормально часть секретиков пихать прямо в логи. У разрабов есть ключ - откроют. Конечно, на проде, когда вафля уже выпущена - такой дичи нет. Но вот во время разработки, когда за ночь легко набегает под терабайт диагностических данных - легко. И шифрование здесь используется как компромисс своего рода, когда разные подрядчики могут работать над массивом данных, но не всегда видеть всё.
Теперь предметно.
За замечание по поводу максимальных размеров - огромное спасибо. Это моё упущение, я об этом не подумал. Честно создал по мотивам два тикета: тыц, тыц. Правда, задача там шире, чем просто default-значение поправить, но буду разбираться. Вы смотрите с перспективы - “как сломать, если захотеть?”, я же честно смотрел с логики прикладного применения в “безопасной” зоне. Это ни в коем случае не отменяет ценности замечания. Тикеты созданы, возьму в работу.
По мотивам замечаний к самой фиче шифрования тоже сделал тикет, чтобы не забыть и подумать.
Про TLS. Это не сюда всё-таки. Это про транспорт. Сравнивать напрямую скорость TLS и
brec cryptне корректно, потому что это разные слои и разные задачи: TLS защищает канал, аbrec cryptзащищает payload внутри самого формата, включая сценарии storage, где TLS уже закончился.Это замечание “шифрование ничего не гарантирует и ни от чего не защищает” я честно не понял. Про то, что шифруется только payload, сказано в статье и документации. Это осознанное решение. Сама библиотека не кладёт в открытые блоки никаких чувствительных данных; блоки содержат только то, что пользователь протокола сам объявил как открытый индекс. Каким образом это убивает защиту самого payload - я не понимаю. Это не отличается от рабочей схемы, где в protobuf-сообщении шифруется отдельное поле, а остальные поля остаются открытыми. Или я, может быть, не понял, в чём вопрос?
Если посмотрите тикеты, я специально для ясности добавил туда пояснения по мотивации - почему было сделано так или иначе. Это тоже очень важно. И в части шифрования мне пришлось пойти на компромиссы ради производительности. Но вот то, что нужно сделать более гибко настраиваемым - тут я полностью согласен. Как и говорил, тикет создан, но пойдёт как улучшение - уязвимости я не вижу.
Почему не BLAKE3? В текущей схеме SHA-256 используется как часть RSA-OAEP-SHA256, то есть как стандартный и широко поддержанный параметр для обёртки сессионного ключа, а не как самостоятельная попытка выбрать “самый быстрый хеш”. О BLAKE3 думал, но это уже скорее отдельный crypto profile / algorithm option, который можно добавить позже по запросу. В идеале было бы здорово это дело настраивать, но так, чтобы не тянуть кучу зависимостей, а именно на этапе генерации определять “кого” и тянуть только его, чтобы не раздувать бинарник.
Насчёт скорости в боевых условиях. Я честно включал фичу шифрования в бенч. Скрывать ничего не пытаюсь. Конечно, шифрование не бесплатно, но и результаты выглядят вполне недурно. И вообще, если вы посмотрите именно на производительность - я там обманывать никого не пытаюсь, а совершенно честно говорю те сценарии, где brec выигрывает и где проигрывает. И если выигрывает, то честно говорю про цену.
Про unsafe. Тут я словил скример от вас ) Проверил… в crypto-core unsafe нет. В генераторе unsafe действительно встречается в zero-copy / referred path и низкоуровневом копировании байт, а в интеграциях - на FFI/JNI границах (об этом ниже). То есть это не часть криптографической схемы как таковой, но место для отдельного аудита, да.
Вы заглянули в интеграции. Спасибо конечно. Но эту часть я пока не готов анонсировать и этого не делал. Эта часть ещё требует доработок и осмысления, там много проблем и нерешённых архитектурных вопросов. Кэширование для Java - вообще черновик, а C# я даже не решил, оставлю ли в проекте в принципе. И да, вы правы… Если в Node и WASM у меня была возможность более внимательно посмотреть, то в части Java и C# - это чистые MVP. Весь фокус всё-таки был на ядре и генераторе. Про CLI в этой части я всё-таки считаю, что вариант вполне рабочий - не вижу проблемы. Мотивация за этим тоже стоит вполне ясная - интеграция разделена на несколько слоёв: слой кодека, когда мы в принципе можем прочитать сообщение, и слой генерации типов под платформу + биндинг (CLI только про этот слой, и он опциональный). Что касается потенциального кошмара в поддержке интеграции, то да - это риск. Но именно для этого все интеграции вынесены в свои крейты, отделены максимально от ядра и живут своей жизнью. Иными словами, апдейтить интеграцию с Node в 98-99 случаях из 100 можно не трогая ядро. Слой клея там есть, но очень тонкий. Но повторюсь - по интеграции есть много нерешённых архитектурных вопросов, о которых я бы пока предпочёл не говорить.
Про “смешанный поток” или “размазывание шума”. Может, я не совсем чётко артикулировал в статье и документации. Доки перепроверил - речи не идёт о том, что brec может собрать своё сообщение по частям. Речь о том, что может найти целое блюдце в мусорном баке. Но найти среди осколков и склеить битое - нет, не сможет. Этого нигде не заявлено и задачи такой не было.
Если что-то упустил - спрашивайте, я с радостью отвечу. Всегда приятно отвечать на умные вопросы от умных людей, но давайте попробуем без ярлыков ;)
gerbert_MX
28.05.2026 14:22Не планировал как то оскорблять или навешивать ярлыки, просто написал как думаю
а теперь по пунктам:
я не владею растом, пробовал много раз, но мне сложного и не очевидного синтаксиса и в Си хватает, потому мог что-то просто криво понять
TLS это не просто транспорт, как и protobuf это не просто gRPC. Если вам нужно безопасно хранить логи клиента то храните, в чистом виде что получили то и храните. При этом куча фишек сразу идет в комплекте причем не только критографических.
-
За хранение:
Статья написана про протокол, в репе сказано за протокол. Я пытался понять зачем хранение в транспортном протоколе. Обычно если делают модуль то разделяют зоны ответственности, то есть транспорт отдельно, хранение отдельно. Вместе это уже какая-то тулза что состоит из отдельных модулей.
По хранению рекомендую посмотреть на как сделано cockroachdb/pebble дам довольно просто и очевидно, потому как ваше простое хранение по фиксированному массиву спорное решение для вашей же задачи когда надо прокидывать и читать странные логи.
Во-первых хранение не массивами, а фиксированными чанками,что бы оно ровно в памяти лежало и проще читалось на произвольные размеры.
Во-вторых как раз лучше разорвать шифрование транспорта и шифрование хранилища, для того что бы расшифрованное нарезать по чанкам, а чанки жать и уже результат шифровать. Даже если все in-memory то оперативка не бесконечная, а зашифрованное не сожмется так как расшифрованное особенно если это логи которые можно сжать и в х20 если повторов много.
По кривому шифрованию как минимум у вас в отрытых данных длинна и как убить комп подменив всего пару байт в потоке я писал выше. Было бы у вас еще по хешу проверка целостности, а не CRC32 то можно было бы "помолившись забить" но так вектор атаки настолько очевиден, что подсознательно кажется что это приманка (например 16 байт с зашифрованного блока это скрытая хеш-сумма всего пейлоада, что бы детектить мамкиных хакеров еше на этапе анализа инфраструктуры)
За интеграции я потому и написал за подключаемые библиотеки. Вы со своей стороны собрали бинарь, а дальше как с ним будут работать не ваши половые трудности. Если простыми словами, то dll/so это "стариковский WASM для десктопов". Потому как CLI это не сильно безопасно и вообще не кроссплатформенно. Я вот например свои пет-проекты если делаю как "универсальный" CLI то собираю 38 бинарей (linux/amd64, linux/arm64, linux/arm/v7, linux/arm/v6, linux/386, linux/mips, linux/mipsle, linux/mips64, linux/mips64le, linux/ppc64, linux/ppc64le, linux/riscv64, linux/s390x, windows/amd64, windows/arm64, windows/arm/v7, windows/386, macos/amd64, macos/arm64, freebsd/amd64, freebsd/arm64, freebsd/arm/v6, freebsd/arm/v7, freebsd/386, openbsd/amd64, openbsd/arm64, openbsd/arm/v6, openbsd/arm/v7, openbsd/386, netbsd/amd64, netbsd/arm64, netbsd/arm/v6, netbsd/arm/v7, netbsd/386, android/amd64, android/arm64, android/arm/v7, android/386) и это самые популярные и беспроблемные (то есть собирается прямо в actions github) потому как предусмотреть все нереально, а ковыряться со сборкой до бума с ИИ редко бы кто стал.
А за логи я вам писал в другом вашем посте развернуто. Как лучше хранить и агрегировать. По поводу "небезопасных данных" - если сами разрабы, кто писали логи, такие "индусы" то просто сделайте тонкий клиент-обфускатор что будет работать в потоке и все. Все равно нежные данные должны как то помечатся - задетектили, обрезали середину, добавили звездочек и вот уже открыто переданный пароль нечитаем для стороннего чтения. Потому как шифрование это полумеры и вы этим лечите чужие ошибки своими костылями. Но вообще за такое безопасники беседуют без смазки со всеми причастными вплоть до увольнений.
AlexWriter Автор
28.05.2026 14:22Послушайте, я внимательно прочитал все ваши комментарии. К сожалению, с должным вниманием - только сейчас.
Что могу сказать: спасибо за прогонку репозитария через ИИ и найденное потенциально уязвимое место. Давайте только для читателей оговоримся, что речь именно о потенциальной уязвимости в сценарии недоверенного входного потока, а не о подтверждённом баге. По этому поводу я уже создал тикеты и буду разбираться.
В остальном, простите, это всё больше похоже на поток общих рассуждений вокруг темы. Если читать по диагонали - выглядит внушительно. Если читать внимательно - многие тезисы либо не относятся к статье, либо подменяют постановку задачи, либо спорят с тем, чего я не утверждал, либо вовсе отменяют реальность - это откровенный флуд. И честно это совсем не характеризует вас, как человека действительно в теме.
Поэтому предлагаю так: если у вас есть конкретные технические замечания по
brec- на GitHub есть вкладка Issues и кнопка New Issue. Воспроизводимый сценарий, входные данные, ожидаемое/фактическое поведение - и я с радостью разберу.А вашей продуктивности остаётся только завидовать: на Хабре меньше месяца, а уже больше полутора сотен объёмных комментариев :) Но увы ни одной статьи про ваши "миллион-миллионов бинарей". Я бы с радостью почитал... отправьте ping, как появится.
Удачи!
gerbert_MX
28.05.2026 14:22Я бы сказал что вы слишком серьезно воспринимаете жизнь, но странно такое писать про человека которому комментарии ИИ пишет
В целом сложилось такое впечатление что я вам своими комментариями непоправимую ментальную травму нанес, что очень странно слышать от настолько старого аккаунта (хотя аккаунтами как и кармой свободно торгуют, причем недорого)
Если вы так плохо воспринимаете критику (а ее и не было как таковой), то не публикуйтесь, что бы поберечь свое ментальное здоровье.
Удачи!
AlexWriter Автор
28.05.2026 14:22я не владею растом, пробовал много раз, но мне сложного и не очевидного синтаксиса и в Си хватает, потому мог что-то просто криво понять
и как же это соотносится с этим?
Из интереса закопался в исходный код (интересен сам алгоритм) и по состоянию на последний коммит f4228c5 вот список вопросов/фактов
вы либо крестик снимите, либо … ну это… что бы факты уверено раздавать
TLS это не просто транспорт, как и protobuf это не просто gRPC. Если вам нужно безопасно хранить логи клиента то храните, в чистом виде что получили то и храните. При этом куча фишек сразу идет в комплекте причем не только критографических.
Вы о чем вообще здесь говорите? Что значит “protobuf это не просто gRPC”? Что “помидор это не просто кетчуп”, “яйцо это не просто майнез”? В чём заключается ваша глубокая мысль?
В статье или в комментариях кто-то спрашивал о том, как хранить логи? В статье вообще есть акценты на хранении данных? Если уж разбираться, то у protobuf-сообщения самого по себе нет универсальной сигнатуры/framing для поиска сообщения в произвольном замусоренном потоке - каждый крутится с этим как может, что не отменяет ценности protobuf. Другое дело, что вы просто булщитите, постоянно пытаясь уйти от топика статьи. Мы с таким же успехом можем обсудить здесь интимные стрижки, они примерно так же соотносятся по смыслу со статьей, как упомянутый gRPC.
Статья написана про протокол, в репе сказано за протокол. Я пытался понять зачем хранение в транспортном протоколе. Обычно если делают модуль то разделяют зоны ответственности, то есть транспорт отдельно, хранение отдельно. Вместе это уже какая-то тулза что состоит из отдельных модулей.
Это просто какой-то набор слов вообще без содержания. “Сама придумала, сама обиделась” ©. В статье речь про фичу в протоколе. В документации прямо говорится, что это конструктор протокола в первую очередь. Storage, reader и прочие части - это инструменты вокруг packet format, а не обязательная часть
cryptи не транспортный протокол. В доках и статье прямо говорится: конструктор протокола + набор инструментов, которыми можно пользоваться по необходимости.По хранению рекомендую посмотреть на как сделано cockroachdb/pebble дам довольно просто и очевидно, потому как ваше простое хранение по фиксированному массиву спорное решение для вашей же задачи когда надо прокидывать и читать странные логи. Во-первых хранение не массивами, а фиксированными чанками, что бы оно ровно в памяти лежало и проще читалось на произвольные размеры.
Откуда читалось? О каком хранилище вы говорите? О Storage из brec, нацеленном на seekable backend? О каких массивах речь? В brec-storage фиксированным является не размер данных, а размер slot: слот хранит длины пакетов и позволяет вычислять offset. Сами пакеты внутри слота переменного размера. Если вы даёте техническую оценку решения - то сопровождайте её кодом и бенчами, отражающими просадку по чтению/записи. Если бенчи делать лень, то надо очень вежливо спрашивать “а не рассматривали ли вы как вариант это и это?”. Именно вежливо, так как именно автор будет тратить своё время на дополнительные бенчи, чтобы вам ответить. Если и это лень, то хотя бы сформулируйте мысль.
Во-вторых как раз лучше разорвать шифрование транспорта и шифрование хранилища, для того что бы расшифрованное нарезать по чанкам, а чанки жать и уже результат шифровать. Даже если все in-memory то оперативка не бесконечная, а зашифрованное не сожмется так как расшифрованное особенно если это логи которые можно сжать и в х20 если повторов много.
Сжатие, транспорт, шифрование всего хранилища, чанки, чанки. Вы статью читали вообще - это обзор конкретной фичи.
brec cryptне является storage encryption pipeline и не пытается им быть. Вы вообще о чём? Если вы не поняли сути, то об этом можно спросить (вежливо) автора. В статье прямо говорится, в комментариях раскрывается, что есть сценарии, в которых на условные 100 сообщений приходится 1-2 зашифрованных. Точка. Если бы вы серьёзным ребятам, на серьёзных embedded-проектах, предложили бы шифровать всё ради 1-2% данных - вас не уволили, вас бы пристрелили, молча и хладнокровно. Вы либо очень ограниченно понимаете мир логов, трейсов, метрик и прочего, считая, что это вотчина исключительно Datadog и OpenTelemetry, либо какое-то медоборудование, где потоково шифруется зачастую вообще всё, либо… я хрен знает, если вы отрицаете право существования логов в файлах (отсылка к вашим вчерашним комментариям к моим статьям 5-летней давности). Мир разнообразнее, чем вам кажется.По кривому шифрованию как минимум у вас в отрытых данных длинна и как убить комп подменив всего пару байт в потоке я писал выше.
То есть да, DoS через length в одном из reader-path возможен (на недоверительном потоке), и это уже вынесено в issues (вас даже за это поблагодарили!). Но назвать это “кривым шифрованием” - это либо непонимание предмета, либо сознательная подмена тезиса. Шифрование здесь не ломается: payload не раскрывается, AEAD не обходится, валидная подмена encrypted body не появляется. Ломается входная валидация длины до аллокации. Это разные классы проблем. Если это ломает шифрование, то будьте добры доказательства на стол, за базар-то надо отвечать, если уж взялись.
Было бы у вас еще по хешу проверка целостности, а не CRC32 то можно было бы “помолившись забить” но так вектор атаки настолько очевиден, что подсознательно кажется что это приманка (например 16 байт с зашифрованного блока это скрытая хеш-сумма всего пейлоада, что бы детектить мамкиных хакеров еше на этапе анализа инфраструктуры)
Ровно то же самое - лишь бы саср#ть. CRC32 в
brecне является криптографической защитой и за неё не выдавался. Это быстрая проверка для чтения, чтобы ловить повреждения и рассинхрон потока. Для encrypted payload криптографическую целостность тела даёт не CRC32, а AEAD-тегChaCha20Poly1305: если подменить ciphertext/tag, расшифровка не пройдёт.Да, открытые length/header поля до decrypt-этапа остаются возможностю для DoS, если читать недоверенный поток без лимитов. Именно это замечание я принял и по нему создал тикеты. Даже при том, что на руках у меня нет воспроизводимого сценария атаки. Но превращать CRC32 в “кривое шифрование” - это просто смешивать разные уровни проверки. Во-вторых, архитектура brec и концепция контекста позволяет реализовывать свой механизм вне фичи
crypt, отвечающий повышенным мерам безопастности, что прямо в статье указано.За интеграции я потому и написал за подключаемые библиотеки. Вы со своей стороны собрали бинарь, а дальше как с ним будут работать не ваши половые трудности. Если простыми словами, то dll/so это “стариковский WASM для десктопов”. Потому как CLI это не сильно безопасно и вообще не кроссплатформенно. Я вот например свои пет-проекты если делаю как “универсальный” CLI то собираю 38 бинарей (linux/amd64, linux/arm64, linux/arm/v7, linux/arm/v6, linux/386, linux/mips, linux/mipsle, linux/mips64, linux/mips64le, linux/ppc64, linux/ppc64le, linux/riscv64, linux/s390x, windows/amd64, windows/arm64, windows/arm/v7, windows/386, macos/amd64, macos/arm64, freebsd/amd64, freebsd/arm64, freebsd/arm/v6, freebsd/arm/v7, freebsd/386, openbsd/amd64, openbsd/arm64, openbsd/arm/v6, openbsd/arm/v7, openbsd/386, netbsd/amd64, netbsd/arm64, netbsd/arm/v6, netbsd/arm/v7, netbsd/386, android/amd64, android/arm64, android/arm/v7, android/386) и это самые популярные и беспроблемные (то есть собирается прямо в actions github) потому как предусмотреть все нереально, а ковыряться со сборкой до бума с ИИ редко бы кто стал.
Ох сударь, вам бы тут промолчать. Если вы не понимаете, чем отличается компиляция бинарника под разные платформы и архитектуры от биндинга и FFI, то хотя бы попридержите своё мнение. И просто для справки: в мире Cargo вспомогательный CLI/build-time tool - это нормальная практика.
Кстати, что такое "половые трудности"?
А за логи я вам писал в другом вашем посте развернуто. Как лучше хранить и агрегировать. По поводу “небезопасных данных” - если сами разрабы, кто писали логи, такие “индусы” то просто сделайте тонкий клиент-обфускатор что будет работать в потоке и все. Все равно нежные данные должны как то помечатся - задетектили, обрезали середину, добавили звездочек и вот уже открыто переданный пароль нечитаем для стороннего чтения. Потому как шифрование это полумеры и вы этим лечите чужие ошибки своими костылями. Но вообще за такое безопасники беседуют без смазки со всеми причастными вплоть до увольнений.
На всё есть ответ и своё единственно-верное мнение. Кругом индусы, а он умничка наша! Ай да молодец, ай да солнышко! Как же хорошо, что мы вместе не работаем )
ЗЫ: Я правда вам признателен за агрессивный прогон решения через ИИ. Вы действительно вскрыли проблему с длинами на недоверенном потоке данных. Тикеты созданы, правки будут внесены. Те 3 проекта (на стадии MVP), что используют сегодня brec и могут в будущем стать реальными продуктами, будут лучше и безопастнее благодаря именно вам. Я особо это подчёркиваю - благодаря Вам. Спасибо! Но наш диалог мог быть совершенно иным, не смотрели бы вы на людей сверху вниз и не пытались бы за счёт других утверждаться. Хотите купить мою учётку на Хабре? Только вряд ли вам это поможет, потому как уважение не покупается.
gerbert_MX
28.05.2026 14:22да я понял что "не бомбит", все ок.
просто будьте проще и жизнь тоже станет проще
gerbert_MX
28.05.2026 14:22да хоть обмажь меня минусами, реальность это не изменит - сам придумал, сам обиделся
если такое хрупкое эго, то не стоит публиковаться, серьезно. или хотя бы пометку делай что это продукт всей жизни и критика неприемлема ни в какой форме, даже в формате вопросов
AlexWriter Автор
28.05.2026 14:22Хе ))) @gerbert_MX Вижу, вы уже не ограничились этой статьёй и пошли по архиву моих публикаций, включая материалы двухлетней давности.
Честно говоря, это уже выглядит не как профессиональная дискуссия, а как желание оставить “экспертное мнение” с явным негативным оттенком везде, где получится. Технические комментарии под старыми статьями я здесь обсуждать не буду: во-первых они весьма спорны и откровенно поверхностны, во-вторых это другая тема, другой контекст и местами вообще другой проект.
По
brecя уже отдельно признал полезные замечания и завёл тикеты там, где есть реальная техническая фактура. Если появятся конкретные воспроизводимые проблемы - входные данные, падение, DoS-сценарий, ошибка чтения - с радостью разберу.Если это что-то личное, напишите в личку - я всегда отвечаю.
gerbert_MX
28.05.2026 14:22да нет, это выглядит как заинтересовала статья пошел читать другие
на дату я потом уже посмотрел))
иногда утка это просто утка
gerbert_MX
TLS - просто существует
Как ученическая работа на поковырять и посмотреть ваш проект хорош. Даже векторы затронули, что не каждый из тех кто играется с созданием своей криптографии делает.
Но вот как "боевое использование" какие преимущества от такой проприоретаршины? На глаз Я бы не сказал что она будет быстрее классики, я бы даже сказал что наоборот если я правильно понял и вы все end-to-end в RSA пакуете. За безопасность тоже под вопросом, хотя тут я не специалист может и не прав.
У меня сразу вопрос почему производная от SHA256 а не тот же BLAKE3?