Crypto Contacts

[asbjornenge]

Crypto Contacts

NB! The technical solution has changes somewhat (ref. the Prelude section in my reply to @tromer below). 😄 👍

Motivation

I propose building a service to simplify discovery of public addresses (wallets). I propose doing this by creating a public index of hashed phone numbers pointing at a list of public adresses.

hash(nbr) -> btc - 1239712037123
          -> zec - t109830198209128309a
          -> eth - ....

Our phones are already full of contacts. If we can leverage the already existing information to lookup a public address - seems that could simplify the process of transacting with cryptographic tokens quite a bit. :+1: :tada:

Technical approach & security considerations

It would be implemented as a RESTful API where anyone can query for a list of addresses using a hashed mobile phone number. Typically aimed at wallet implementers.

The main difficulty is that the system needs some method of verifying that a certain number belongs to a specific individual - and that only he/she can update the records for the hashed number.

A straight forward solution would be to use a SMS-gateway which would send a "short lived update token" to the number in question and by using this token the user can update the records. This however has some downsides since SMS isn't exactly secure and since such a service would well qualify as a honeypot (if you can replace a busy address with your own).

A more robust solution might include a phonecall with a voice reading the token.

Other options might include adding additional "profile data" like email (or a more robust 2fa mechanism) upon intial registration. A notification system where one user can ping another to verify addresses. Notification on record changes. "User X has recently changed address, are you sure you want to send?" alerts Etc. etc.

All these safetymeasures have their own tradeoffs that need to carefully considered before landing on any specific solution. Feel free to help come up with additional and more robust alternatives!

In any case, having an easy way to check that the correct information is registered for a specific number (is my information correct?) and a streamlined solution for recovery is essential.

All software produced would be OSS.

Team and background

For now it's only me.

My name is Asbjørn Enge Andersen, and I've been a software engineer for 10+ years. I'm currently working as an infrastructure architect building cloud and service infrastructure for a SaaS product. Previously in my career I've been working tiny to major projects on all sorts of different stacks and levels of complexity. Everything from tiny webapps to major Enterprise deployments. Currently I prefer building network services and tools using JavaScript & Node.js.

I'm quite new to the crypto space however (not to worry, I'm not planning to roll my own :joy:). I've been following the space with interest for some time, and especially been interested in the ZCash project since I first heard about it. I have also been running a small ZEC GPU farm since the launch ⚡️ 🤖

Evaluation plan

If successful, at a high level, the project would help reduce the friction involved in transacting with tokens today.

If successful, at a lower level, the project would offer a robust and simple service / API for wallet implementers. Enabling the above high level goals while also reducing the probability that such a system becomes a pr. wallet solution.

If very succesful, it could turn into a sustainable business.

Scedule

Laying out a schedule for a software project like this is hard - as you might know :wink:

• Basic API design (1 month)
• Main infrastructure design and setup (2 weeks - includes monitoring and surrounding services)
• Security measures (3-6 months - allowing time for external verification)

Budget and justification

The idea would be to take some time off work initially to focus on the project full time. Anything from a few weeks to 1 month depending on how much is granted. So a big portion of funds would go to cover living expenses.

It will also require a moderate amount of funds dedicated to infrastructure hosting. Depending on traffic I would estimate no more than a few $100 / month.

In terms of long term sustainability; My main idea is to offer a paid service for wallet implementers where additional data about the owner of the number is included - things like a profile picture, name, etc. - whatever the user wants to upload. This step would most likely require a webapp of sorts where a user can register and upload this information (or via APIs implemented in wallets). Another idea to allow companies and other entities to register wallet using other information than their phone number, e.g. tax numbers or something official, and index their names (suddenly you can search for "amazon" or "stabucks NY" etc.).

PUH! I didn't really intend for this small idea of mine to turn into an actualt proposal, but here we are 😬 Please feel free to ask questions and pick the project apart. It's an idea that has been brewing for a while, but I surely haven't considered all aspects and security ramifications.

Thanks for reading it :smile: :+1: :wave:

[tromer]

@asbjornenge, what use cases do you have in mind, where people would like to send a ZEC payment by phone number (and aren't anyway in physical proximity to the recipient so they can scan a QR code)?

There are grave security concerns, including:

1. There's the risk of attackers using phone number porting to get control of a phone number. We're seeing this attack a lot these days. Which use cases remain adequately secure in the presence of these attacks?
2. Attackers can repeatedly query the service to find phone numbers of wallet owners, and then attack them via phishing, or even extortion (with phone# often leading to additional personal detials).
3. In the case of BTC and ETH addresses (which you mentioned), the attackers can even see the transactions and balance. And compromise what little anonymity Bitcoin and Ethereum might provide.

[asbjornenge]

@tromer Thanks for great feedback 😄 👍

The use case concern is an easy one. It is not hard to think of a case where I need to send funds to someone that is not in my proximity. Just yesterday I needed to send some funds to my friend who was booking a canoe trip for us. He was miles away and needed the funds quickly. In Norway we have a similar service / app called vipps, which connects phone numbers with bank accounts. It has spread like wildfire and people are using for anything from paying for lunch to buying used stuff online to sharing bills etc. It is very convenient. And it is what sparked my ideas; "Man, we need something like this for crypto" 😉

Now, for the security concerns...

Prelude

An improved approach would be one where the service never revels the actual public address, but generates a new public address for every query curl /<nbr>/btc, which in turn will forward funds to the registered address. Somewhat how https://shapeshift.io operates (perhaps it could even use shapeshift under the hood? 🤔 ). This would of course add some additional complexity to the service.

1. For this concern I have no solution other than making it as easy as possible to detect that this has happened and provide quick and easy recovery. E.g. by sending email + sms when records are updated (to previous email+nbr if those are changed) and also provide an easy way for users to verify that their details are still correct (e.g. "check my CryptoContact addresses" when expecting a big transaction).

2. This is somewhat mitigate by the prelude. An attacker could identify that a number (and thereby person) has registered on the service, but could not see any funds nor tie a returned address directly to a person (since a new address is generated for every query). If the fact that a person has a crypto address at all is an attack vector, it won't be for long (when it's commonplace). And a much more profitable approach would be to extort people who have been in the space for a long time and are likely to hold lots of tokens. Every BTC conference speaker list would be a good start.

3. This would be entirely mitigate by the prelude imho.

4. Service HACKED 😱 Another consideration is if the service were to be hacked. In this case an attacker would be able to connect phone number (person) with their public address, and that brings 2 and 3 back on the table. This won't be awesome. However it will not directly lead to anyone loosing funds. One "workaround" here would be to remind users that it's probably not the best idea to register your $ 1 billion cold storage BTC address to the service, but rather one you would like to use for everyday transactions.

Notes

If you are sending $ 1000 worth of funds to someone, it might be a better approach to meet in person and scan the QR code. It is the safest approach and for large amounts preferable. This imho does not cancel the usefulness of this service.

Scanning QR codes and sending around public addresses on slack / email / irc has it's own set of downsides. Anyone you pay by scanning a QR code can retrospectively see your public address on chain, and if you met in person he/she might very well know who you are and sell or in other ways misuse that connection.

A third note is that using mobile phone numbers is by no means the only identifier possible. It is a convenient one since phone and contact lists are already loaded with Name<->Nbr connections and most people use them. But one could just as easily picture @twitterhandle as the identifier, or email address. It could even be optional which one a user wants to register, and for strong security one could register multiple (as demonstrated by keybase).

I'm very much looking forward to hearing your response 😄 👍

[tromer]

Taking a step back:

Secure directory services for key establishment are a nontrivial problem, that's already tackled by other systems, like Signal and WhatsApp.

So how about the alternative approach of using an existing channel based on phone numbers (WhatsApp, Signal, or even plain SMS/MMS), and sending a payment over this channel, as discussed in https://github.com/zcash/zcash/issues/2432?

[asbjornenge]

@tromer interesting... 🤔

The discussion you link to is specific to zcash and frankly a bit over my head 😝 On the other hand, using something like an RSA handshaking protocol two parties could exchange keys securely over any insecure channel (for any token). Or...? 🙈 Seems weird that we haven't seen more attempts at building protocols like this? Maybe we have and I'm just not aware? Imho a major hurdle to mainstream adoption is key (wallet address) exchange / discovery (as previously stated).

I would be happy to convert this project into an attempt at designing such a protocol with an accompanying library implementation. However I'm not sure I'm up for it with regards to my crypto skills.

I would design something like this:

w1 ---- elo ----> w2
w1 <---- pub2 ---- w2
w1 ---- pub2(secret1+salt) + pub1 ----> w2
w1 <---- pub1(secret2+salt) ---- w2

I'm pretty sure this would be too primitive. I'm not sure why 😝 🙈

[tromer]

@asbjornenge Exchanging keys over an insecure channel raises the problem of making sure you're taking to the right person (rather than an impostor or a man-in-the-middle), this is a very difficult problem --- that https://github.com/zcash/zcash/issues/2432 sidesteps by assuming the secure channel already exists. But you're right, securely realizing https://github.com/zcash/zcash/issues/2432 does require going into cryptographic details of the Zcash protocol.

[asbjornenge]

@tromer I think I'll have to save that for another day 😉 Seems it has blown a bit out of proportion either way, so I'll just pull it before I commit to something I cannot deliver. Thanks a bunch for reviewing my proposal and your feedback 👍

[tromer]

@asbjornenge, nonetheless, thanks for your interest in helping Zcash, and for tackling the problem of address discovery. This problem (known elsewhere as the Public Key Infrastructure problem) is indeed one of the hardest in applied cryptography... I hope to see tackle other problems, in the community and in future calls for grants.