KILT Messaging

Distributed trust on the internet only works if credentials and other information can be exchanged securely, and communicating parties can be confident that bad actors aren't fooling or eavesdropping on them. KILT provides a transport-agnostic messaging layer that helps with securely exchanging data between the respective owners of two DIDs.

This messaging layer provides authenticated end-to-end encryption, the gold standard in secure communication, in a way that hides the security of the technologies used for transporting the message over the internet – be it sending the encrypted messages via email, or posting them to and fetching them from a centralized or decentralized messaging service.

info

The messaging layer enables secure communication between two digital identities, DIDs. A necessary condition for secure communication with a given person or organization is to make sure that the DID on the other side of the communication channel is really controlled by the other party to avoid attacks such as Man in the Middle (MitM) attacks.

To be able to communicate, the two DIDs need to expose key agreement public keys for that purpose (a.k.a., an encryption key). To send a message to the other party, a DID owner (called Alice) looks up her peer's (called Bob) encryption public key, which can be part of either a full DID or a light DID. Using this key in combination with her secret encryption key, Alice can now encrypt the message such that only she and Bob can decrypt it. A nonce introduces randomness and uniqueness into encryption operations, making it highly challenging for an attacker to predict or replicate the encryption process. Each message has a different nonce, resulting in the creation of a unique encryption context for every message.

Bob can decrypt this message after looking up Alice's encryption key. An additional message authentication code (MAC) added during encryption and verified on decryption protects against manipulation of the encrypted data. As long as both parties keep their secret keys well protected, the combination of these measures allows Bob to be confident that if the message decrypts successfully, only Alice could have encrypted it and that malicious third party hasn't read or tampered with it while in transport.

While encrypted, the message travels in a compact and privacy-preserving envelope format that only exposes data that the recipient needs to be able to decrypt.

{
  "ciphertext": "0x973b9e43299ef41644e5d4122371e2adaa587441ee0682eef6b3dc3db5fd452be05d9d3b696b5ed8267addf86125d661aeff66cd234a2df144073efbc03001cf36f1c40af1a310a9acbd10974de000517b5712ea6f19649df88bb61a9194139a9701c16adc0fc0e0fb03efc2fc65b0d163303efe1a5249a15b9c4dbbfc97de0e43485214b0c5510b3d52cba6ae4b67e6ed7376cda070ee54a6ed7936aecda3b1611a2cf0c35c84f8af48081d92a9d9e965d61f9c5c60f2104236506a83801541c45b2413a849447f40d74f86c58f52e65e9125997b63ef2f289305e386dc3d97f65c68bc6a01d8e567fe1323d83b5a2ef22877f1aadf0a60873f423fb423c812e4e3cec958f515d7a73bf3309254622948beebed211c862567067858df2121d1678c0578e90600f9bb127d605f1a54a01a7f19b64108d1b5febf285e4dcf7d62c0765645699d7b41751aa89fbe9b8064ba2f202fea361b6e5a643e759acd779d58ab541061956dd7a0f8a8230c3ee87355bd2c391356df765752f0e0e937ac2f9412afc1e26588028a2973e4276a30ab853356cd4b0afb",
  "nonce": "0x010101010101010101010101010101010101010101010101",
  "senderKeyUri": "did:kilt:4qWb21mMmWjbgsVuQPJ1f9VFQMbyZwDSFC5wTzJZC91ehVam#0x6833db3ef3c37f865f769ac12b7c70e84d5d219622c941d3fa5199ac6be8ba8f",
  "receiverKeyUri": "did:kilt:4t9FPVbcN42UMxt3Z2Y4Wx38qPL8bLduAB11gLZSwn5hVEfH#0x04e74f9e54eb74179d3661aa2b3dc927b457c05d15b9ce0d50a9a3d58bcf9153"
}

The encrypted message not only references the DIDs of sender and recipient, it also references the unique identifier of the keys that used in encryption. Therefore, this scheme still works if a DID should expose multiple encryption keys from which a message sender may choose.

caution

While no one can read or change what's inside an encrypted message even if they intercept it while traveling on the network, a sophisticated attacker may try to guess what's inside and trick either side of the channel by resubmitting a copy of that message later. For a detailed developer-oriented guide about how to protect against replay attacks, read the Replay Protection Cookbook section.