Skip to content
This repository has been archived by the owner on Apr 3, 2023. It is now read-only.

Use stealth addresses or similar #73

Open
theymos opened this issue Jan 18, 2019 · 1 comment
Open

Use stealth addresses or similar #73

theymos opened this issue Jan 18, 2019 · 1 comment
Labels
help wanted Extra attention is needed research Requires further research

Comments

@theymos
Copy link

theymos commented Jan 18, 2019

A lot of sites want to reuse grinbox addresses, but this potentially leaks a lot of information to the server. It'd be better if you used stealth addresses. So:

  • Addresses would be A | B, with A and B being pubkeys.
  • The sender would calculate a one-time public key and R using the address and random data, and would use this one-time public key as the recipient's pubkey is used now.
  • The sender would upload R, the usual slate data, and their own pubkey to the server. If you're not already, the sender should always generate a new-per-transaction pubkey at this step - there's no reason not to.
  • The recipient would download all transactions from the server in the time period that they're interested in and scan each of them until they find one that they can get the private key for.

As a bandwidth optimization, you could generate a "key ID" as hash(days_since_epoch | address) (so it changes every day), and the server would require that you provide/subscribe-to the first few bits of this key ID in order to filter out a large percentage of the keys.

Since you're allowing for centralization anyway, there might be a more clever solution than just using stealth addresses, but I wasn't able to immediately think of one.

@lehnberg
Copy link
Contributor

Thank you very much for your proposal and for considering our service!

To be precise, users using grinbox today leak some metadata, i.e. which grinbox address transacts with which, and when. And from what IPs these requests come in from. We don’t like this, and are thinking actively about how to avoid this from happening.


As a mitigation, privacy-minded users can rotate between 2^32 different grinbox addresses, but this does not solve the problem fully as IPs are still exposed.

Your proposal is one approach, but comes at a performance and scalability cost. Once there are many transactions, users would have to download a lot of data in order to find their message.

Other potential approaches could be to introduce full TOR support, or simply encourage privacy-minded users to either run their own relay (the protocol supports federation), or connect to a relay they trust.



What do you think about those approaches?

@jaspervdm jaspervdm added help wanted Extra attention is needed research Requires further research labels Jul 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
help wanted Extra attention is needed research Requires further research
Projects
None yet
Development

No branches or pull requests

3 participants