Building Crypviser
Cryptography and Layer 1 protocol development for secure messaging and VoIP
Crypviser set out to solve the oldest unsolved problem in public-key cryptography: how two strangers confirm each other's keys without taking a company's word for it.
Its answer was CSMP, a protocol that splits every user's public key between a blockchain and a server so that neither one can forge it alone. We built the cryptographic implementation and Layer 1 blockchain that carries it.
- Encryption was solved, key distribution was not
- CSMP splits every key so no single party can forge it
- The handshake lets two strangers check each other in nine steps
- Why we ruled out every public chain
- We cut Graphene down to identity, keys and permissions
- The commercial model ran on the same transactions as the security
- Merkle proofs brought verification practical on a phone
- Delivery, and what reached production
001
ClientCrypviser GmbH, a German company selling encrypted messaging to consumers and business users
002
ChallengeLet two users verify each other's encryption keys with no authority to trust, and make it work on a phone
003
SolutionAn implementation of the CSMP protocol on a dedicated Layer 1 blockchain, built from Graphene with the trading and asset functionality removed, keeping identity, keys, permissions, token payments and governance
004
EngagementQ3 2017 to early 2022
005
Aetsoft's roleCryptographic implementation, protocol design and engineering, Layer 1 delivery, continued development
Engagement lead
Pavel Sivayeu
CTO, Aetsoft Inc
Ran delivery and led the Aetsoft team across the engagement, 2020 to 2022
Encryption was solved, key distribution was not
Strong encryption has been a commodity for decades. What nobody had solved for ordinary users is the moment just before it. A device receives a public key and has to decide whether it really belongs to the person the user meant to reach.
Almost every messenger answers with a directory. The provider holds everyone's public keys and hands them out on request. Anyone who controls that directory can hand out a key of their own instead, decrypt everything that follows, re-encrypt it and pass it on. To both users, the conversation looks normal. This is the man-in-the-middle attack, and it does not require breaking any cipher.
Without a sound way to hand out and confirm keys, encryption is a house with a strong front door and open windows. Hard to force the door, easy to climb through a window nobody thought about.
Solving this for ordinary users means removing the need to trust a central key directory, without making them learn cryptography or manage keys themselves.
Solution
Registration proves an identity before it can be used
Registration creates three identifiers: a device key pair for first-contact authentication, a second key pair for the account, and CrypID, a hash of local-storage key fragments and the user's passphrase. CrypID never touches the blockchain. It signs the user in and encrypts local storage. A separate anonymous user ID keeps the server from linking chain activity to a person.
Writing the key half into the chain is itself a proof. The user spends authentication tokens to the server, carrying the key fragment as metadata. Only the holder of the matching secret key can spend those tokens, because spending means solving a cryptographic problem tied to CrypID. The server then sends tokens back and the app repeats the check in the other direction. Both sides end up knowing the fragment in the ledger is genuine. Any tampering on the way shows up at once.
CSMP applies this across three levels. On the device, storage is encrypted independently of the phone's own operating system.
On the network, every kind of traffic runs end to end encrypted, from chats to voice and video and file transfers. On the provider side, connections go peer to peer wherever the network allows. Crypviser's stated design principles were no tracking, no tracing and no metadata records.
We implemented this model in code and built the chain it depends on, which is the kind of blockchain development work that starts at the protocol layer and moves up. We also later returned to the question of user control over digital identity in our work on the Velocity verifiable credentials network, where people keep career credentials in a wallet and decide what to share.
Solution
The handshake lets two strangers check each other in nine steps
When one user starts a session with another, the two devices run an exchange that never requires either of them to trust the server's word.
The initiator opens with a nonce and a timestamp. The responder returns its own nonce and timestamp, plus a sealed package. Inside are the initiator's original values, the responder's identity and a hash of its key record, signed with its secret key and then encrypted with its CrypID. Signing before encrypting matters. It proves who wrote the contents, and not just who sealed the envelope.
The initiator cannot read that package, so it forwards it to the server over TLS, the same encrypted transport a browser uses for a secure web page. The server holds the responder's CrypID, decrypts it, and confirms the identity inside matches the one it has on file. It then fetches the responder's first key half from the blockchain, joins it to the second half in its own database, and checks the signature. Only then does it return the reconstructed key to the initiator, signed and encrypted.
The initiator now does the work that makes the whole design hold. It reads the responder's first key half from the blockchain itself. Joining that to the half the server supplied, it compares the result against the hash the responder sent in step two. It also checks that its own nonce came back unchanged and that the timestamp falls inside an acceptable window.
If every check passes, the initiator knows the key belongs to the responder. The proof is that the blockchain half and the server half agree with a hash that came from the responder directly. The responder then runs the same sequence in reverse. Replay is blocked by the nonces, and a compromised server cannot substitute a key without contradicting a ledger it does not control.
Solution
Why we ruled out every public chain
The protocol assumes a chain that enforces its own rules. We worked through the requirements with Crypviser and tested the cheaper route first, which is where our blockchain consulting engagements usually start.
The protocol assumes a chain that enforces its own rules. We worked through the requirements with Crypviser and tested the cheaper route first, which is where our blockchain consulting engagements usually start.
Public chains of that period offered one place to put data that was not a payment: a short note attached to a transfer. Every registration, key update and revocation would have to travel inside those notes. A note like that is opaque to the network, which cannot reject a malformed registration or stop one record contradicting another. Every rule would end up being checked afterwards by an app or a server, which puts the trusted party straight back into a protocol designed to remove it.
Two further costs came with that route. Reading a user's current state would mean replaying their whole history on a chain already carrying years of unrelated traffic. And the price of every write would follow the market value of a token Crypviser did not control.
A dedicated chain removed all four problems and cost more to build. We took that trade, and the chain we designed is the one that went into the product.
How a verified record moves through the system
We cut Graphene down to identity, keys and permissions
We started from Graphene, which sits behind BitShares, a protocol we have contributed to upstream. Cutting a Graphene chain back is one way to work on that codebase. Embedding an EVM in a BitShares fork is the opposite move, and we did that too, so Solidity contracts could hold the chain's own assets with no bridge in the path. To adapt the Graphene codebase for Crypviser, we removed the trading engine, market data functions, asset issuance and settlement, and the worker and vesting systems.
What was left was narrow but not minimal. It held the records that prove which key belongs to which account. It also kept what those records needed to work. Token transfers paid for authentication, subscription state decided how long a key stayed valid, and governance could change network settings and tariffs by vote.
Onto that we added the operations CSMP needs. Users publish and replace their own key halves. They request permission for services such as voice calling, and the relevant server grants it. Accounts move through defined states, and the network validates each transition itself instead of leaving it to an application. Registration became a right the company held and could pass to partners, so nobody could sign themselves up, which closed the cheapest route to filling the network with fake accounts.
Consensus and committee governance came across from Graphene unchanged. Network settings could then be changed by vote, without shipping a new protocol each time.
The commercial model ran on the same transactions as the security
Crypviser built payment into the protocol. CVCoin covered the blockchain transactions used to authenticate users, so payment and authentication ran through the same process.
That is unusual, and it solves a problem most subscription products share. Any rule living inside an app disappears with the app, since the app sits on the customer's device and can be replaced. Checking a key costs nothing, so a customer could take a verified key and run their own client indefinitely.
We carried the principle into the protocol, so payment set how long a published key stayed valid. The design has one limit, and it cuts both ways. Someone who already cached an expired or revoked key can go on checking it against the chain, because the ledger half is permanent. What they cannot do is reach anybody new, since an expired key can no longer be distributed safely.
Merkle proofs brought verification practical on a phone
Users check keys on a phone, and a phone cannot hold a blockchain. Merkle proofs were the way around it. We built them into the protocol so a client could confirm that one record belongs in the chain without holding the chain. The protocol interfaces were extended so apps could request those proofs and check them.
On top of the proofs came a light client, a crypto wallet and the mobile builds of the blockchain library. Crypviser's own team built the messenger apps. We built the chain underneath them, the cryptographic implementation, and the library that let an app talk to both.
During architecture design, we considered a model in which every smartphone would run a full node. The aim was to give each device the highest level of independent verification.
We tested the model against a scenario of one million registrations. Based on two registration transactions of roughly 250 bytes each, registration data alone would reach about 500 MB. Block headers, other transactions and implementation overhead would increase the total further.
Continuous synchronisation and verification would also consume bandwidth, memory and processing time. The cost would rise with every new user. We therefore documented the full-node model as an option. It was not implemented in the production product.
Crypviser released its messenger and the mainnet in 2018. The subscription model ran until the company made the app free at the end of 2021. We joined before Crypviser had chosen its blockchain architecture. We assessed the options, implemented the cryptography, and turned the protocol design into working code. Over the next five years, our work shifted to protocol updates as the product changed.
Cryptography. Crypviser's chief architect owned the security model. We contributed our own thinking to it, argued the parts we disagreed with, and turned the result into working code and the chain it required.
What the engagement delivered:
A working implementation of CSMP. The split-key model, the registration and token-proof sequence, and the nine-step authentication handshake, in code.
A dedicated Layer 1 built for Crypviser. Derived from Graphene and reduced to identity, keys and permissions, with new operations for key publication, permissions and delegated registration.
Verification that worked on a smartphone. Merkle-proof verification, extended protocol interfaces, a light client, a wallet and the mobile blockchain library.
Results
“The quality was really good, and we got the results we wanted. They delivered a well-developed and reliable blockchain platform that matches our technology requirements. Most of the development deliverables were provided on time and according to the designs. We worked with complex technology, including a new generation of cryptography.”
Vadim Andryan 
Former CEO, Crypviser GmbH.
Frequently asked questions about custom Layer 1 development
-
Why does key distribution need a blockchain at all?
It does not always. It needs one when you want users to verify each other without trusting you. A directory works fine if your users accept that you control it. Once that assumption fails, you need a record your own company cannot quietly edit, and that is a short list of technologies.
-
When is an existing chain the wrong choice?
Usually it is the right one and most products should use it. The question is whether the chain can enforce your rules itself. If your guarantees depend on rules the chain cannot read, something else has to enforce them, and in practice it will be your own app or your own server. Your users are still being asked to trust you.
-
Does a custom Layer 1 mean building from nothing?
Not here. This one started from Graphene and most of the engineering went into removal. Choosing a codebase whose consensus you already want, then cutting it back, is usually safer than a blank page. Other projects need the opposite. L3COS required three consensus mechanisms that did not exist yet, and VPLedger began from a consensus requirement that ruled out the usual options.
-
Can business rules really live in a protocol?
Some should. A protocol applies the same rules to every app on the network.In Crypviser, subscription payment determined how long a published key remained valid. Every compatible client reads the same validity state from the blockchain. We used the same principle on a securities tokenization platform. The protocol applied each instrument’s ownership and trading rules across the network.
We’ll analyse your requirements and define the right architecture. You’ll leave with a delivery roadmap.
