IOTA MAM Ultra Lite
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:
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.
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:
{'MAML_protocol': MAML_Ed25519 (or MAML_RSA)
'data_payload': Some data here ....
'pubkey/hash': fgdwer8s7d6gdfg6d6fg8.....
'signature': fd7g9s8df7g98df7g...}
so that the code could switch and be agnostic to the type of MAML protocol.
Based on this suggestion I’m planning to expand the code to be able to handle Ed25519 and RSA streams on the fly. Code repository could be found here. You can reach me on IOTA Discord at stkubr#1936 or on Twitter @KubrakStan. If you like my work and want me to continue please feel free to buy me a beer by donating some Iotas on address:
EHNQJBGFAIUTJKPMSUCSDMIH9XTHANMJBVEZLFYURUXJUARTGKG9KDBHTCZHDKZZOGT9ENQEMHPOSLHPWXAELUPSDX
Thank you for your attention :)
UPD: yes NTRUSign scheme is broken — see here
