|
I changed the Readme, is it enough?
|
|
|
|
|
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)
|
|
|
|
Scrypt is adjustable in difficulty. In litecoin it's only scrypt(1024,1,1) which is really low and very fast to calculate. Most CPUs can at least do 20,000 scrypt calculations per second, and many new processors can do much better.
That's where my problem is: I'm at 2 scrypt calculations per second Thanks |
|
|
|
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 |
|
|
|
|
Can someone with an account on a litecoin forum post that question there?
Thanks
|
|
|
|
I don't find that as complicated as in bitcoin-qt Your specific problem is only between lines 361->412. I even left the print's so you can uncomment them to see the values Just delete everything after line 530 and put this verifySignature('mqMmY5Uc6AgWoemdbRsvkpTes5hF6p5d8w','H+HUh1GiTw22BMhqRwbSET/4aYCFIuivSgTyU/A+qH7xZp5gz61zp//WMFTbpNDbiMYoYz7pD88NYg/0DekcMpY=','test')
|
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
I'm finishing the code, it's coming in the following hours Here's what I get for your test: fb: 1b
recid: 0
r: e1d48751a24f0db604c86a4706d2113ff869808522e8af4a04f253f03ea87ef1
s: 669e60cfad73a7ffd63054dba4d0db88c628633ee90fcf0d620ff40de91c3296
Rx: e1d48751a24f0db604c86a4706d2113ff869808522e8af4a04f253f03ea87ef1
Ry: 8f875bbc497b680cfe288eeda4bfb1da78af6703afdfaaf580e9e656ad62531c As for Q: Q = inv_r * ( R*s + G*minus_e ) |
|
|
|
In the mean time, could you post the message and address that give this signature? It seems odd because Rx = r + {0;1}*q and this doesn't correspond to your example at all (first bits should be the same as q=0xffffffffffffffff...) For exemple, signing 'bitcoin' with private key '\x01'*32 gives Flag: 1c -> uncompressed key and Rx=r+0*q
r: b6392b8e0250550a0a068e8ba68891d555a34eb48fe6266ae042b3c689265586
s: b220ecbbe88b379812fbc920afcb15a4bd17a73f7555a5fea92b3b4c6a187523 So Rx=b6392b8e0250550a0a068e8ba68891d555a34eb48fe6266ae042b3c689265586 It's from the top of my head, I'll post the code when I have access to my dev computer |
|
|
|
|
I'm about to release a code for signing in Armory
If I understood correctly, it should solve your problem
|
|
|
|
|
Knowing that calculating a block hash takes ~0.5s, a new node would validate the entire blockchain in more than 48 hours...
I'm sure it's not the case, so how does the client can validate those blocks?
|
|
|
|
Is it possible / trivial to compute the public key (or the bitcoin address) from the private key? I haven't studied asymmetric cryptography, but as far as I understand it, the public key is a function of the two secret prime numbers: I would thus guess that the answer to my question is yes.
Oui. Et non, la clé publique ne dépend que de la clé privée et du générateur (public, identique pour tout le monde) If that is the case, how should I do it, practically?
La clé publique est un point de coordonnées (x,y) sur la courbe elliptique utilisée par Bitcoin. Donc y² = x³ + 7. Sur la courbe on définit les opérations addition (point + point) et multiplication (point * nombre), et un point spécial qu'on appelle générateur (choisi "au hasard") La clé publique est le générateur * clé privée Concretely, I want to store my bitcoin wallet information on one QR code. I could very well store both the public/private keys (using the URI format for inst.) but I would prefer storing only the private key in order to reduce the complexity of the QR, if that is possible.
Comme tu le vois, oui c'est possible |
|
|
|
Ok then! I think/hope that will anyway be useful in the future For now I have that: v0 {
'message': 'jjj',
'signature': 'G52Qg26N+v9BE7WlaG+MQUYF+35Or0UF6cWUp9bRVM46LFT8AP+spHCVLds9gpCh+IGcKLOCLYdLWKgFqvP82PY=', // =base64(signature)
'address': '1BCwRkTsYzK5aNK4sdF7Bpti3PhrkPtLc4'
}-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
ldld
-----BEGIN PGP SIGNATURE-----
iHkEABMIACEFAlGOIpYCGwMGCwkIBwMCBhUIAgkKCwMWAgECHgECF4AACgkQQAqjLBlarMRT3wEA1IED (OpenPGP packets)
GsDYPz4OTY0bn35RTz6RkyCh59i47DBnjih4S5IA/R3qcXG/V9Mx8uHzjaU1uM6CrS1II1aij+JqU6vR
2Gtp
=D1/a
-----END PGP SIGNATURE----- -----BEGIN SIGNATURE-----
kA0DAAgTU4HmRG72SLABywpiAFGOJKpsZGxkiHkEABMIACEFAlGOJKoCGwMGCwkIBwMCBhUIAgkKCwMW (OpenPGP packets)
AgECHgECF4AACgkQU4HmRG72SLBCWAD8Db4nEv/poywtioVXy3nRCIwVkVJc8kULlRVpEeW4Os8BAJ2B
8qnmdGqEmyYbl3ZDV+Osp7440Cdl8WgSv3EHvAMf
=5wDl
-----END SIGNATURE----- So instead of my clear sig, you'd want that, right? -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
ldld
-----BEGIN PGP SIGNATURE-----
G52Qg26N+v9BE7WlaG+MQUYF+35Or0UF6cWUp9bRVM46LFT8AP+spHCVLds9gpCh+IGcKLOCLYdLWKgFqvP82PY= (same data than v0: 1+64 bytes, may be different if contains \n)
=crc24
-----END PGP SIGNATURE-----
But what about the base64 one? Just this? -----BEGIN PGP SIGNATURE-----
G52Qg26N+v9BE7WlaG+MQUYF+35Or0UF6cWUp9bRVM46LFT8AP+spHCVLds9gpCh+IGcKLOCLYdLWKgFqvP82PY= (same data than v0: 1+64 bytes)
=crc24
-----END PGP SIGNATURE-----
|
|
|
|
|
Be off for 2 days
Miss 3 new alt-currencies
Wtf is wrong with you guys?
|
|
|
|
Oh ok I misunderstood, I thought you wanted that for Python. I might look at that once the current problem is solved. That problem is this one: I thought I was making mistakes in my implementation but looking at some codes I realized that there is currently not a single implementation of OpenPGP that accepts secp256k1. I tried to add it in gnupg-ecc, but no luck yet... So... I have done what you asked for (message signing with secp256k1 keys that follows RFC2440) but nobody can read those signatures yet. This leads to two questions - 1. Is it enough to claim (a part of) the bounty? I'm not being greedy, it's just that I have other projects and I see that continuing this one (ie implementing OpenPGP verifying) will require some additional hours of work. In all cases, I'll finish and implement that verifying but the ETA's would be different.
- 2. Say that I'm going to implement that now (bounty or not, it's more about the 'global' 'future' of secp256k1 signing with RFC2440). There's still a problem:
- GPG needs to have the public key stored in your keyring to verify. AND that keyring doesn't accept secp256k1 keys.
- GPG doesn't accept to verify signatures if the public key and the signature are in the same block. (Not a word about such behavior in RFCs though.)
So, well... What should I do?
- Create two blocks (key export + signature) ? (OK with GPG behavior BUT (1) two blocks to process: importing, then verifying, and (2) GPG doesn't support secp256k1 key import yet)
- Stick to RFCs, break compatibility with GPG and create big signatures that contain the pubkey? (simpler to verify: only one block BUT will never work with GPG)
Anyway, I'll publish my signing code soon. This week hopefully. With both possibilities for problem 2. PS: All this post is about Version 1 / OpenPGP signatures, not Version 0, which is done |
|
|
|
|
Show Posts
