MAM handling layer

[phifty]

Description

Added a layer to transmit and receive MAM messages.

The logic is based on MAM.client.js. I've scratched my head over some parts of the JS implementation, so I advise a careful review.

Fixes #118

Type of change

• Enhancement (non-breaking change which adds functionality)

How Has This Been Tested?

Test first. There are Unit-tests and I wrote two example programs to transmit and receive messages to/from the tangle.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have written example code according to the contribution guidelines
• I have added tests using ginkgo that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[luca-moser]

Hey Philipp, thanks for the PR! We really appreciate your contribution. I have added some review comments, mostly semantic things.

[phifty]

Thanks for the review. I'll have a closer look on it soon.

The thing that makes me wondering in the javascript implementation (and I transferred the logic here) is, that the messages in a private channel gets encrypted with 9999... (see here) Is that correct? A derived key from the seed should be more appropriate in my eyes. Or am I missing something out?

[phifty]

Any further comments on this?

[luca-moser]

You'll have to wait a little, I am currently busy with IRI. Will have another look at your PR once I'm done.

[luca-moser]

@phifty

The thing that makes me wondering in the javascript implementation (and I transferred the logic here) is, that the messages in a private channel gets encrypted with 9999... (see here) Is that correct?

Users of the JavaScript library need to use changeMode() in order to set the given channel mode and provide a side key which then isn't all 999...s.

I've added some further review comments as the logic inside Receive() is buggy rn.

[phifty]

@phifty

The thing that makes me wondering in the javascript implementation (and I transferred the logic here) is, that the messages in a private channel gets encrypted with 9999... (see here) Is that correct?

Users of the JavaScript library need to use changeMode() in order to set the given channel mode and provide a side key which then isn't all 999...s.

Ok, so let me just clarify the user interface here. Taken form the javascript implementation, the differences between the channel modes are...

• In public channel mode
  • the sidekey is optional and will be used as provided
  • the transaction address is the merkle tree root
• In restricted channel mode
  • the sidekey is required
  • the transaction address is a hash of the merkle tree root
• In private channel mode
  • the sidekey is optional and will be used as provided
  • the transaction address is a hash of the merkle tree root

Is the purpose of the private mode to obfuscate the transaction address? Or should there be more differences?

[luca-moser]

• In public mode there is no side key and the address/merkle root is used to encrypt/decrypt the message. Everybody can read it because the address is public.
• In private mode you encrypt/decrypt using the merkle root but the hash of the merkle root is used as the address. So it's private because only you know the start root and hence are able to progress further in the message chain/read subsequent roots.
• Like private mode but you additionally use a side key for encryption/decryption. So given only the merkle root you can hash it to get the address where the message is located but you can't decrypt it because you don't have the side key.

[phifty]

Thanks for clarify! This logic is currently not reflected in the interface. Currently, it's easily usable in a wrong/insecure way. I'll do some more checks and a refactoring.

[luca-moser]

Thanks for your PR!

[phifty]

You're welcome. Thanks for merging!