Introducing Hive-Mail, a new, quantum-resistant messaging protocol on Hive
Can we use Hive for encrypted communication, in a way that messages will remain safe even after quantum computing becomes widespread?
Introducing "Hive Post-Quantum Mail", Hive-Mail for short.
TL;DR
I've built a new protocol for encrypted communication based on the Hive blockchain which uses Kyber-1024, a "post-quantum" asymmetric encryption algorithm. In addition to quantum resistance, this new system has other additional advantages, such as not requiring transfer of funds or Active Key signing for sending encrypted messages. This system is already fully functional, but currently no GUI is available, only CLI.
GitHub address: https://github.com/hassemer-g/hive-mail/
Hive offers encrypted communication using encrypted memos attached to "transfer" operations. Here's a breakdown of what we already have:
→ Public Memo Key is derived from Private Memo Key using secp256k1 elliptic curve (same as used e.g. in Bitcoin)
→ shared secrets are built based on sender and recipient Memo Keys using ECDH [Elliptic Curve Diffie-Hellman]
→ the memo is encrypted using AES-256-CBC (an unauthenticated symmetric cipher)
The shortcomings of Hive's current encrypted memos system being:
→ user must necessarily transfer funds in order to send an encrypted message (even if only 0.001 HIVE or 0.001 HBD) — 😡 this is a huge annoyance
→ the Private Active Key is necessary to send encrypted messages (required for "transfer" operation) — 😈 this is bad for account security
→ the recipient of an encrypted message is publicly visible onchain
→ uses relatively weak authentication (4-byte checksum taken from hashed plaintext)
→ if the sender's Private Memo Key becomes compromised, an adversary can decrypt all messages sent by this user (that were sent using that private key)
→ the whole security falls apart if the private-public key system used by Hive is compromised (quantum computing [due to Shor's Algorithm] is expected to make secp256k1 for asymmetric key derivation obsolete) — 💀☠️ this means all encrypted messages sent using Hive Memo Keys will be vulnerable somewhere in the not-so-distant future, and will remain vulnerable even after the Hive adopts quantum-resistant cryptography chain-wide (only messages sent after such changes would be safe)
In sum, what does the new Hive-Mail have to offer?
→ onchain sending of encrypted messages with Posting Authority signing, without the need to send any funds
→ quantum-resistant encryption
→ recipient of messages not revealed onchain
→ messages remain safe, even if all the sender's keys (including his Private Post-Quantum Key) are compromised — because only the recipient can decrypt a message
How to use the Hive-Mail CLI?
The required Node.js libraries and other relevant infos are provided in the [brief] documentation at: https://github.com/hassemer-g/hive-mail/
The first step is creating an encrypted "message vault", just follow the console instructions. The process is straightforward and well explained in the console. When creating a vault, you will need to provide your Private Posting Key and Private Memo Key. You will also need to register at least one contact (i.e., another Hive account, with which you would like to communicate).
Once a vault is successfully built, you can send encrypted messages and search onchain for messages sent to you by your registered contacts. You can add more contacts at any time (choose "Alter save file").
In order to signal to someone that you would like to communicate using Hive-Mail, you can send to that person a traditional (transfer operation) encrypted message, which will be shown on the other user's account history. Just keep in mind, messages sent to you using Hive-Mail WILL NOT be shown in your account history; you will need to perform a search to get them (which is very simple).
In order to make this system work, I had to create a completely new key pair to be used by Hive accounts. I call it the "Post-Quantum Key". Just like any other key pair on Hive, there is a Private and a Public version of the Post-Quantum Key Pair. This new key is required for the quantum-resistant messaging Hive-Mail offers.
Whereas the Private Post-Quantum Key should be kept private (it is safely stored inside the vault), the Public Post-Quantum Key should be exposed onchain. I decided the best way to do this was to save the Public Post-Quantum Key in a Hive account's Posting Metadata. This also has the added advantage of requiring only Posting Authority to register or change your Post-Quantum Key!
Let's see an example, from my own account:
So, making it easier to read:
?tG/6e.uQ-P=?o+pD|Wc;1djm:PqCJ<v009DeeFiT}D7acXQ&XUoBgs_WVk]ZVqV[Fjsqc0%dBr#F`]ny*4nPpY!jdJR0J&>+D!Q%#N@c$=iZ!_]?:[[%P0Ru6Hv:7.7/T3/+yKIAOojT2g$@k/[+d01fyRiI3u)EI^yeR|*4oA|[BP^e2aDJq%bd(}Wne:JYjV8~F[2D=LHBSOlBFQvNjO!`A4NA8bSr<aXeYW!>O$u&y/73WDgZ5a)=1<I$8)sMDuO-Nr+sC:$1[&Mj[/_Kej[0E2L~vSi@dYH81{ep~Za+>Fo,|Hj];P?Vw9i-zb]&;D<_ZpL<uv&zJ8w}py|J5N.GT8QCS!-6sd,]ckI9!!G/cN<WE<tnu$cU(xJattLh!BK#kJS.DtVzI.>8UbA[6WDwA+dh!2^B{Bv!n((;bV7kr<O?Ex/`wX,ylOFmXhgf=>dNwcl)YF{_Cd)&64,+!sF|=G,+BaO;%O~(DRN<NrQ20?iro0<ET^:+4JINCE&2n{R/Xa=&lc[W)N8t|}fX9QmX7|yKa?fV?%$!A@_/[B##5-^$-=Isk~68+|);3U>grTfvbW4~nT6%N(d~]{#p,R0>f|ReZNN=)Fu+!TYdG2c?p0/.)Y8?M2Y8XLRkom#M!b5Krcx?pAZzO,cHy/&,lZ,kkQ9Oag@Jl)8z^VcpiHwsy1n&e[G2b]VA[j#Y/0E$nqa:Y}$X$?k{cV@kPA>)NeT+Q/P!Ay2a30_e3INQW*y$:g+C*e7[,5tiD(a}.xa}H|K9Ymn&1E^obfd*FV<}?cW]/em8EZo_)nQ4_7Cy.{OMV2X^gL{V1_9p$TQxw3ovp@$4rbddf]uEKzKN.&K1#+P_Ip&FA=w+mzT|yV=^/7{c}YU#j@}uU:L;;TDHo)+)_85q5bXPs@Mw%JTaDmh3tp0)^r0KNH!|h+BJ4y{O14wP&LEFZQvBtG:N5M&PYfzU9acF5u%~MYu]6(?u]qa[jIQtS`g.HRMH`HuDo^o{:<(|..J!:RTffC(doo4seNgD=lC_2R;1YUS5n`;H00^&Aqs8Cc?APO<L1-$+!0cPoq{zm+4b,UT1^sY^`t#V+Ue^Nm4u^C#,BcBFE_Mcd325x$o>9FdE~D$aQUE.+9IT{xBE;PZ4AWt9xCaZ%>::WSaxx*icDjEGB{[~10Ju8K9IxfH|n*N>g^lG+{]KyRH0s8:uPhY6L.a*[@]{O=)7?V.}DS7;S!m6z[zkkZ%ncnJt&_0|jQ^|UP`kYzH]m5<aOHpcG<[=OIp/cF/Q+v2.*(/C@ECs0ALBla*<S1YhI(V#QtS8U[t7%2G>r@wG3%B9u?S2j8_I;WNGndEBf[*5@S:K!q(;b).Cox8hsc$m[ZDuUJY!Va?Z<1DP;a;MKGgT~xis]:MaPcVhOK!k=$)Etm^,OxWkM1!~*jvBOj8ECY0U)Sk;BO3}4xcHt_A$Q?UrG8--DC-*fUWG$AdV)S%paa%i|S^59-F7!uK!PUDFp8N5xPPfr4I>8vvDqlQe(Qy3N,TR8eSSF2Hy<VBd#{k;eddq*I34zvQ6~2Uk9-.]Kl*lU0Nw4}cQ/[Q[n+ZbDLRqwJjct[M1G@0%#.hxpj/##&[}{7TC;Mz)i)MpI[E-C!4raxHtZ5Z<55n84qT;l@$`,>G/E{9z3}o~f$G^$6f;$`52uX,<vpJ]rAT,$&gP#ERoX5gd4g]uIQu9E,fbC_Mk!.7EjTUvS^J-n$![Z+P9+1McPg[Z@]LWc#dV`vs!c2vJEnA0tZ9~C5zV(<!${]FkVe!>mZAe21?gF|W))N0oX_p^5WkpQ~vewNbl_(ym|_9OW?+h&aDH;$C1:Z*8}Vj6U$0N)7rmGf`0nI5Jb>WEq1R0)c6eB/u+I^1pN^%1Y9;y9Die3As`E:H=o_&bE.}Zwk%%qiq0?w|7?HALu*vCo&bQ5h4-nbB
This absolutely lovely chunk of apparent gibberish is my current Public Post-Quantum Key. In order to maximise space efficiency, everything published onchain by Hive-Mail (including public keys and encrypted messages) is Base 91 encoded.
Post-Quantum keys are quite the brutes 💪🏻 A Private key has 3168 bytes, whereas the Public key (which is contained within the Private key) has 1568 bytes. No deriving of public keys from private keys using a point in a curve or anything of the like. Kyber is lattice-based, completely different from the asymmetric algorithms in use nearly everywhere today.
You can change your Post-Quantum key anytime you want, and your previous Private Post-Quantum keys are stored inside your vault, to ensure you are able to decrypt messages sent to you before you changed your key.
Onchain messages are encrypted using XChaCha20-Poly1305, an authenticated, reinforced version of the well-known ChaCha20 symmetric encryption algorithm.
Let's have a look at how an encrypted message onchain looks like:
Can any of you guys break this encryption and reveal the original message? 🙂
I know, I know, even regular Hive encrypted messages are still perfectly safe, up to now at least. The point being, Hive-Mail was built to offer robust security that will last.
That's it, I don't want to overextend this post. I hope you guys like this lil addition to our repertoire.
I for one think the best way for this new protocol to benefit the Hive community is to have it added to popular apps and UIs, such as the Hive Keychain (https://hive-keychain.com/ | @stoodkev), PeakD (https://peakd.com/), Ecency (https://ecency.com/ | @good-karma), etc.
Hey, let me and the rest of the Hive community know in the comments what you think of this creation! Suggestions very much welcome. Also, if you like, I could make more posts on Hive-Mail, delve into the detail of different aspects of this new feature on Hive.
Also, make sure to spread the word, if enough people endorse it, maybe we could have better communication functionalities added to Hive apps and websites someday.
Hey, this is pretty rad... I'm going to have to play with this.
Thanks! Do let me know what you think after testing it
This looks pretty neat, especially since the recipient isn't disclosed. Great job!
Thanks!! Make sure to test it
I will, once there's a more user-friendly version to the one described here :)
Sounds interesting. I gather that Hive can store all sorts of data and hiding the recipient is cool.
What are the risks to Hive in general from quantum computing? I'm not clued up on the encryption used.
Messages published onchain using Hive-Mail are quantum resistant, but this does not change anything in the way how Hive currently works. Hive like most blockchains is not expected to resist Shor's Algorithm when quantum computing reaches a certain number of logical qubits, likely ~2000. Meaning, at some point in the future, the algorithm used to derive key pairs in most blockchains including Hive will need to be changed. There's no reason for panic right now though.
Now, as I explained in my post, even after Hive changes algos to become quantum resistant, any encrypted messages published onchain prior to that will remain unchanged, i.e. easy prey to quantum computing, forever.
I'm sure plenty of people are worried about all sorts of old communications that could be cracked at some point. You can be sure governments are working on that.
Congratulations @hassemer! You have completed the following achievement on the Hive blockchain And have been rewarded with New badge(s)
Your next target is to reach 50 comments.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out our last posts:
Just to verify, it only requires one's posting authority to send and read messages, and also to create new post-quantum keys?
Thanks!
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.
Interesting for sure. Thanks for making it.
Does it use custom_json to send messages?
Also, are you aware of the Sting messaging protocol? You can use it on Peakd to send encrypted messages. It doesn't store the messages onchain which seems preferable from a security standpoint - what do you think?
Thanks! Make sure to test it.
Yes, encrypted messages are conveyed in custom_json ops, requiring only Posting Authority signing.
Yes, I'm aware PeakD offers this Sting messaging. However, I don't think my Hive-Mail is a competitor to that. This Sting on PeakD would compete with the likes of Telegram, Whatsapp, Signal, etc. I built Hive-Mail as an improved version of the existing Hive onchain encrypted messages. Simply as that.
Also worth mentioning, paramount in my design was that the only online infra required for the use of Hive-Mail is the very same to any other Hive service: Hive RPCs only. Everything is done locally, including all encryption/decryption. The user can be absolutely sure of what's happening, because the scripts are on his own local machine. And the only way (e.g. for a government) to censor/stifle Hive-Mail would require having the Hive blockchain as a whole censored, i.e. all its RPCs blocked.
This relatively long answer to explain that security and censorship-resistance, not convenience or even efficiency, was the motivation behind the new protocol. It is not meant as a substitute for existing communication protocols. If anything, it could be used to improve the existing onchain encrypted messages.
Really, Well Done This is so Good.
Thanks!
Hello hassemer!
It's nice to let you know that your article will take 8th place.
Your post is among 15 Best articles voted 7 days ago by the @hive-lu | King Lucoin Curator by deepresearch
You receive 🎖 0.2 unique LUBEST tokens as a reward. You can support Lu world and your curator, then he and you will receive 10x more of the winning token. There is a buyout offer waiting for him on the stock exchange. All you need to do is reblog Daily Report 751 with your winnings.
Buy Lu on the Hive-Engine exchange | World of Lu created by szejq
STOPor to resume write a wordSTART