Вау, оно реально работает на линухе!!!

И установка и распаковка и контроль версий! Крута!

С первого раза на линуксе завелось, проработал хорошо)

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

По этому пока что закрою билд, как только выпущу стабильную версию игры, открою как на линукс, так и на виндовс билды =)

Сколько вам потребовалось времени на настройку CI/CD билда QT приложения на обе платформы?

ДА....

А если серьезно, я не знал, что линукс НА СТОЛЬКО КАПРИЗНЫЙ К РЕГИСТРУ НАЗВАНИЯ ИМЕН.

Ну типа для него Versioninfo.h и VersionInfo.h это СОВЕРШЕННО РАЗНЫЕ ФАЙЛЫ, хотя для Виндовс вообще не принипиально, там компилятор их хавает без проблем. Все эти сломанные билды, только линукс.

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

git rm --cached -f Versioninfo.h
git add VersionInfo.h
git commit -m "Force fix case sensitivity in git"
git push origin master

И все заработает прекрасно. Кто бы знал, кто бы знал

ПОБЕДА!

H5 Заголовок Wireguard РАБОТАЕТ!

Скоро туда засуну посткванты =)

Объясняю для людей, которые не понимают что я делаю.

Я когда то давно писал о том, что есть инструмент, который называется Rosenpass (Немецкий заяц)

Проблема в том, что он работает на голом TCP (Протокол, который позволяет гарантированно доставить большой пакет данных) Это отдельный порт сетевой на сервере. + один паттерн обнаружения

Wireguard работает ТОЛЬКО на UDP, это 1500 байт МАКСИМУМ. А я написал модуль, который имитирует TCP протокол ВНУТРИ UDP протокола. Или правильнее сказать ПОВЕРХ UDP.

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

На данном скриншоте я отправил 12 тысяч байт и оно пришло.

Для чего?

ML-Kem и ML-DSA, это очень простые в вычислении алгоритмы, но данные, которые они генерируют, очень массивные. Это проблема для UDP, напомню, там 1500 байт максимум, когда как данные ML-DSA в среднем 5 тысяч байт.

Я уперся в PQC реализации библиотек, для их адекватной работы стек должен быть +- 120 Кб, а в kernel в 10 меньше, к сожалению.

Похоже плакала моя идея PQC примитивов в kernel.

Самое забавное, что оказывается об этом уже писали и это известное ограничение, которое я проигнорировал, пока сам не столкнулся. Хаха =)

Как минимум транспорт у меня работает, передать в kernel пакет будет не сложно. По крайней мере я на это надеюсь.

Я кстати придумал описание как работает ML-KEM для простых смертных, кто плохо понимает постквантовую криптографию!
Может кому то будет любопытно.

Механизм:
Сервер генерирует приватный ключ ML-KEM алгоритма и из него публичный ключ.

Но, публичный ключ это не совсем ключ, это скорее описание структуры пространства, в которое клиент будет прятать секрет. Буду называть его Seed Server — для простоты аналогия рабочая.

Внимание! Самое прикольное на клиенте.

Клиент генерирует СВОЁ РАНДОМНОЕ ЧИСЛО, это не ключ AES и не ключ Кузнечика и ничего подобного, это просто его личный секрет. Буду называть его Seed Client.

Фокус. Следите за буквами.

Клиент запихивает в функцию ML-KEM(Seed Server + Seed Client) -> Получает СГЕНЕРИРОВАННЫЙ ключ AES или того же Кузнечика ИИИИИИ Шифротекст.

Этот шифротекст представляет из себя массив (набор) данных, в котором Seed Client спрятан на основе структуры Seed Server.

Это отправляется на сервер.

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

Это и есть магия KEM.

Можно сказать магия происходит на клиенте. ML-KEM гарантирует, что даже перехватив шифротекст, квантовый компьютер не сможет вскрыть ключ — математика решёток не даёт. Ключа то по факту там нет внутри, там лежит Seed Client, который тоже ничего не даст!

Для понимания почему это так важно:

Классическая криптография на эллиптических кривых работает по простому. У нас есть приватный ключ и публичный ключ. Публичный ключ отправляется клиенту. Клиент ГЕНЕРИРУЕТ СВОЙ AES ключ и ЗАШИВАЕТ ЕГО В ПУБЛИЧНЫЙ КЛЮЧ от сервера. То есть шифротекст СОДЕРЖИТ в себе ключ — это первый момент. Второй момент: при передаче ПУБЛИЧНОГО ключа, из-за математики эллиптических кривых, квантовый компьютер сможет провернуть обратно публичный ключ в приватный — и тогда вскрыть шифротекст. Это особенности эллиптических кривых и алгоритма Шора.

В ML-KEM ключа в шифротексте нет в принципе. Квантовому компьютеру нечего вскрывать.

Я обещал перейти на FireFox, теперь буду сидеть на Firefox =)

Нахер Edge и Хромиум вообще.

Для VPN и Прокси самый удобный по архитектуре, это FireFox, как оказалось, это факты.

На его движке оказывается был сконструирован Tor, кто бы знал, кто бы знал. Я НЕ ЗНАЛ.

Ща буду настраивать под себя

А я все еще скурпулезно и методично пытаюсь заставить работать посткванты.

Я настроил пейплайн Client userspace (PQC) -> Client Kernel -> BPT (Мой новый протокол mini-TCP over UDP) -> Server kernel -> Userspace (PQC)

Это знаете ли сложно =0

Но на самом деле переписывать Liboqs ЕЩЕ сложнее, так как постквантовые алгоритмы очень чувствительны на реализацию.

Мне предложили переписать алгоритмы с выделением памяти и прочего - прочего прямо в kernel, но это открывает целую КУЧУ векторов атак, на самом деле. На много безопаснее сделать это в userspace и не думать об этом.