Blockchain Privacy-Enhancing Technology Series — Stealth Address (I)

Many of today’s blockchains, including Bitcoin and Ethereum, are open and public ledgers in the sense that there are no restrictions on participation and all transaction details are visible on the blockchain. In a public ledger, the transaction entities are only identified by their blockchain addresses, which are derived from the corresponding public keys. Public ledgers are generally considered to be “pseudo-anonymous”, which means that an address is linked to one person, but that person is unknown to the public. However, by analyzing the transaction graph and combining with other information, it is possible to reveal the true real world identity behind a blockchain address, as shown by recent research. People and corporations prefer to add privacy-enhancing features to blockchain transactions for various reasons, including but not limited to managing law-enforcement related issues and hiding sensitive, company-specific information.

Stealth Address Key Management Mechanisms

A stealth address is a privacy-enhancing technology for protecting the privacy of receivers of cryptocurrencies. Stealth addresses require the sender to create random, one-time address for every transaction on behalf of the recipient so that different payments made to the same payee are unlinkable.

Basic Stealth Address Protocol (BSAP)

The most basic stealth address scheme was first developed by a Bitcoin Forum member named ‘ByteCoin’ in 2011, which relies on the Elliptic Curve Diffie-Hellman (ECDH) protocol and works as follows:

• The sender and receiver have private/public key pairs (a, A) and (b, B), respectively, where A = a·G and B = b·G and G is the base point of an elliptic curve group.
• Both the sender and receiver can compute a shared secret c using the ECDH: c = H(a·b·G) = H(a·B) = H(b·A), where H(·) is a cryptographic hash function.
• The sender simply uses c·G as the ephemeral destination address for sending the payment.
• The receiver actively monitors the blockchain and checks whether some transaction has been sent to the purported destination address c·G. If it has, the payment can be spent using the corresponding private key c.

The design of BSAP has two major issues: i) The ephemeral destination address is fixed between two communication entities. Thus, the transactions between those entities can be easily linked; ii) Both the sender and receiver can compute the private key c. As a result, if the receiver does not spend the payment in a timely manner, the sender can change their mind and take the money back.

Improved Stealth Address Protocol (ISAP)

To address the design flaws in BSAP, an improved scheme, called ISAP, has been detailed by Nicolas van Saberhagen in CryptoNote’s white paper in 2013, which was later adapted by Peter Todd in the Bitcoin protocol in 2014. ISAP is an extension of BSAP, which applies an additive key derivation technique as described below:

• The receiver has a private/public key pair (b, B), where B = b·G and G is the base point of an elliptic curve group.
• The sender generates an ephemeral key pair (r, R), where R = r·G and transmits it with the transaction.
• Both the sender and receiver can compute a shared secret c using the ECDH: c = H(r·b·G) = H(r·B) = H(b·R), where H(·) is a cryptographic hash function.
• The sender uses c·G + B as the ephemeral destination address for sending the payment.
• The receiver actively monitors the blockchain and check whether some transaction has been sent to the purported destination address c·G + B. If it is, the payment can be spent using the corresponding private key c + b. Note that the ephemeral private key c + b can only be computed by the receiver.

While ISAP fixed the aforementioned design flaws of BSAP, a blockchain node still needs to use its private spending key b for actively scanning the blockchain for the purported destination address c·G + B, which is contrary to the common practice of securely storing private keys. The continuous usage of the private spending key significantly increases the risk of it being compromised.

Dual-Key Stealth Address Protocol (DKSAP)

To eliminate the private spending key overusage limitation of ISAP, a dual-key enhancement, DKSAP, was created by a developer known as rynomster/sdcoin in 2014 for ShadowSend, an efficient and decentralized anonymous wallet solution. The DKSAP has been implemented in a number of cryptocurrency systems since then, including Monero, Samourai Wallet, and TokenPay, just to name a few. The protocol takes advantage of two pairs of cryptographic keys, namely a ‘scan key’ pair and a ‘spend key’ pair, and computes a one-time payment address per transaction, as detailed below:

• The receiver has two private/public key pairs (s, S) and (b, B), where S = s·G and B = b·G are ‘scan public key’ and ‘spend public key’, respectively. Here G is the base point of an elliptic curve group.
• The sender generates an ephemeral key pair (r, R), where R = r·G and transmits it with the transaction.
• Both the sender and receiver can compute a shared secret c using the ECDH: c = H(r·s·G) = H(r·S) = H(s·R), where H(·) is a cryptographic hash function.
• The sender uses c·G + B as the ephemeral destination address for sending the payment.
• The receiver actively monitors the blockchain and checks whether some transaction has been sent to the purported destination address c·G + B. Depending on whether the wallet is encrypted, the receiver can compute the same destination address in two different ways, i.e., c·G + B = (c + b)·G. If there is a match, the payment can be spent using the corresponding private key c + b. Note that the ephemeral private key c + b can only be computed by the receiver.

In DKSAP, if an auditor or a proxy server exists in the system, the receiver can share the ‘scan private key’ s and the ‘spend public key’ B with the auditor/proxy server so that those entities can scan the blockchain transaction on behalf of the receiver. However, they are not able the compute the ephemeral private key c + b and spend the payment.

Challenges for Blockchain-Based Internet of Things (IoT) Systems

DKSAP provides strong anonymity for transaction receivers and enables them to receive unlinkable payments in practice. However, this approach does require blockchain nodes to constantly compute the purported destination addresses and find the corresponding matches in the blockchain. While this process works well for full-fledged computers, it poses new challenges for resource-constrained IoT devices. So the question is “can we adapt DKSAP to blockchain-based IoT systems by making certain trade-offs?” Furthermore, the transactions that use stealth addresses can be easily identified due to the presence of an ephemeral key, which results in some loss of privacy. Therefore, another question is “can we mitigate this loss of privacy from the presence of ephemeral keys when using stealth addresses?” To learn how IoTeX is approaching these challenges, please stay tuned for our next blog post on stealth addresses and IoT-based systems!

About IoTeX

IoTeX is the auto-scalable and privacy-centric blockchain infrastructure for the Internet of Things (IoT). IoTeX’s global team is comprised of Ph.Ds in Cryptography, Distributed Systems, and Machine Learning, top tier engineers, and experienced ecosystem builders. IoTeX is developing several in-house innovations to push the frontier of blockchain 3.0, including a blockchain-in-blockchain architecture for heterogeneous computing, lightning fast Roll-DPoS consensus mechanism, and lightweight privacy-preserving techniques, to bring autonomous device coordination to the masses.

Website: https://iotex.io/Twitter: https://twitter.com/iotex_ioTelegram Announcement Channel: https://t.me/iotexchannelTelegram Group: https://t.me/IoTeXGroupMedium: https://medium.com/@iotexReddit: https://www.reddit.com/r/IoTeX/