[BOUNTY: 2.0 BTC] [CLAIMED] Message Signing in Armory

[etotheipi]

Ok, I assumed this was what you wanted
Released on github: https://github.com/jackjack-jj/jasvet/blob/master/jasvet.py

Great, I'll look at it when I get some time.  I won't get to it today, so if you want to tweak it any further, go ahead.  Perhaps, also add a few comments there (or here), describing exactly how the v1 signing is done.  Basically, just mention which parts of RFC2440 were used, and how the signature is created exactly (i.e. I assume it matches the version-0 format, but it should be noted).

And while you're at it, can you add a header to the file declaring that the code in this file is being released to the public domain? 

Thanks! 

[1715048772]

1715048772

[1715048772]

1715048772

[jackjack]

I just released on github before your message: https://github.com/jackjack-jj/jasvet/blob/master/jasvet.py

Ok for 64-chars wide blocks and headers, I'll change that
Yes for the dashes, newlines, and key recovery matters

Is the v1-Base64 you identified correctly?  It says "BEGIN SIGNATURE", but it should probably be "BEGINE BITCOIN MESSAGE", I assume the text and signature are both bundled in there.

Nope, RFC2440 divides everything in packets and as you didn't want/need packets I didn't know how to bundle them
Do you need a specific way to bundle them? If not I'll do (1byte header + r + s + message)


I didn't say anything about your CPP additional matter. Was I unclear somewhere?



Edit: I deleted my previous post to answer yours

[jackjack]

Perhaps, also add a few comments there (or here), describing exactly how the v1 signing is done.  Basically, just mention which parts of RFC2440 were used, and how the signature is created exactly (i.e. I assume it matches the version-0 format, but it should be noted).

Ok!

And while you're at it, can you add a header to the file declaring that the code in this file is being released to the public domain? 

It was the point of CC0, but I'll explicit

[etotheipi]

I just released on github before your message: https://github.com/jackjack-jj/jasvet/blob/master/jasvet.py

Ok for 64-chars wide blocks and headers, I'll change that
Yes for the dashes, newlines, and key recovery matters

Fantastic.

Is the v1-Base64 you identified correctly?  It says "BEGIN SIGNATURE", but it should probably be "BEGINE BITCOIN MESSAGE", I assume the text and signature are both bundled in there.

Nope, RFC2440 divides everything in packets and as you didn't want/need packets I didn't know how to bundle them
Do you need a specific way to bundle them? If not I'll do (1byte header + r + s + message)

I guess I don't understand.  The point v1 non-clearsign is that you get a single block of opaque base64 that contains the original message and the signature, together.  The user should have no idea what's in it until they copy it into their wallet and it will spit out the message only if the signature is valid.  This is considered ideal since users have a tendency to only look for the message header and trust it without checking.  This way, they can't get the message unless they also check the signature.  

Does RFC2440 not mention how to encode and concatenate this data?  You can see what I'm talking about by just doing a regular "gpg --sign --armor file.txt".  Then when you "gpg -v file.txt.asc" it checks the signature, and writes out the signed data to a file.  I don't need the file operations, but I do want the bundling.  

I didn't say anything about your CPP additional matter. Was I unclear somewhere?

No, I was just clarifying.  There seemed to be some confusion earlier about where the key recovery should happen.  I was just clarifying that it needs to happen in the python code, but I'll give "extra credit" for the Crypto++ implementation.

Thanks!

[jackjack]

Is the v1-Base64 you identified correctly?  It says "BEGIN SIGNATURE", but it should probably be "BEGINE BITCOIN MESSAGE", I assume the text and signature are both bundled in there.

Nope, RFC2440 divides everything in packets and as you didn't want/need packets I didn't know how to bundle them
Do you need a specific way to bundle them? If not I'll do (1byte header + r + s + message)

I guess I don't understand.  The point v1 non-clearsign is that you get a single block of opaque base64 that contains the original message and the signature, together.  The user should have no idea what's in it until they copy it into their wallet and it will spit out the message only if the signature is valid.  This is considered ideal since users have a tendency to only look for the message header and trust it without checking.  This way, they can't get the message unless they also check the signature.  

Does RFC2440 not mention how to encode and concatenate this data?  You can see what I'm talking about by just doing a regular "gpg --sign --armor file.txt".  Then when you "gpg -v file.txt.asc" it checks the signature, and writes out the signed data to a file.  I don't need the file operations, but I do want the bundling.  

RFC2440 says that you must communicate with blocks of packets, it describes all the types of packets you can create (signature, public key, private key, signer info, literal data, etc) and how to write them.
So yes it does mention how to bundle the sig+data, but as you said you didn't need OpenPGP compatibility I thought I didn't even have to stick to this 'packet rule'.

I'll try to be clearer:

• Bitcoin's base64 is base64( leading byte + r + s )
• My current code base64 (for v0, v1CS and v1B64) is base64( leading byte + r + s )
• RFC2440 works with packets:
  
  • Verifying a clear text needs only a signature packet: base64( type + length + 04 + hash algorithm byte + pubkey type byte + timestamp + ... + MPI(r) + MPI(s) )
  • Verifying with included text needs a signature packet and a literal data packet: base64( type of literal data packet + len of literal data packet + flag + 00 + timestamp + message + type of pubkey packet + length of pubkey packet + 04 + hash algorithm byte + pubkey type byte + timestamp + ... + MPI(r) + MPI(s) )

As you can see, OpenPGP doesn't contain the leading byte so anyway I can't use strict RFC2440 to concatenate sig+data
A choice must be made because we can't use strict RFC2440 rules

[etotheipi]

I'll try to be clearer:

• Bitcoin's base64 is base64( leading byte + r + s )
• My current code base64 (for v0, v1CS and v1B64) is base64( leading byte + r + s )
• RFC2440 works with packets:
  
  • Verifying a clear text needs only a signature packet: base64( type + length + 04 + hash algorithm byte + pubkey type byte + timestamp + ... + MPI(r) + MPI(s) )
  • Verifying with included text needs a signature packet and a literal data packet: base64( type of literal data packet + len of literal data packet + flag + 00 + timestamp + message + type of pubkey packet + length of pubkey packet + 04 + hash algorithm byte + pubkey type byte + timestamp + ... + MPI(r) + MPI(s) )

As you can see, OpenPGP doesn't contain the leading byte so anyway I can't use strict RFC2440 to concatenate sig+data
A choice must be made because we can't use strict RFC2440 rules

Understood.  It's okay to deviate from RFC2440 as long as it's documented.  The goal was simply to follow RFC2440 to standardize the implementation as much as possible, but knowing that there would be slight deviations from RFC2440 where it makes sense to use our Bitcoin conventions.  I am honestly not going to be picky about it, as long as what is chosen is well-defined and documented. 

[jackjack]

As a Bitcoin signed message will always have the same, fixed format I think we don't need to use packets as they are used to provide flexibility
That would for example lead to:

• signature = byte + r + s
• sig+msg = byte + r + s + msg

Text rules (dash, etc...) in RFC2440 can (and should imo) be used

That way we have a simple format

Code:

lb, r, s, msg = data[0] + data[1:33] + data[33:65] + data[65:]
if msg:
  ...
else:
  ...

Or tell me what you prefer

[etotheipi]

As a Bitcoin signed message will always have the same, fixed format I think we don't need to use packets as they are used to provide flexibility
That would for example lead to:

• signature = byte + r + s
• sig+msg = byte + r + s + msg

Text rules (dash, etc...) in RFC2440 can (and should imo) be used

That way we have a simple format

Code:

lb, r, s, msg = data[0] + data[1:33] + data[33:65] + data[65:]
if msg:
  ...
else:
  ...

Or tell me what you prefer

That sounds good to me.  We want the standardized encoding/formatting, but don't need to all the flexibility in those serializations, since we have a very static/simple system for Bitcoin.  So clearsign will be identical to RFC2440 for the message, dash-esc, etc, but the signature will only be 65 bytes in base64.  The opaque version will simply be the header & footer, with the the properly-formatted message as you described above, all converted to base64. 

Where does crc24 fit into this?  Was that implemented and used?  I didn't look too closely at where it fit in.  Or was it only useful for the OpenPGP-formatted stuff?

[jackjack]

Great

The CRC24 is used to check that the ASCII armor wasn't modified. So it's calculated on the data you send to base64, ie (lb+r+s) or (lb+r+s+msg)

[jackjack]

I changed the Readme, is it enough?

[etotheipi]

I changed the Readme, is it enough?

Code looks good, but I can't try it because I don't have the ecdsa module.  What/where is that?

[jackjack]

easy_install ecdsa must work
I'm sure I can get rid of that dependency though

[etotheipi]

easy_install ecdsa must work
I'm sure I can get rid of that dependency though

Ahh.  You know I never used easy_install, but I just tried it.  That really is easy! 

Okay, it works now.  I might have to dig in a little bit to tweak things.  But it looks like exactly what I wanted.  PM me a payment address.
Thanks jackjack!

[Pieter Wuille]

Just as a FYI, the C secp256k1 library I'm writing has support for creating recoverable signatures, and doing key recovery (though not the - admittedly weird - serialization that Bitcoin uses for it).

[jackjack]

Thanks
I think it's easily tweakable. If anybody (etotheipi or any reader in the future) got a problem, just PM me or complain here!

[jackjack]

As etotheipi asked me I just pushed a new version, which doesn't need any dependency

[picobit]

Ahh.  You know I never used easy_install, but I just tried it.  That really is easy! 

At least until you want to uninstall again.  No luck.  Which is why pip is preferred over easy_install, and preferably in a virtual_env.

[jackjack]

Ahh.  You know I never used easy_install, but I just tried it.  That really is easy! 

At least until you want to uninstall again.  No luck.  Which is why pip is preferred over easy_install, and preferably in a virtual_env.

Care to explain? I never heard anything about that

[picobit]

Ahh.  You know I never used easy_install, but I just tried it.  That really is easy! 

At least until you want to uninstall again.  No luck.  Which is why pip is preferred over easy_install, and preferably in a virtual_env.

Care to explain? I never heard anything about that

unlike real packaging systems, easy_install drops everything in the main Python directory structure.  There is no central database of what was installed by which package, and no way to uninstall the stuff again.  This can make it kind of hard to return to a clean installation, or to get rid of unnecessary packages.

[greBit]

I just released on github before your message: https://github.com/jackjack-jj/jasvet/blob/master/jasvet.py

Im trying to make a quick and dirty script to sign messages that are compatible with Bitcoin & Armory clients and came across your nicely written Python module .

Just wondering if you could give me a couple of pointers to get me started

#
#  Some tests with ugly output
#  You can delete the print commands in FormatText() after testing
#

pvk1='\x01'*32


text0='Hello world!'


FTVerbose=True
sv0=ASv0(pvk1, text0)
print sv0
verifySignature(sv0['address'], sv0['b64-signature'], sv0['message'])
print
print ASv1B64(pvk1, text0)
print
print ASv1CS(pvk1, text0)

How can I get a representation of my private key from base58 format (e.g. 5KWLD8VF29WR36qR2YM3wWLDuePHJAP4YKgCMcfvNN7TTxSFgFx) so I can plug it into `pvk1` ?

Can I just do the following ...

pvk1 = b58decode('5KWLD...', None)

Secondly, how can I calculate the public key from pvk1?

cheers!