IOTA MAM Ultra Lite

By Coinmonks Last updated May 23, 2019

Lightest Masked Authenticated Messaging protocol for IOTA

Inspired by MAM Lite protocol, a light-weight alternative to MAM streams in IOTA, written by Samuel Rufinatscha I decided to re-implement it in Python. Doing so I stumbled into a few limitations, originated from RSA signature scheme used in MAML and therefore I opted to switch to another signature scheme, Ed25519 (the one that NANO uses). It has much shorter public keys and signatures and thus provides several advantages, that will be discussed later. As the result of an effort there is MAML_Ed25519 protocol library (no, not MAMUL ?), you can checkout the code and examples here.
Apart from using a different signature scheme, it has the similar features:

Authentication
Forward Secrecy
Stream access from every address
Channel splitting
AES encrypted

Now let’s discuss the differences.

First, consider RSA signature scheme:

RSA keys can be used both for encryption and signing, but they are quite lengthy, for example, RSA-3072 pubkey and signature in trytes are:

import iota
import base64
from ciphers import RSACipher
prikey_RSA, pubkey_RSA = RSACipher.generate_keys(3072)

# pubkey
pubkey_RSA_enc = base64.b64encode(pubkey_RSA.exportKey('DER'))
pubkey_RSA_trytes =  iota.TryteString.from_string(pubkey_RSA_enc.decode())
len(pubkey_RSA_trytes)
# 1128 trytes

# signature
sign_RSA = RSACipher.sign_message('test_message'.encode(),prikey_RSA)
len(iota.TryteString.from_string(sign_RSA.decode()))
# 1024 trytes

So to send RSA pubkey alongside with a data it takes approximately 1000 trytes and this is only the pubkey so far — the signature will also take about 1024 trytes. Keeping in mind that one transaction on Tangle have length of 2187 trytes, it is hard to put anything else meaningful in one transaction. The way to handle this is to keep only a hash of pubkey and splitting your JSON data in chunks over several Tangle transactions in one bundle, as it is done in MAML.

There is another drawback — having only a hash of pubkey supplied requires one to know a corresponding pubkey in advance and to store it to be able to verify the signatures in MAML. Otherwise if you join a public stream in a midwdle you woudn’t be able to verify and identify messages. Potentially this could be solved with the following trick:

H(pubkey) →Trytes [0:81]→Address →send_tx_to(Address)with_data({‘pubkey’:pubkey})

so that anyone knowing a hash of pubkey would know where to search or listen for a corresponding pubkey, compare with the hash and store it. But unlike traditional blockchains, Tangle prunes itself often(now even more often), so it would be necessary to rebroadcast your pubkey regularly.

Lastly, using the same RSA keys for signing and encrypting for restricted access messaging in the same time can become problematic, since signature and encryption keys should have different life-cycle.

Ed25519 signature is all about short keys and speed:

How short in IOTA trytes? Let’s have a look:

import iota
import base64
from ciphers import Ed25519Cipher

prikey_Ed25519, pubkey_Ed25519 = Ed25519Cipher.generate_keys()

# pubkey
pubkey_Ed25519_enc = pubkey_Ed25519.to_ascii(encoding = 'base64').decode()
pubkey_Ed25519_trytes = iota.TryteString.from_string(pubkey_Ed25519_enc)
len(pubkey_Ed25519_trytes)
# 86 trytes

# signature
sign_Ed25519 = Ed25519Cipher.sign_message('test_message'.encode(),prikey_Ed25519)
len(iota.TryteString.from_string(sign_Ed25519.decode()))
# 172 trytes

That’s a drastic difference! Now you can supply your JSON with pubkey, not just a hash, and it has roughly similar security level as RSA-3072 above.

Since Ed25519 cannot be used for encryption, for the fine grained access messaging within a stream the communicating entities would need to exchange their RSA pubkeys, thus ensuring different life-cycles for signing keys and asymmetric encryption keys.

As a conclusion I would like to point out that this not a battle of MAML protocols “which one is better”, but rather a suggestion for the unification of MAML streams, that can be done easily by adding one extra field to JSON: