Introducing IOTA Palantír Messaging (IPM)

A Masked Authenticated Messaging experiment

One of the reasons why we started to look into IOTA for our project “Untangle Care” was Masked Authenticated Messaging (MAM), which is a second layer data communication protocol on top of IOTA. This protocol, in theory, should be able to distribute healthcare data in a highly secure, decentralized, patient-centric way and therefore would be ideal for our project. In addition, this protocol also holds significant advantages over other similar blockchain related concepts: transactions are feeless and happen almost instantly. These two properties, in my opinion, make for example Ethereum based healthcare data solutions (crypto coins) cumbersome and unsuitable.

However, MAM is still in early stage and missing some off-tangle protocols around it to make it fully functional, like a key exchange, long-term storage and the possibility to send larger files. On top of it, if you use the current implementation and want to send MAM messages from your mobile phone, it takes quite some time to complete the proof-of-work (PoW) and therefore to actually send the message. Therefore, when I started to work on our chat app Chiota the idea was also to find and test possible solutions for these problems. As it turns out, I ended up removing the current MAM implementation completely (which might change in the future) and developed a NTRU based messaging solution, which I call IOTA Palantír Messaging or IPM, mostly because I don’t have a better name for it right now and I tried to stick with a Lord of the Rings theme for this article (see wikipedia Palantír article).

IPM Part 1: The NTRU Key Exchange

If you want to exchange messages in a quantum secure way, you need some form of appropriate key exchange. The most secure, but not very user-friendly way to do this is to exchange the keys in person. Another way is to use one of the available post-quantum key exchanges. Since RLWE has some problems if you keep reusing the same keys, I decided to use NTRU . This methodology has the additional benefits of being patent-free and can be extremely fast.

Let’s say Saruman and Sauron want to discuss Gandalf’s birthday present without his knowledge. The first thing both need to do is to generate an NTRU key pair. Luckily this can be done based on their IOTA seed, so they don’t need to remember or store anything except their seed. This way they also don’t need an additional random engine, which improves the overall security, since random engines are usually not completely random. Now both store their 1026 byte long public NTRU key (can be archived by using the following NTRU parameter sets APR2011743 or EES743EP1) on an IOTA address together with an additional address, which tells you where to send the contact request. Then Saruman tells Sauron the address where his public key and request address is stored. Sauron checks that there is only one valid public key/request address combination stored on this address. If this is the case, he can use the public key to send encrypted information to Saruman and tell him where to find his public key. If it’s not the case, he simply needs to wait until Saruman tells him his new public key address, which is automatically generated if two valid public key/request combinations are detected by Saruman’s device.

IPM Part 2: The Messaging

For the encrypted messaging Sauron and Saruman use a different NTRU parameter set (EES1499EP1FAST), which allows a maximum text size of 247 bytes, is close to 40 times faster and therefore makes it practical to use it also for encrypting small files (even without GPU support). The disadvantage is that each of these encrypted messages is 2066 bytes long and thus too big for one IOTA transaction (1300 bytes). However, you can split the messages into two transactions and do the PoW parallel (not in sequence!), so it takes the exact same time to send the transactions.

Let’s now imagine that Sauron comes up with a passphrase and a salt, which will be used to generate the new chat key. Additionally, he generates a random chat address, encrypts both information using the public key of Saruman and sends this information to him. Now both parties know the chat address and have access to the public chat key as well as the same private chat key. In theory, Sauron could decide to share the chat address/key also with the Witch-king of Angmar (I needed to google this one ?) and this way they could create a Gandalfs birthday present group chat.

If everyone sends all the messages to one address, over time it gets really slow to load new messages. To prevent this and to also make it more secure in IPM, after six messages on one address the next chat address is automatically created. This address is based on the decrypted content of the previous messages as well as on an incrementing part of the current chat address (Letter A to B, B to C and so on). This way, only the people participating (with keys) in the chat have access to the next chat address. The incrementing part assures that the chat address is changed even though everyone posts constantly the exact same message.

To integrate forward secrecy, like MAM, Sauron and Saruman could simply change the passphrase and salt of the chat key based on a similar system. This way, if they provide someone with a chat address and the chat key, this person only has easy access to the new messages and not the old messages. For example, if Sauron and Saruman at the beginning trash-talked about Elrond, but later want him to join the group, they probably don’t want him to see the earlier messages.

IPM Part 3: The File Transfer

Now Sauron finally has a cool idea for a birthday present and creates this nice ring for Gandalf and wants to share a picture of this ring (in a quantum-secure and decentralized manner) on the birthday group. Since he wants to make sure Gandalf doesn’t see the image before his birthday, he fully encrypts the image with the same NTRU parameter set as he used for chatting before the upload (= zero knowledge storage). If he does this, the size of the encrypted image will be approximately 8 times as big, so a 1,6 MB image will become a 13 MB image. To upload this on the tangle you would need to do the PoW 10.000 times and even Sauron doesn’t have the time or energy for this. An alternative for him would be to upload the encrypted image on a cloud storage and simply share the link to it in the chat group. The problem with this solution is that it is centralized. For example, once Sauron likes to switch to a different hosting provider for his image, the image link on the tangle won’t work any longer, because it might still say orcbox.com/imagename instead of the new balrog.com/imagename link.

To solve this problem Sauron uses the InterPlanetary File System (IPFS). With IPFS the files don’t get a unique address which tells you where to find something, but rather they simply get a unique fingerprint called a cryptographic hash. This way Sauron simply shares the unique fingerprint of his file inside the chat and can change the storage provider (=IPFS Gateway) of the file whenever he wants. To upload the file, Sauron uses an IPFS gateway (similar to an IOTA node) which stores the file permanently for him (pins). Saruman can then use an IPFS gateway of his choice to access this image.

IPM Part 4: The Long-term Storage

Currently, all information that doesn’t store any value is removed from the tangle every few months, during a so-called snapshot. In the future, every node can do these snapshots whenever they want. Therefore, Sauron and all the other chatting people from middle earth keep a local SQLite database on their devices, which stores all transactions. This obviously only works for small files.

(Beware: the following is not tested yet!)

Additionally, they upload backups of these transactions after every address changes (see part 2) through IPFS gateways. This backup also contains the cryptographic hash of the previous backup (if there is any of this chat), this way it’s possible to find the complete chat history (reduces the security of forward secrecy). Since the backup of the same chat always results in the exact same cryptographic hash there is a unique fingerprint for these backups, which makes it easy to prove the data integrity of the backup. Furthermore, since all people participating in a chat upload the exact same data, there will be automatically multiple copies, if they don’t use the same IPFS node.

To connect the current chat with the correct backups, Sauron and Saruman could easily attach the current hash fingerprint to every chat message. A different option would be to use a constant IPNS (interplanetary name service) address, which always links to the latest message backup.

Ideally, all the IPFS gateways used for specific purposes/groups are part of a decentralized storage cluster. Alternatively, the data is copied and stored by other “interested” nodes in the network to secure the existents of long-term backup copies. For example, in the healthcare sector, I envision that pharmacies, clinics, etc. run their own IPFS nodes and store (=pin) the encrypted data of their patients. This way they can immediately access the data anytime a patient gives them the key (even if the internet stops working). Furthermore, since these parties are to certain level trusted authorities, a Sybil attack becomes less likely.

Final words

IPM is not proven to be secure. On the one hand, advances in cryptanalysis may at some point break NTRU. On the other hand, I am not a cryptographic expert and tend to simply do/test things and improve them over time.

At the moment, not all of the features listed in this article are fully tested and integrated into Chiota. So, any help is highly appreciated, see https://github.com/Noc2/Chiota.

*more research is necessary regarding this number