Umbrella Protocol
Source-available cryptographic stack on IETF MLS (RFC 9420) with post-quantum extensions, targeting a Tier-D state-level adversary threat model.
ENEnglishRUРусскийKKҚазақUZOʻzbekchaUKУкраїнськаBEБеларускаяAZAzərbaycancaHYՀայերենKAქართულიZH中文HIहिन्दीESEspañolARالعربيةFRFrançaisBNবাংলাIDIndonesiaPTPortuguêsURاردوDEDeutschJA日本語PAਪੰਜਾਬੀSWKiswahiliVITiếng ViệtTEతెలుగుMRमराठीKO한국어TRTürkçeFAفارسیMSMelayuTLFilipinoTAதமிழ்HAHausaITItalianoTHไทยGUગુજરાતીPLPolskiYOYorùbáKNಕನ್ನಡMLമലയാളംMYMyanmarAMአማርኛIGIgboKUKurdîNLNederlandsRORomânăSOSoomaaliSIසිංහලNEनेपालीKMខ្មែរELΕλληνικάHUMagyarZUisiZuluCSČeštinaSVSvenskaCACatalàSRСрпскиBGБългарскиAFAfrikaansSQShqipLOລາວMNМонголHRHrvatskiSKSlovenčinaLTLietuviųSLSlovenščinaMKМакедонскиBSBosanskiLVLatviešuETEestiGAGaeilgeMTMaltiDADanskFISuomiNONorskHEעבריתKYКыргызчаTGТоҷикӣTKTürkmen
Founder profile
Kirill Abrams
Founder & CEO, UmbrellaX TOO
Building a privacy-first messenger and backend platform for one billion users under a jurisdiction outside the Five Eyes alliance.
Background
Kirill Abrams is the founder of UmbrellaX TOO, a Kazakhstan-based privacy company building a messenger and backend platform engineered for one billion users from day one. He is the author of Umbrella Protocol, a source-available cryptographic stack built on IETF MLS (RFC 9420) with post-quantum extensions, targeting a state-level adversary threat model (Tier D). His work spans the full stack: a 167-microservice Rust backend, iOS and Android clients, a self-hosted email service, and the public editorial operations of umbrellax.io. Kirill's approach is grounded in privacy-first design, self-hosted infrastructure, a jurisdiction outside the Five Eyes alliance, and transparent cryptographic review by independent auditors.
What I build
Backend at scale
167-microservice Rust platform engineered for one billion users from day one. Postman + Sealed Servers, 3-of-5 Shamir for cloud-mode key custody.
Privacy jurisdiction
UmbrellaX TOO registered in Kazakhstan, outside the Five Eyes alliance. Self-hosted email, no third-party analytics, no government channels.
Editorial ops
Public umbrellax.io blog with E-E-A-T sourcing, single-author byline, every claim traceable to a primary source.
Reach out
- x.com
- x.com/KirillAbrams
- GitHub
- github.com/KirillAbrams
- Website
- umbrellax.io
UmbrellaX private beta update
Beta moved to January 1, 2027
During our security review, we found serious issues in several open-source libraries used for encryption and secure communication. Local fixes are ready, but they still need full verification and independent review. I will not release the beta until I am confident these risks are closed.
Here is the complete list in plain language. Open a section to see what could go wrong, an everyday example, and the patch reference.
Group messaging and MLS state
Safer group updates and messages
Decrypted group secrets could leave extra copies in memory or diagnostics. Bad ciphertext, Welcome messages, proposals, update paths, missing local keys, random-number failures, unusual system time, and epoch limits could close the app instead of returning a safe error. Some tree integrity and path-length checks were also not guaranteed in every release path.
For example, a broken group update received from the network must be rejected without closing the messenger, skipping an integrity check, or exposing message bytes in a crash report.
Local fix prepared, verification in progress.
Technical details: openmls 0.8.1 | UMB-117, UMB-118, UMB-120, UMB-121, UMB-125, UMB-128, UMB-129, UMB-130, UMB-131, UMB-132, UMB-133, UMB-134, UMB-135, UMB-136, UMB-137, UMB-138, UMB-139
Complete removal of stored group data
Deleted or replaced MLS records could leave serialized copies or hidden proposal bodies in memory. Group snapshots needed scoped atomic replacement, debug access needed redaction, and an optional persistence mode stored readable encoded text instead of authenticated encrypted data.
For example, deleting a group must also remove its hidden pending proposals, and a storage option must not look encrypted when it only converts data to readable text.
Local fix prepared, verification in progress.
Technical details: openmls_memory_storage 0.5.0 | UMB-119, UMB-212, UMB-213, UMB-214
Message encryption and safe decryption
Removing a vulnerable optional crypto chain
An unused optional backend still pulled a vulnerable package into the dependency inventory. HPKE private material also needed stronger redaction and memory cleanup.
For example, a backend we do not use should not bring a known-vulnerable package into a release, and an error printout must never contain an HPKE private key.
Local fix prepared, verification in progress.
Technical details: hpke-rs 0.6.1 | RUSTSEC-2026-0124
Cleaning failed decryption buffers
The random generator and temporary HPKE values needed real cleanup. Failed authenticated decryption could also leave a partly modified plaintext buffer in memory.
For example, when a message fails authentication, the half-processed plaintext buffer should be erased immediately.
Local fix prepared, verification in progress.
Technical details: hpke-rs-rust-crypto 0.6.1 | UMB-122
Crypto errors must not close the app
Random state, key-derivation output, private-key bytes, and failed encryption buffers needed cleanup. Invalid nonce lengths and unsupported key exchange requests could reach process-ending paths.
For example, a malformed nonce must return a normal error instead of closing the messenger.
Local fix prepared, verification in progress.
Technical details: openmls_rust_crypto 0.5.1 | UMB-122, UMB-123, UMB-124
Keys and memory cleanup
Erasing temporary group-signature secrets
Signing nonces, shares, scalar bytes, and a temporary readable secret string needed cleanup on success and error paths. An unused feature also pulled an unmaintained dependency chain.
For example, temporary values used for a group signature should not remain readable in memory after signing finishes or fails.
Local fix prepared, verification in progress.
Technical details: frost-core 3.0.0 | local audited patch
Cleaning session-key ingredients
Discarded pseudorandom keys and intermediate key-expansion blocks could remain in memory after a final key was produced.
For example, after a session key is ready, the temporary ingredients used to derive it should be erased.
Local fix prepared, verification in progress.
Technical details: hkdf 0.12.4 | local compatibility backport
Cleaning authentication key material
Derived key blocks, oversized-key digests, and internal hash results in the compatible HMAC branch could remain in ordinary memory.
For example, verifying that a message is authentic should not leave reusable key-derived bytes behind.
Local fix prepared, verification in progress.
Technical details: hmac 0.12.1 | local compatibility backport
Extending cleanup in the current HMAC branch
The available cleanup option was off by default and covered only part of the temporary and stored key-derived state.
For example, completing an authentication check should clean both temporary and stored key-derived blocks.
Local fix prepared, verification in progress.
Technical details: hmac 0.13.0 | local audited patch
Erasing internal hash state
SHA-256 and SHA-512 working state and block counters needed drop-time cleanup on the compatible branch.
For example, hashing a secret during key derivation should not leave the hash engine's working state in reusable memory.
Local fix prepared, verification in progress.
Technical details: sha2 0.10.9 | local compatibility backport
Damaged or hostile input
Rejecting hostile lengths and damaged fields
A damaged input could request a huge allocation, read beyond its declared field, loop without progress, or trigger overflow and panic paths. Secret vector diagnostics and partial failed input also needed cleanup.
For example, a tiny message that falsely claims to contain a huge field must not consume huge memory or trap the app in an endless loop.
Local fix prepared, verification in progress.
Technical details: tls_codec 0.4.2 | local audited patch
Calls, relay passwords, and media encryption
Hiding relay authentication keys
The STUN message-integrity key could be printed in diagnostics and was not explicitly erased with temporary credential text.
For example, a connection error log must not reveal the secret used to authenticate a relay request.
Local fix prepared, verification in progress.
Technical details: stun 0.17.1 | audit patch 6e5cbb42
Erasing relay passwords
A long-lived TURN password was stored as an ordinary string and needed explicit erasure when the client was destroyed.
For example, ending a call should not leave its relay password in the old client object's memory.
Local fix prepared, verification in progress.
Technical details: turn 0.17.1 | audit patch 6e5cbb42
Removing call credentials from diagnostics
TURN usernames and passwords were stored as ordinary strings and automatically printed in ICE debug output.
For example, a call connection report may say credentials exist, but it must not print the username and password.
Local fix prepared, verification in progress.
Technical details: webrtc-ice 0.17.1 | audit patch 6e5cbb42
Cleaning encrypted-call keys and salts
Media key-derivation input, derived keys, stored SRTP/SRTCP salts, and cipher working state needed reliable cleanup.
For example, after an encrypted call ends, its temporary media keys and salts should not remain in ordinary buffers.
Local fix prepared, verification in progress.
Technical details: webrtc-srtp 0.17.1 | audit patch 6e5cbb42
For beta notes and access updates, follow my personal X account.