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:

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 store it to be able to verify the signatures in MAML. Otherwise if you join a public stream in a middle 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:

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 still need to exchange their RSA pubkeys, thus ensuring different life-cycles for signing keys and asymmetric encryption keys.