The creation of a "Hive-Mail vault" requires both the Private Posting Key and the Private Memo Key. The Active Key isn't used anywhere, for security reasons.
Specifically, the Posting Key is used to sign "custom_json" and "account_update2" operations. The custom_json are used for sending encrypted messages onchain, and the account_update2 are used to update the user's Posting Metadata with the updated Public Post-Quantum Key.
The Memo Key is used as an additional security element, alongside the Post-Quantum Key, to encrypt messages.
No Hive keys are required to create or update your Post-Quantum key pairs, but you will need your Posting Key in order to update it onchain (with an account_update2 operation).
Now, to read messages directed to you, you need only your Private Memo Key and Private Post-Quantum Key. The Posting Key isn't used for that.
Ok. The issue with using the Posting Key is that many frontends, such as Peakd, require the Posting Key. I believe others, such as 3Speak, also require posting authority over everyone that uses their frontend, but I know that Peakd does need it. So, all Peakd users are vulnerable to Peakd, or anyone with access to Peakd's stored user Posting Keys, and any other frontend on Hive that also uses the Posting Key authority of their users, can send encrypted messages as the user, and can update their Public Post-Quantum Key.
Unless I misunderstood and the Memo Key is also required for those transactions, which "The Memo Key is used as an additional security element, alongside the Post-Quantum Key, to encrypt messages." does seem to indicate.
I do not know of a frontend requiring access to the Memo Key at this time, so if both the Posting Key and the Memo Key are required for all operations the Posting Key is used for, then I do not think there is a security problem. If the Posting Key alone is used for any of these transactions, that's a problem.
Thanks!
Hey, I'd suggest you try to use the new protocol, these doubts you're having would most likely dissipate. It's CLI-only, but it's already fully functional.
That said, I understand your concern that Posting Keys are handled with considerable liberality, and that could pose a security threat to Hive-Mail. But this is not really the case.
First, anyone with your Posting Key can sign account_update2 and custom_json (not requiring Active) operations. This is not my doing; rather, this is dictated by Hive's code. This can be annoying but is not a serious security threat, since your funds can't be touched this way. People could, however, post really shitty things on Hive like they were you, which could lead to reputation damage.
Specifically regarding Hive-Mail, if someone malicious got your Posting Key, the maximum damage he could cause is register onchain (in your Posting Metadata) a different Public Post-Quantum Key. However, this would be promptly spotted (it's visible onchain), and the user could simply change his Posting Key, knowing it has been compromised. Then the user could change his publicly registered Public Post-Quantum Key, either reverting to the previous one or creating a brand new key.
What really matters here is, there is absolutely zero chance that anyone gets access to messages sent to you from obtaining your Posting Key. To read such messages, an adversary would need: 1) your Private Memo Key, 2) your Private Post-Quantum Key, and 3) he would need to know who you have been communicating with. If any of these elements is missing, there's no way to get access to the messages directed to you.
So, in sum, no, the Posting Key represents no threat to the privacy of Hive-Mail.
I very much appreciate you thoroughly addressing the concern I raised. From what I understand, the only potential threat from Posting Keys being available to others is that they could send encrypted messages as you, and the Posting Key being available to others already allows them to post unencrypted messages as you, anyway. Having your Posting Key would also allow them to change your public Quantum Encryption Key.
Is that a complete description of the potential ways an attacker could use your Posting Key?
Yes, that's a correct enumeration of risks. In sum, there's no privacy risk, IF the only compromised key is the Posting one.
A caveat though: you said "they could send encrypted messages as you" — however, sending messages AS YOU in any meaningful way would require that your adversary knows who you have been communicating with. Keep in mind that it is impossible to infer the addressee of a message sent with Hive-Mail, unless you are the addressee himself and have ALL the required private keys (Memo AND Post-Quantum) to decrypt the message. Not even the sender can decrypt a message, after it's sent. That's intentional, that's a feature, I built it like this on purpose.
Build it for Reticulum. Free speech is about to end on the internet.
Thanks for the suggestion. This is actually very interesting.
https://github.com/markqvist/sideband
Hive-Mail's quantum-resistant messages could be sent via Reticulum, if one didn't want them stored onchain on Hive. Still Hive would be useful, as the Public Memo Key and Public Post-Quantum Key are publicly stored onchain and can easily be fetched as needed (my code does that).
This pipeline would work even on something like Telegram, etc. The encryption protocol is built and working, one could send the messages using any rails he chooses.
That is excellent. Going forward, I see no reason Hive couldn't move to the Reticulum network and become truly decentralized and permissionless, where mesh density allows. Various Hive users are already subject to KYC internet, such as those from the UK, and from SK. Were Hive to adopt quantum resistant encryption, that would enable free speech to continue to be a feature of Hive regardless of the edicts of tyrants or owners of legacy centralized network infrastructure. Sites like Telegram et al. would still be required to comply (even if accessed through Reticulum) because they have owners that can be compelled by their jurisdictions, but the distributed witnesses and nodes of Hive aren't the owners of the platform, and no one has any ability to accept service of process, nor any ability to comply with jurisdictional requirements for the platform, as I understand it.