topic in HDF should be hashed

[arnauorriols]

Description

BranchAnnouncements securely mask the topic of the new branch being created. However, messages published to the branch include the topic in the HDF, which is readable by anybody.

Solution

BranchAnnouncements and Keyloads (assuming #259) carry over the topic of the branch in a secure manner. This means that any subscriber that is supposed to be aware of a topic to which a message is sent, must have already gotten access to the topic plaintext. If the mapping of the cursors of the branches is done with the hash of the topics instead of their plaintext, the HDF only need to include such hash.

[DyrellC]

The only problem I see with this is that we store cursors based off of Topic, so if we don't have the Topic in the HDF, the insert_cursor() function will have to occur after unwrapping (which can potentially fail). This would change the logic order for handling each of the messages.

[arnauorriols]

If the mapping of the cursors of the branches is done with the hash of the topics instead of their plaintext, the HDF only need to include such hash.

Doesn't this already account for that?

[DyrellC]

Ah, yes it would, I misread that part. If we map by hash though we can only display hashes later (like when pulling topics() or when printint cursor store). Essentially in this approach once you've seen the plaintext and hash/store it, you'd never see the plaintext anywhere else again, which might make the creation of a new branch from an old topic a bit of a problem unless it's stored external to the stream for the users. 🤔

[kwek20]

Hmm it would also make it hard to join a stream and iterate all topics to join the ones you want (like we discussed a few weeks ago)