1

The standard Bitcoin message signature works as follows:

sign(sha256(magicPrefix . length(message) . message))

The "magic prefix" is simply the string '\x18Bitcoin Signed Message:\n', where 0x18 is the length of the prefix text.

In other words, it's this:

sign(sha256(length(prefix) . prefix . length(message) . message))

My question is:

  1. Why does it use a magic prefix?
  2. Why does it include the lengths of the two components?

I'm asking mainly from a security point of view. Does adding a prefix or including the length(s) have any security benefits? If not, I'd like to drop it from my signatures.

Manish
  • 2,012
  • 20
  • 33
  • Is this from the C++ code? Because I saw similar code in pybitcointools' `electrum_sig_hash` function – Wizard Of Ozzie Apr 09 '15 at 01:50
  • It's also in BitcoinJS: https://github.com/bitcoinjs/bitcoinjs-lib/blob/1079bf95c1095f7fb018f6e4757277d83b7b9d07/src/message.js#L13 – Manish Apr 09 '15 at 02:02
  • 1
    The duplicate doesn't address the inclusion of the lengths. The answer is that it's to definitively protect against [length extension attacks](http://en.wikipedia.org/wiki/Length_extension_attack). – David Schwartz Apr 09 '15 at 08:37

1 Answers1

0

RFC4880 apparently standardises the way signatures work, so it could be referring to:

0x18: Subkey Binding Signature This signature is a statement by the top-level signing key that indicates that it owns the subkey. This signature is calculated directly on the primary key and subkey, and not on any User ID or other packets. A signature that binds a signing subkey MUST have an Embedded Signature subpacket in this binding signature that contains a 0x19 signature made by the signing subkey on the primary key and subkey.

But it seems much more likely BIP70 extension proposal is the reason for standardising signatures, as outlined by their BitID wallet implementation requirements:

To be compatible with the BitID protocol, a wallet must implement the following:

  • register the bitid scheme
  • throw a bitid intent when scanning a BitID QR code (if applicable)
  • decode the URI and verify its format
  • display a request for authentication showing the domain name callback and > - ask for validation
  • ask the user to pick up or create a Bitcoin address for the authentication (show the last Bitcoin address used if this is a known callback address)
  • sign the BitID URI with the private key (using the \x18Bitcoin Signed Message:\n#{message.size.chr}#{message} convention)
  • POST the signature and the public key to the callback URL completion dialog : success/retry/cancel
Community
  • 1
Wizard Of Ozzie
  • 5,268
  • 4
  • 30
  • 63