etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2013, 06:16:12 PM |
|
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!
|
|
|
|
jackjack
Legendary
Offline
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2013, 06:18:50 PM |
|
I just released on github before your message: https://github.com/jackjack-jj/jasvet/blob/master/jasvet.pyOk 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
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
jackjack
Legendary
Offline
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2013, 06:25:41 PM |
|
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
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2013, 06:30:11 PM |
|
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
Legendary
Offline
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2013, 07:17:19 PM |
|
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
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2013, 07:32:07 PM |
|
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
Legendary
Offline
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2013, 08:16:20 PM |
|
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 lb, r, s, msg = data[0] + data[1:33] + data[33:65] + data[65:] if msg: ... else: ...
Or tell me what you prefer
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2013, 08:29:30 PM |
|
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 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
Legendary
Offline
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2013, 08:37:45 PM Last edit: May 11, 2013, 10:14:44 PM by 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)
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
jackjack
Legendary
Offline
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2013, 10:16:25 PM |
|
I changed the Readme, is it enough?
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 12, 2013, 12:10:47 AM |
|
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
Legendary
Offline
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 12, 2013, 01:11:50 AM |
|
easy_install ecdsa must work I'm sure I can get rid of that dependency though
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 12, 2013, 01:15:46 AM |
|
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
Legendary
Offline
Activity: 1072
Merit: 1181
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 12, 2013, 09:47:02 AM |
|
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).
|
I do Bitcoin stuff.
|
|
|
jackjack
Legendary
Offline
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 12, 2013, 09:41:37 PM |
|
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!
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
jackjack
Legendary
Offline
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 16, 2013, 09:25:11 PM |
|
As etotheipi asked me I just pushed a new version, which doesn't need any dependency
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
picobit
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 17, 2013, 02:32:09 PM |
|
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
Legendary
Offline
Activity: 1176
Merit: 1257
May Bitcoin be touched by his Noodly Appendage
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 17, 2013, 02:50:34 PM |
|
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
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
picobit
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 17, 2013, 06:17:28 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 27, 2013, 05:52:20 PM |
|
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!
|
|
|
|
|