Update: Masked Authenticated Messaging (MAM) will be replaced by Streams in the future. To get the latest updates read our docs.
As you may know, Masked Authenticated Messaging (MAM) is a second layer data communication protocol which adds functionality to emit and access an encrypted data stream over the Tangle (IOTA’s distributed ledger). IOTA’s consensus protocol adds integrity to these message streams. Given these properties, MAM fulfills an important need in industries where integrity and privacy meet.
In IOTA, a user can publish a message at any time. They only need to conduct a small amount of Proof of Work (PoW) to allow the data to propagate through the network (this is necessary to prevent spamming of the network). If nodes are listening for the channel ID (i.e. address) in real time, the message (spread through the network) will be received by a subscriber when it reaches the subscriber’s node.
For an in-depth overview of MAM up until now and IOTA, please click here.
The current implementation of MAM in IOTA has always been considered a beta prototype implementation.
Since the middle of 2018, the IOTA Foundation has been engaged with the Belarusian State University (BSU) in their pursuit to develop a MAM protocol that has undergone a security evaluation, improved design, and reference implementation.
After extensive efforts by the BSU team, the final specification was delivered in early February — what we are referring to when we use MAM in IOTA.
Using this final specification, MAM entities of IOTA can:
- Create channels for broadcasting messages;
- Create channel endpoints for protecting messages during broadcasting;
- Protect messages in different ways, for example, turn on / off encryption / authentication;
- Split messages into parts (packets), protect and transmit each part almost independently;
- Set message recipients and provide them with key material in different ways.
Creating endpoints is new. The prototype version of MAM did not include these. In the prototype MAM, channel keys are used to sign the messages transmitted through the channel.
Unfortunately, a user can sign only a restricted number of messages. It is due to inherent onetime nature of MSS: a user cannot use a leaf private key twice.
Of course, after all leaf keys are used, a user can generate a new set of leaves, cover them with a new rootchid and continue with it. Since chid unambiguously identifies the channel, the user actually changes the channel.
The approach works but seems not to be very convenient. Indeed, after changing the channel the user generally loses her subscribes and has to make considerable efforts to reattach them (or subscribers have to make considerable efforts to get a new user’schid and to attach to it).
We think that channels and therefore chid should be as permanent as possible. To support such functionality, we propose to use additional keys subordinate to chid. It could be multi-time keys of MSS or other type or it could be fully permanent keys.
We can imagine broadcasting stations which are equipped with subordinate keys and which help channels to transmit messages. Each station has a certain operating resource. A channel can launch new stations after exhausting the resources of active ones. We call such imaginary stations endpoints.
Algorithms are grouped into layers. They are:
- Sponge (basic cryptographic processing of loosely formatted data);
- Spongos (basic cryptographic processing of strictly formatted data);
- WOTS (one-time signatures based on a hash algorithm from Sponge);
- MSS (multi-time signatures over WOTS);
- NTRU (public key encryption).
- Additional layers are:
- Protobuf3 (encoding, decoding and high-level cryptographic processing of messages);
- MAM (the overall protocol).
The team at the IOTA Foundation has been hard at work implementing the new MAM specification. You can view a list of all the closed and open issues in our GitHub here.
Currently the low-level layers of WORS, Sponge, and NTRU are complete. Based on our current pace, we are expecting to have the new version of MAM released in the C implementation by the middle of March.
We will update in Discord. as MAM becomes available in the rest of the client libraries. Please check #mam-discussions on Discord for ongoing updates.