Hello,
I've made a proposal for a standardized ecies scheme for bitcoin
communication. To address gmaxwell's criticism, I'd like to also
follow up with a proposed change to BIP44, such that a structured
wallet would also include a series of identity keys, both addresses
which will be used for signing, and public keys which would be used
as destinations for encrypted messages.

If anyone is familiar with ECIES and would be interested, there is a
working implementation at http://memwallet.info/btcmssgs.html,
which also includes this whitepaper:

Abstract

This document describes a scheme for sending signed encrypted messages using bitcoin public and private keys.

Motivation

PGP and Bitmessage and other secure communications channels exist. This standard allows for secure messaging using a bitcoin wallet alone, without the need for other software. This standard allows the owner of an address to conveniently prove ownership to the holder of another address privately without the need for separate secure communications channels.

Specification: Message Format

In the rest of this text we will assume the public key cryptography used in Bitcoin. The || operator is concatenation. All operations are defined over binary, and not text conversion of the data. When serializing public keys the compressed encoding is always used, even if the input parameters are passed as uncompressed. Bitcoin addresses are always serialized from compressed public keys, and for mainnet. (directives to use testnet or uncompressed keys ignored) String literals are represented as if for the C programming language in native UTF-8. No assumptions are made about the payload message format, it may even be binary. Caveat Decryptor. Plain unformatted text message payloads are recommended to use utf-8.

This standard assumes the reader is familiar with the bitcoin compact signature format, which is a 65 byte signature which allows the verifier to recover the public key associated with the signature, eliminating the need to send it with the message. Once consequence of this format is that signatures of tampered messages will nearly always result in some public key, but it will not be the same as the orignial signing key. The address of the sender will be provided to enable validation of the signature. The format is a 1 byte recid, followed by ECDSA R then S values.

Summary of the functions defined:

Message Sending

Inputs:

Serialization output

Message Receiving

Inputs:

Output:

Test Vectors

By convention keys will be in WIF format, public keys in base58_check format, messages in c style UTF-8 string literals. Encrypted messages are in Base64 format. Compliant implementations will use random nonces from a cryptographically strong DRBG. For the units tests, they will be provided in hex format. The nonce bytes provided are to be used both for the ECIES ecies_nonce_bytes, as well as for the Signature algorithm.

Test vector 1

Test vector 2

Implementations

http://memwallet.info/btcmssgs.html

Acknowledgements

Implementation by: 76NPRHE2g5pSvbLgP8fEEtBvfPB4zte56veXdxXfaXcsQwRjZB aka 1Lk96ASyr3k6ZoTFGLrUgxGuctNKF24V5q Credit Must be given to bitaddress.org brainwallet.org, and many others who have made crypto and bitcoin easy to code for in javascript.