Message Encryption¶
Kaspeak SDK uses a set of well-studied cryptographic primitives to provide confidentiality, integrity, and compactness for transmitted data.
- ECDH — obtaining a shared secret between two parties without transmitting any private data.
- 2 x SHA-256 — deriving a fixed 256-bit key from the ECDH point.
- XChaCha20-Poly1305 — symmetric encryption and authentication.
- CBOR + Zstandard — object serialization and further compression.
How to Use Encryption in Your Application?¶
Kaspeak SDK automatically handles encryption and decryption of messages if your message class has the parameter requiresEncryption = true
.
You only need to provide the shared secret key, which is calculated using the recipient’s public key.
A typical workflow includes:
- Creating a message class that requires encryption;
- Obtaining a shared secret (key) via
sdk.deriveConversationKeys
; - Passing this key to the
sdk.encode
andsdk.decode
methods.
Below is a full example.
Full Example¶
Let’s create a message type that requires encryption:
This example demonstrates sending an encrypted message to yourself.
If the message is intended for someone else, pass the recipient's public key toderiveConversationKeys
.
How to Derive the Shared Secret for Decoding?¶
The shared secret key is formed using the SDK method deriveConversationKeys
, which takes the other party's public key:
secret
— the encryption key used for encoding and decoding messages.chainKey
— an additional identifier used for generating unique message points.
Extra Argument for encode
and decode
Methods¶
The encode
and decode
methods take an optional second argument — the encryption key:
If your message type is marked with the requiresEncryption
flag, the encryption key is required.
If the flag is not set, passing the key has no effect and will be ignored.
Thus, the SDK automatically ensures correct encryption and decryption of your messages.
How Does It Work Inside the SDK?¶
1. Forming the Symmetric Key¶
The key computed by both parties will be completely identical.
2. Serialization and Compression¶
CBOR provides a compact binary representation;
Zstandard further reduces the payload size.
3. Encryption¶
If the wrong key is used or the data is corrupted, decryption will fail, which reliably filters out foreign or damaged traffic.
4. Decryption¶
5. Authenticity Verification¶
Before sending, the entire payload is signed with the author's Schnorr signature at the SDK level.
As long as you do not disable the setSignatureVerificationEnabled
flag, you can be sure that the message truly belongs to the sender.
Any change in the bytes will result in a negative verification result on the SDK side.