#ed25519 — Public Fediverse posts on home.social

Opening: Mission Control is an open-source dashboard aimed at orchestrating AI agents and their workflows from a single UI. The project centralizes agent lifecycle management, task pipelines, Kanban-style boards, cost and token tracking, and webhook delivery while minimizing external infrastructure dependencies.

Key Features:
• Agent lifecycle: registration, heartbeat, wake, retire, and inter-agent messaging.
• Real-time telemetry: combination of WebSocket and SSE with smart polling to reduce noise when users are idle.
• Storage & state: embedded SQLite (WAL) database to avoid mandatory external DBs.
• Access control: role-based access with viewer/operator/admin roles and support for session and API key authentication.
• Integration primitives: multi-gateway support (current gateway: OpenClaw), Claude Code session discovery, outbound webhooks with delivery history, retry with exponential backoff and circuit breaker.
• Security primitives: webhook signature verification using HMAC-SHA256 with constant-time comparison and Ed25519 device identity for gateway handshakes.
• Workflow constructs: pipeline orchestration, quality gates that block task completion pending sign-off, scheduler/cron and templates for workspace file sync (Agent SOUL).

Technical implementation:
• The frontend leverages modern frameworks and TypeScript for a single-page experience while server push uses WebSocket/SSE for low-latency updates.
• Persistence via SQLite WAL enables local operation without Redis/Postgres while still supporting background schedulers and stateful retry queues for webhooks.
• Webhook delivery implements exponential backoff plus a circuit breaker pattern to prevent cascading failures from unreliable endpoints.

Use cases:
• Managing multi-model agent fleets and tracking per-model token usage and costs.
• Orchestrating multi-step pipelines with quality review gates for human-in-the-loop workflows.
• Centralizing webhook integrations and delivery retry history for downstream systems.

Limitations & considerations:
• The project is labeled Alpha; APIs, schemas and configuration formats may change between releases.
• The default UI/content security policy still permits unsafe-inline styles for framework compatibility; operators should treat this as a known limitation.
• The embedded SQLite design reduces external dependency complexity but may limit horizontal scaling in very large multi-node deployments.
• Security guidance in the repo advises changing seeded credentials and avoiding direct exposure to the public Internet without TLS and host restrictions.

References: check the repository for documentation on role mappings, gateway adapters and webhook delivery semantics.

🔹 tool #agent_orchestration #webhooks #sqlite #ed25519

🔗 Source: https://github.com/builderz-labs/mission-control

#ed25519 #sqlite #webhooks #agent_orchestration

Habr @[email protected] · 2026-03-05 · 11:32 UTC

Разворачиваем self-hosted Matrix: Synapse + OIDC + LiveKit + подписанные обновления

Привет. Мне стало интересно, насколько реально одному разработчику собрать продакшн‑подобную инфраструктуру мессенджера без managed‑решений и «облачной магии». Не стартап‑презентацию, а инженерный эксперимент: развернуть стек, заставить его жить, увидеть слабые места и понять, что в этой системе действительно критично. На Хабре уже есть материалы про базовую установку Synapse + Element, но моя цель чуть другая — показать сборку, где к Matrix добавляется внешний слой идентификации (OIDC), VoIP‑инфраструктура (LiveKit + TURN) и механизм подписанных обновлений Android‑клиента. В статье — архитектура, ключевые конфиги и границы ответственности компонентов. В следующих частях разберу грабли, потому что в этом стеке они не побочный эффект, а часть реальности.

https://habr.com/ru/articles/1006904/

#Matrix #Synapse #OIDC #LiveKit #WebRTC #Docker #PostgreSQL #Android #Ed25519 #мессенджеры

#мессенджеры #ed25519 #android #postgresql #docker #webrtc

Habr @[email protected] · 2026-02-22 · 12:32 UTC

Как я реализовал криптографически доказуемые чаты в своём мессенджере: Ed25519 + хеш-цепочка

Мне 18 лет, и последние несколько месяцев я разрабатываю Xipher — мессенджер, который пишу с нуля на C++ (бэкенд) и Kotlin (Android). В какой-то момент я захотел добавить фичу, которой нет ни в одном популярном мессенджере: режим, в котором переписку невозможно подделать — ни участникам, ни мне как владельцу сервера, — и это можно проверить независимо, без доступа к серверу. Так появился Xipher Provable Chat . В этой статье разберу, как именно это реализовано, какие решения я принял и с какими проблемами столкнулся.

https://habr.com/ru/articles/1002436/

#Ed25519 #хешцепочка #цифровые_подписи #криптография #мессенджер #Kotlin #C++ #OpenSSL #Android #доказуемость

#доказуемость #android #openssl #c #kotlin #мессенджер

alip @[email protected] · 2026-02-05 · 19:18 UTC

I have been fuzzing my #rustlang rewrite of #openbsd #signify with #AFL for: run time : 27 days, 22 hrs, 31 min, 46 sec, cycles done : 2.11M, last saved crash : none seen yet. Will we finally crack #ed25519 or do we need more #AI for fuzzing? https://crates.io/crates/signify-rs #exherbo #cryptography #freedom

#rustlang #openbsd #signify #afl #ed25519 #ai

Dima @[email protected] · 2026-01-27 · 21:30 UTC

Spent the last week diving deep into E2EE and encryption. Decided to do it right: generated a fresh GPG key on my own hardware using Vanity GPG.

Managed to "mine" 10 trailing zeros for the fingerprint in just 5 minutes on the M4 Max—the performance is wild.

Chose ECC (Curve25519/Ed25519) for that perfect balance of speed and high security. Moved the private key to my YubiKey, and now signing GitHub/GitLab commits is just a single tap away.

My brain loves manual protocols, and there’s something deeply satisfying about hardware-backed trust. I know, I'm late to the party, but it feels good to finally have that "Verified" badge.

#GPG #Cryptography #YubiKey #Infosec #M4Max #OpenSource #Privacy #Ed25519 #CyberSecurity #Mastodon #Fediverse

#gpg #cryptography #yubikey #infosec #m4max #opensource

Heals :heart_nb: (moved) @[email protected] · 2026-01-26 · 20:58 UTC

I wonder, are there any working SSH clients on iOS that can handle ed255519_sk keys?

(That’s the variant where you have a public and private key part however the private key links to a residential key on an external FIDO2 security token. You plug in the token or use NFC, enter the pin and confirm with a touch)

#ssh #fido2 #token2 #iOS #ed25519

#ssh #fido2 #token2 #ios #ed25519

Hacker News @[email protected] · 2026-01-03 · 22:28 UTC

Ed25519-CLI – command-line interface for the Ed25519 signature system

https://lib25519.cr.yp.to/ed25519-cli.html

#HackerNews #Ed25519 #CLI #command #line #interface #signatures #cryptography

#hackernews #ed25519 #cli #command #line #interface

John Shaft @[email protected] · 2025-12-03 · 23:51 UTC

TLDs using #ed25519 (algorithm 15) for #DNSSEC :

- .fj (Fiji)
- .pg (Papua New Guinea)
- .ml (Mali)

#ed25519 #dnssec

John Shaft @[email protected] · 2025-12-03 · 23:44 UTC

RE: https://mastodns.net/@diffroot/115657783055191749

Mali going secure!

Third TLD to use #ed25519. Second one to publish its first DS directly with this algorithim

\o/

(poke @camille )

#DNSSEC #DNS

#ed25519 #dnssec #dns

benzogaga33 :verified: @[email protected] · 2025-11-27 · 11:10 UTC

Ackify CE : preuve de lecture cryptographique en Go + Vue3 https://linuxfr.org/news/ackify-ce-preuve-de-lecture-cryptographique-en-go-vue3 #cryptographie #postgresql #ed25519 #Golang #golang #docker #rgpd #vue

#cryptographie #postgresql #ed25519 #golang #docker #rgpd

Marek @[email protected] · 2025-11-09 · 14:39 UTC

I am currently updating my small OpenWrt routers from v23 to v24. Unfortunately, this is not so easy: Dropbear does not support ED25519 in v24. RSA (with a key length of 4096) takes several seconds per login, which is too slow when using Ansible.

#OpenWrt #Dropbear #OpenSSH #Fail #Anaible #RSA #ED25519 #Networking #HomeLab

#openwrt #dropbear #openssh #fail #anaible #rsa

Marek @[email protected] · 2025-11-09 · 14:39 UTC

I am currently updating my small OpenWrt routers from v23 to v24. Unfortunately, this is not so easy: Dropbear does not support ED25519 in v24. RSA (with a key length of 4096) takes several seconds per login, which is too slow when using Ansible.

#OpenWrt #Dropbear #OpenSSH #Fail #Anaible #RSA #ED25519 #Networking #HomeLab

#openwrt #dropbear #openssh #fail #anaible #rsa

Marek @[email protected] · 2025-11-09 · 14:39 UTC

I am currently updating my small OpenWrt routers from v23 to v24. Unfortunately, this is not so easy: Dropbear does not support ED25519 in v24. RSA (with a key length of 4096) takes several seconds per login, which is too slow when using Ansible.

#OpenWrt #Dropbear #OpenSSH #Fail #Anaible #RSA #ED25519 #Networking #HomeLab

#openwrt #dropbear #openssh #fail #anaible #rsa

Marek @[email protected] · 2025-11-09 · 14:39 UTC

I am currently updating my small OpenWrt routers from v23 to v24. Unfortunately, this is not so easy: Dropbear does not support ED25519 in v24. RSA (with a key length of 4096) takes several seconds per login, which is too slow when using Ansible.

#OpenWrt #Dropbear #OpenSSH #Fail #Anaible #RSA #ED25519 #Networking #HomeLab

#homelab #networking #ed25519 #rsa #anaible #fail

Marek @[email protected] · 2025-11-09 · 14:39 UTC

I am currently updating my small OpenWrt routers from v23 to v24. Unfortunately, this is not so easy: Dropbear does not support ED25519 in v24. RSA (with a key length of 4096) takes several seconds per login, which is too slow when using Ansible.

#OpenWrt #Dropbear #OpenSSH #Fail #Anaible #RSA #ED25519 #Networking #HomeLab

#openwrt #dropbear #openssh #fail #anaible #rsa

ピゴスパ @[email protected] · 2025-09-19 · 16:52 UTC

It's been a while since I've last used #crypto (and by that I don't mean coins but oldschool #cryptography : encrypting and signing mails, etc.), and lately I've only used #gpg to encrypt my #pass vault.

However, I wanted to up my game a little, so here it comes: For the first time I got myself a hardware token. I opted for #yubikey even though #nitrokey is probably the better option, because of #opensource. But I wanted my first steps to be smooth ones, and also try out all the different operational scenarios; and all research said that Yubikey is the better supported and the more versatile option (maybe I'll switch to a #nitrokey later on).

I went a bit overboard with the setup as well. I got myself some new USB drives, one flashed with #tails - a portable live #linux system by the @torproject developers, to boot with it a machine #offthegrid on which I'd create my keys. A #gnupg main key just for certification, and three subkeys for signing, encryption and authentication. The main key was moved to two backup USB drives, the subkeys on two Yubikeys (which as a bit of a hassle as usually you are only allowed to move them to one).

While the private main key will never see the light of day (i.e. just stay on the thumbdrives or be imported by the off-grid tails system), the subkeys will live on my tokens (which are not extractable as well).

They expire every year so I'd need to renew them (with the main key on tails), my identities are tied to the main key, and if any key is compromized I can easily create new ones with that main key.

To me that seems pretty sound, and a lot of overkill, tbh :D But it was also quite fun.

Next up: Switching my environment to use Yubikey and my new GPG keys instead of #ssh etc. And after that I'll give #2FA a try. And if I am not on the PC I'll guess I'll read some more about #EllipticCurveCryptography. First time I am using those algorithms. So long, #RSA, you've been a great companion, and hello #ed25519, nice to meet you.

#security #privacy

#gpg #pass #yubikey #nitrokey #opensource #tails

ピゴスパ @[email protected] · 2025-09-19 · 16:52 UTC

It's been a while since I've last used #crypto (and by that I don't mean coins but oldschool #cryptography : encrypting and signing mails, etc.), and lately I've only used #gpg to encrypt my #pass vault.

However, I wanted to up my game a little, so here it comes: For the first time I got myself a hardware token. I opted for #yubikey even though #nitrokey is probably the better option, because of #opensource. But I wanted my first steps to be smooth ones, and also try out all the different operational scenarios; and all research said that Yubikey is the better supported and the more versatile option (maybe I'll switch to a #nitrokey later on).

I went a bit overboard with the setup as well. I got myself some new USB drives, one flashed with #tails - a portable live #linux system by the @torproject developers, to boot with it a machine #offthegrid on which I'd create my keys. A #gnupg main key just for certification, and three subkeys for signing, encryption and authentication. The main key was moved to two backup USB drives, the subkeys on two Yubikeys (which as a bit of a hassle as usually you are only allowed to move them to one).

While the private main key will never see the light of day (i.e. just stay on the thumbdrives or be imported by the off-grid tails system), the subkeys will live on my tokens (which are not extractable as well).

They expire every year so I'd need to renew them (with the main key on tails), my identities are tied to the main key, and if any key is compromized I can easily create new ones with that main key.

To me that seems pretty sound, and a lot of overkill, tbh :D But it was also quite fun.

Next up: Switching my environment to use Yubikey and my new GPG keys instead of #ssh etc. And after that I'll give #2FA a try. And if I am not on the PC I'll guess I'll read some more about #EllipticCurveCryptography. First time I am using those algorithms. So long, #RSA, you've been a great companion, and hello #ed25519, nice to meet you.

#security #privacy

#gpg #pass #yubikey #nitrokey #opensource #tails

ピゴスパ @[email protected] · 2025-09-19 · 16:52 UTC

It's been a while since I've last used #crypto (and by that I don't mean coins but oldschool #cryptography : encrypting and signing mails, etc.), and lately I've only used #gpg to encrypt my #pass vault.

However, I wanted to up my game a little, so here it comes: For the first time I got myself a hardware token. I opted for #yubikey even though #nitrokey is probably the better option, because of #opensource. But I wanted my first steps to be smooth ones, and also try out all the different operational scenarios; and all research said that Yubikey is the better supported and the more versatile option (maybe I'll switch to a #nitrokey later on).

I went a bit overboard with the setup as well. I got myself some new USB drives, one flashed with #tails - a portable live #linux system by the @torproject developers, to boot with it a machine #offthegrid on which I'd create my keys. A #gnupg main key just for certification, and three subkeys for signing, encryption and authentication. The main key was moved to two backup USB drives, the subkeys on two Yubikeys (which as a bit of a hassle as usually you are only allowed to move them to one).

While the private main key will never see the light of day (i.e. just stay on the thumbdrives or be imported by the off-grid tails system), the subkeys will live on my tokens (which are not extractable as well).

They expire every year so I'd need to renew them (with the main key on tails), my identities are tied to the main key, and if any key is compromized I can easily create new ones with that main key.

To me that seems pretty sound, and a lot of overkill, tbh :D But it was also quite fun.

Next up: Switching my environment to use Yubikey and my new GPG keys instead of #ssh etc. And after that I'll give #2FA a try. And if I am not on the PC I'll guess I'll read some more about #EllipticCurveCryptography. First time I am using those algorithms. So long, #RSA, you've been a great companion, and hello #ed25519, nice to meet you.

#security #privacy

#gpg #pass #yubikey #nitrokey #opensource #tails

ピゴスパ @[email protected] · 2025-09-19 · 16:52 UTC

It's been a while since I've last used #crypto (and by that I don't mean coins but oldschool #cryptography : encrypting and signing mails, etc.), and lately I've only used #gpg to encrypt my #pass vault.

However, I wanted to up my game a little, so here it comes: For the first time I got myself a hardware token. I opted for #yubikey even though #nitrokey is probably the better option, because of #opensource. But I wanted my first steps to be smooth ones, and also try out all the different operational scenarios; and all research said that Yubikey is the better supported and the more versatile option (maybe I'll switch to a #nitrokey later on).

I went a bit overboard with the setup as well. I got myself some new USB drives, one flashed with #tails - a portable live #linux system by the @torproject developers, to boot with it a machine #offthegrid on which I'd create my keys. A #gnupg main key just for certification, and three subkeys for signing, encryption and authentication. The main key was moved to two backup USB drives, the subkeys on two Yubikeys (which as a bit of a hassle as usually you are only allowed to move them to one).

While the private main key will never see the light of day (i.e. just stay on the thumbdrives or be imported by the off-grid tails system), the subkeys will live on my tokens (which are not extractable as well).

They expire every year so I'd need to renew them (with the main key on tails), my identities are tied to the main key, and if any key is compromized I can easily create new ones with that main key.

To me that seems pretty sound, and a lot of overkill, tbh :D But it was also quite fun.

Next up: Switching my environment to use Yubikey and my new GPG keys instead of #ssh etc. And after that I'll give #2FA a try. And if I am not on the PC I'll guess I'll read some more about #EllipticCurveCryptography. First time I am using those algorithms. So long, #RSA, you've been a great companion, and hello #ed25519, nice to meet you.

#security #privacy

#cryptography #privacy #security #crypto #ed25519 #rsa

ピゴスパ @[email protected] · 2025-09-19 · 16:52 UTC

It's been a while since I've last used #crypto (and by that I don't mean coins but oldschool #cryptography : encrypting and signing mails, etc.), and lately I've only used #gpg to encrypt my #pass vault.

However, I wanted to up my game a little, so here it comes: For the first time I got myself a hardware token. I opted for #yubikey even though #nitrokey is probably the better option, because of #opensource. But I wanted my first steps to be smooth ones, and also try out all the different operational scenarios; and all research said that Yubikey is the better supported and the more versatile option (maybe I'll switch to a #nitrokey later on).

I went a bit overboard with the setup as well. I got myself some new USB drives, one flashed with #tails - a portable live #linux system by the @torproject developers, to boot with it a machine #offthegrid on which I'd create my keys. A #gnupg main key just for certification, and three subkeys for signing, encryption and authentication. The main key was moved to two backup USB drives, the subkeys on two Yubikeys (which as a bit of a hassle as usually you are only allowed to move them to one).

While the private main key will never see the light of day (i.e. just stay on the thumbdrives or be imported by the off-grid tails system), the subkeys will live on my tokens (which are not extractable as well).

They expire every year so I'd need to renew them (with the main key on tails), my identities are tied to the main key, and if any key is compromized I can easily create new ones with that main key.

To me that seems pretty sound, and a lot of overkill, tbh :D But it was also quite fun.

Next up: Switching my environment to use Yubikey and my new GPG keys instead of #ssh etc. And after that I'll give #2FA a try. And if I am not on the PC I'll guess I'll read some more about #EllipticCurveCryptography. First time I am using those algorithms. So long, #RSA, you've been a great companion, and hello #ed25519, nice to meet you.

#security #privacy

#gpg #pass #yubikey #nitrokey #opensource #tails

Habr @[email protected] · 2025-08-22 · 08:02 UTC

Как я НЕ взломал ED25519

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

https://habr.com/ru/articles/939686/

#curve25519 #ed25519 #python #хакинг #криптография #эллиптические_кривые #исследования_в_ит #математика #edwards_curve #уязвимости

#уязвимости #edwards_curve #математика #исследования_в_ит #эллиптические_кривые #криптография

data0 @[email protected] · 2025-08-14 · 10:26 UTC

#Ed25519 is now supported in all major #browsers. Big up @igalia!

https://blog.ipfs.tech/2025-08-ed25519/

#ipfs #ecc #webcryptoapi #cryptography #browser

#ed25519 #browsers #ipfs #ecc #webcryptoapi #cryptography

Internet.nl @[email protected] · 2025-07-29 · 19:35 UTC

@camille
Thanks for your feedback. Do you have an example domain?

The test validates #DNSSEC #ED25519 signatures on ed25519.nl and ed25519.no:
- https://internet.nl/site/ed25519.nl/3367385/#sitednssec
- https://internet.nl/site/ed25519.no/3367390/#sitednssec

#ed25519 #dnssec

ChaCha20Poly1305 @[email protected] · 2025-07-29 · 09:36 UTC

@internet_nl your #DNSSEC test seems to be unable to validate #ED25519 signatures.

#dnssec #ed25519

Pixelcode 🇺🇦 @[email protected] · 2025-03-23 · 11:33 UTC

As I need an Ed25519-SK SSH key generated with a hardware token, I tried to use my Nitrokey #FIDO2 for that, but: no.

Years ago, #ed25519 had experimentally been added to the firmware (not released) but later #Nitrokey stated that customers should've donated on top of the selling price to get firmware updates & advised to buy the new product instead.

The latter would be OK if the old key wasn't sold anymore, but it is still sold & the firmware was last updated in 2021.

https://github.com/Nitrokey/nitrokey-fido2-firmware/issues/39#issuecomment-1721164809

#fido2 #ed25519 #nitrokey

John Shaft @[email protected] · 2025-03-06 · 11:28 UTC

So smol 🥺

#DNSSEC #ed25519

https://piaille.fr/@shaft/114115244980271165

#dnssec #ed25519

Jason 🦓 Gerard 🦀 DeRose @_json420 · 2025-01-30 · 16:05 UTC

I've reached 420 commits in ZebraChain. All 69 unit tests are passing.

https://github.com/zebrafactory/zebrachain

Not joking, `cargo test` for yourself 😏

#Rust #PostQuantumCryptography #Dilithium #ed25519

#rust #postquantumcryptography #dilithium #ed25519

Linknation @[email protected] · 2025-01-30 · 13:14 UTC

@soatok LOADS of #banks are still using RSA X-D shiiiiite X-D
anyone seen #https using #Ed25519 not me

#banks #https #ed25519

Linknation @[email protected] · 2025-01-30 · 12:56 UTC

@soatok alright got it :D using #Ed25519 for ssh since a long time :D https://en.wikipedia.org/wiki/Elliptic_curve but what about https? https://duckduckgo.com/?q=https+Ed25519

#ed25519

Jason 🦓 Gerard 🦀 DeRose @_json420 · 2025-01-23 · 01:27 UTC

I'm now doing post quantum secure hybrid signing with #Dilithium and #ed25519 (in #Rust of course):
https://github.com/zebrafactory/zebrachain

#dilithium #ed25519 #rust

Soatok @[email protected] · 2025-01-15 · 04:24 UTC

Don’t Use Session (Signal Fork)

Last year, I outlined the specific requirements that an app needs to have in order for me to consider it a Signal competitor.

Afterwards, I had several people ask me what I think of a Signal fork called Session. My answer then is the same thing I’ll say today:

Don’t use Session.

The main reason I said to avoid Session, all those months ago, was simply due to their decision to remove forward secrecy (which is an important security property of cryptographic protocols they inherited for free when they forked libsignal).

Lack of forward secrecy puts you in the scope of Key Compromise Impersonation (KCI) attacks, which serious end-to-end encryption apps should prevent if they want to sit at the adults table. This is why I don’t recommend Tox.

And that observation alone should have been enough for anyone to run, screaming, in the other direction from Session. After all, removing important security properties from a cryptographic security protocol is exactly the sort of thing a malicious government would do (especially if the cover story for such a change involves the introduction of swarms and “onion routing”–which computer criminals might think sounds attractive due to their familiarity with the Tor network).

Unfortunately, some people love to dig their heels in about messaging apps. So let’s take a closer look at Session.

I did not disclose this blog post privately to the Session developers before pressing publish.
I do not feel that cryptographic issues always require coordinated disclosure with the software vendor. As Bruce Schneier argues, full disclosure of security vulnerabilities is a “damned good idea”.

I have separated this blog post into two sections: Security Issues and Gripes.

Security Issues

Insufficient Entropy in Ed25519 Keys
In-Band Negotiation for Message Signatures
Using Public Keys as AES-GCM Keys

Insufficient Entropy in Ed25519 Keys

One of the departures of Session from Signal is the use of Ed25519 rather than X25519 for everything.

Ed25519 Keypairs generated from their KeyPairUtilities object only have 128 bits of entropy, rather than the ~253 bits (after clamping) you’d expect from an Ed25519 seed.

fun generate(): KeyPairGenerationResult {    val seed = sodium.randomBytesBuf(16)    try {        return generate(seed)    } catch (exception: Exception) {        return generate()    }}fun generate(seed: ByteArray): KeyPairGenerationResult {    val padding = ByteArray(16) { 0 }    val ed25519KeyPair = sodium.cryptoSignSeedKeypair(seed + padding)

As an implementation detail, they encode a recovery key as a “mnemonic” (see also: a gripe about their mnemonic decoding).

Does This Matter?

You might think that clearing the highest 128 bits of the Ed25519 seed is fine for one of the following reasons:

It’s hashed with SHA512 before clamping.
Ed25519 only offers 128 bits of security.
Some secret third (and possibly unreasonable) argument.

It’s true that Ed25519 targets the 128-bit security level, if you’re focused on the security of the Elliptic Curve Discrete Logarithm Problem (ECDLP).

Achieving 128 bits of security in this model requires 256-bit secrets, since the best attack against the ECDLP finds a discrete logarithm in guesses.

Additionally, having 256-bit secrets makes the multi-user security of the scheme easy to reason about, whereas 128-bit secrets makes it a lot harder. (This mostly comes up in criticism of AES, which has a 128-bit block size.)

When your secret only has possible values, your multi-user security is no longer as secure as Ed25519 expects.

Additionally, you can shove the SHA512 + clamping in your attack script (thus negating the first objection) and find the corresponding secret key in queries if you know the top 128 bits were initialized to 0, using a modified version of Pollard’s rho for discrete logarithms.

This means that Session’s KeyPairUtilities class only provides 64 bits of ECDLP security.

CMYKat

What does 64 bits of ECDLP Security actually mean?

I provided a technical definition already, but that’s probably not meaningful to most people outside computer security.

What this means is that a distributed computing effort can find the secret key for a given Ed25519 public key generated from this algorithm in only queries.

For flavor, queries is approximately the attack cost to find a SHA1 collision, which we know is possible and economical.

Based on this attack, the authors projected that a collision attack on SHA-1 may cost between US$75K and US$120K by renting GPU computing time on Amazon EC2 using spot-instances, which is significantly lower than Schneier’s 2012 estimates.
— from the Shattered paper, page 2.

I don’t know if this was mere stupidity or an intentional NOBUS backdoor that only well-resourced adversaries can crack. (I also don’t have hundreds of thousands of dollars lying around to test this myself.)

How would you exploit this in practice?

If you’re not familiar with Pollard’s rho, then this section might be a bit abstract and difficult to follow.

Instead of directly passing a full 256-bit value to your oracle with each iteration (like you do with a standard Pollard’s rho implementation), you would need mutate the output the same way Session does (n.b., replace 128 bits of the seed with zeroes), hash & clamp that, and then perform the scalar multiplication.

It should be a bit more expensive than a raw ECDLP attack against a 128-bit curve (due to the hashing), but the strategy should succeed in the expected number of queries (average case).

Although this makes the attack totally feasible for a nation state, I do not have the resources to build and test a proof of concept against a candidate keypair. If anyone does, get in touch, it would make for a fun research project.

CMYKat

Alternatively, Pollard’s kangaroo might be a better cryptanalysis technique for Session’s setup.

Note: If there is any classified government algorithm especially suited for cracking Ed25519 keys constructed exactly like Session does, it’s not one I’ve ever heard of. I don’t have any security clearances, nor do I want one.
However, ECDLP security of elliptic curve-based protocols is extremely well-understood in the cryptography literature.

In-Band Negotiation for Message Signatures

If you thought the previous issue was mitigated by the use of Ed25519 signatures on each message, don’t worry, the Session developers screwed this up too!

// 2. ) Get the message partsval signature = plaintextWithMetadata.sliceArray(plaintextWithMetadata.size - signatureSize until plaintextWithMetadata.size)val senderED25519PublicKey = plaintextWithMetadata.sliceArray(plaintextWithMetadata.size - (signatureSize + ed25519PublicKeySize) until plaintextWithMetadata.size - signatureSize)val plaintext = plaintextWithMetadata.sliceArray(0 until plaintextWithMetadata.size - (signatureSize + ed25519PublicKeySize))// 3. ) Verify the signatureval verificationData = (plaintext + senderED25519PublicKey + recipientX25519PublicKey)try {    val isValid = sodium.cryptoSignVerifyDetached(signature, verificationData, verificationData.size, senderED25519PublicKey)    if (!isValid) { throw Error.InvalidSignature }} catch (exception: Exception) {    Log.d("Loki", "Couldn't verify message signature due to error: $exception.")    throw Error.InvalidSignature}

What this code is doing (after decryption):

Grab the public key from the payload.
Grab the signature from the payload.
Verify that the signature on the rest of the payload is valid… for the public key that was included in the payload.

Congratulations, Session, you successfully reduced the utility of Ed25519 to that of a CRC32!

Art: AJ

Using Public Keys As AES-GCM Keys

I wasn’t entirely sure whether this belongs in the “gripes” section or not, because it’s so blatantly stupid that there’s basically no way Quarkslab would miss it if it mattered.

When encrypting payloads for onion routing, it uses the X25519 public key… as a symmetric key, for AES-GCM. See, encryptPayloadForDestination().

val result = AESGCM.encrypt(plaintext, x25519PublicKey)deferred.resolve(result)

Session also does this inside of encryptHop().

val plaintext = encode(previousEncryptionResult.ciphertext, payload)val result = AESGCM.encrypt(plaintext, x25519PublicKey)

In case you thought, maybe, that this is just a poorly named HPKE wrapper… nope!

 /** * Sync. Don't call from the main thread. */internal fun encrypt(plaintext: ByteArray, symmetricKey: ByteArray): ByteArray {    val iv = Util.getSecretBytes(ivSize)    synchronized(CIPHER_LOCK) {        val cipher = Cipher.getInstance("AES/GCM/NoPadding")        cipher.init(Cipher.ENCRYPT_MODE, SecretKeySpec(symmetricKey, "AES"), GCMParameterSpec(gcmTagSize, iv))        return ByteUtil.combine(iv, cipher.doFinal(plaintext))    }}

This obviously doesn’t encrypt it such that only the recipient (that owns the secret key corresponding to the public key) can decrypt the message. It makes it to where anyone that knows the public key can decrypt it.

I wonder if this impacts their onion routing assumptions?

Why should I trust session?
(…)
When using Session, your messages are sent to their destinations through a decentralised onion routing network similar to Tor (with a few key differences) (…)
Session FAQs

Gripes

Some of these aren’t really security issues, but are things I found annoying as a security engineer that specializes in applied cryptography.

Mnemonic Decoding Isn’t Constant-Time
Unsafe Use of SecureRandom on Android

Mnemonic Decoding Isn’t Constant-Time

The way mnemonics are decoded involves the modulo operator, which implicitly uses integer division (which neither Java nor Kotlin nor Swift implement in constant-time).

return wordIndexes.windowed(3, 3) { (w1, w2, w3) ->    val x = w1 + n * ((n - w1 + w2) % n) + n * n * ((n - w2 + w3) % n)    if (x % n != w1.toLong()) throw DecodingError.Generic    val string = "0000000" + x.toString(16)    swap(string.substring(string.length - 8 until string.length))}.joinToString(separator = "") { it }

This isn’t a real security problem, but I did find it annoying to see in an app evangelized as “better than Signal” on privacy forums.

Unsafe Use of SecureRandom on Android

The recommended way to get secure random numbers on Android (or any Java or Kotlin software, really) is simply new SecureRandom(). If you’re running a service in a high-demand environment, you can take extra care to make a thread-local instance of SecureRandom. But a local RNG for a single user isn’t that.

What does Session do? They use SHA1PRNG, of course.

public static byte[] getSecretBytes(int size) {  try {    byte[] secret = new byte[size];    SecureRandom.getInstance("SHA1PRNG").nextBytes(secret);    return secret;  } catch (NoSuchAlgorithmException e) {    throw new AssertionError(e);  }}

And again here.

SecureRandom secureRandom = SecureRandom.getInstance("SHA1PRNG");

Why would anyone care about this?

On modern Android devices, this isn’t a major concern, but the use of SHA1PRNG used to be a source of vulnerabilities in Android apps. (See also: this slide deck.)

Closing Thoughts

There are a lot of Session’s design decisions that are poorly specified in their Whitepaper and I didn’t look at. For example, how group messaging keys are managed.

When I did try to skim that part of the code, I did find a component where you can coerce Android clients into running a moderately expensive Argon2 KDF by simply deleting the nonce from the message.

val isArgon2Based = (intermediate["nonce"] == null)if (isArgon2Based) {    // Handle old Argon2-based encryption used before HF16

That’s hilarious.

Cryptography nerds should NOT be finding the software that activists trust with their privacy hilarious.

CMYKat

So if you were wondering what my opinion on Session is, now you know: Don’t use Session. Don’t let your friends use Session.

If you’re curious about the cryptography used by other messaging apps, please refer to this page that collects my blogs about this topic.

#AESGCM #Android #asymmetricCryptography #cryptography #E2EE #Ed25519 #Java #Kotlin #messagingApps #OnlinePrivacy #privateMessaging #Session #Signal #SignalAlternatives #vuln

#aesgcm #android #asymmetriccryptography #cryptography #e2ee #ed25519

Pixelcode 🇺🇦 @[email protected] · 2024-12-10 · 06:08 UTC

You may have noticed that I updated my #Keyoxide profile link in various places. That was legit – my old RSA #OpenPGP key had expired back in early November without me noticing, and yesterday, I created a new #ed25519 key. If you still see my old Keyoxide link somewhere, please tell me. #pgp #rsa

🔗 https://keyoxide.org/FEF07E34F003F58EF486E744A49FCA80F5B7DE61

First, however, I had to manually update #GPG to version 2.4 by compiling it from source. 🤡

🔗 https://www.procustodibus.com/blog/2023/02/gpg-2-4-on-ubuntu-22-04/

QT https://fed.brid.gy/r/https://bsky.app/profile/did:plc:dxkyhpbv4bsktz3x2yp6m2rz/post/3lcvpgpgnu22j

#keyoxide #openpgp #ed25519 #pgp #rsa #gpg