The signature scheme

To sign and verify messages, MAML uses RSA. It’s an asymmetric cryptographic algorithm that can be used for both encryption and digital signing. It uses a key pair consisting of a private key used to decrypt or sign data and a public key used to encrypt or verify signatures. The private key is kept secret and cannot be calculated from the public key.

Each channel participant owns a key pair and therefore both a private and a public key. Besides that, every participant holds the public keys of all other participants they trust. The process is illustrated by the following example:

Alice wants to publish a new message. She signs her message with her private key and publishes it. Bob sees a new message in the stream. He checks if his collection of public keys contains the public key found in the signature section of the message. Bob is aware of it and it seems like it’s Alice’s message. But to be really sure that the message was from Alice, Bob needs to verify the signature. He verifies the signature given the address, message data, signature and public key. It appears to be valid — Alice is the author of the message. Authentication and data integrity are guaranteed.

Anatomy of a message

MAML offers multi-part messages in which different sets of data are combined in a single body. Each message consists of following parts:

Private Restricted Signature

The private section can be read by all participants who can follow the stream. The restricted section makes fine grained access possible. That’s guaranteed by encrypting the data with the public key of a trusted party.

The simultaneous provision of private and restricted data contributes to flexibility. In both modes, the messages are only readable by those who are provided with the appropriate credentials.

The signature section contains the signature of the author as well as the appropriate public key. This public key is needed to know against which public key the signature must be verified. Every channel participant who holds the public key of an author can identify and verify the signature.

The message format was designed to be very lightweight. It’s a JSON string and consists of only a few fields so that the proof of work can be kept to a minimum. Since the next address is always derived from the current address, no pointer to the next address must be included in the message.

As indicated above, there exist use cases where for example every author inside a channel must stay anonymous, but at the same time observable and assignable for an external trusted party. This could be solved by signing the message with a random private key and add the genuie public key to the the author’s public key in the signature section with the public key of the trusted party. This would make a centrally controlled channel possible.

Status of the implementation

The first version of MAM Lite is published here on GitHub for Java. Lots of features are already implemented. You can create/split channels, post and read messages. Besides that, I have coded also a command line interface so that everyone, even non coders, can play with it, create their own channels and see how it works. The library was designed to be as easy to use as possible. [2]

In the following illustration, a new channel will be created. After publishing a few messages, the stream will be read. At the end I will load a totally different stream. All I need is an address of the stream (where I want to read from) and the appropriate password to follow it.