Invoices/Payments/Receipts proposal discussion

[riplin]

and how do you know what this function does inside?

Because we took the time to figure that out? You should try it some time.

But you did not tell me which function, nor any other specifics that I asked about.

Sigh.

https://github.com/sipa/secp256k1/blob/master/src/secp256k1.c

line 23, secp256k1_ecdsa_verify:

Code:

int secp256k1_ecdsa_verify(const unsigned char *msg, int msglen, const unsigned char *sig, int siglen, const unsigned char *pubkey, int pubkeylen) {
    int ret = -3;
    secp256k1_num_t m; 
    secp256k1_num_init(&m);
    secp256k1_ecdsa_sig_t s;
    secp256k1_ecdsa_sig_init(&s);
    secp256k1_ge_t q;
    secp256k1_num_set_bin(&m, msg, msglen);

    if (!secp256k1_ecdsa_pubkey_parse(&q, pubkey, pubkeylen)) {
        ret = -1;
        goto end;
    }
    if (!secp256k1_ecdsa_sig_parse(&s, sig, siglen)) {
        ret = -2;
        goto end;
    }
    if (!secp256k1_ecdsa_sig_verify(&s, &q, &m)) {
        ret = 0;
        goto end;
    }
    ret = 1;
end:
    secp256k1_ecdsa_sig_free(&s);
    secp256k1_num_free(&m);
    return ret;
}

E.g.: how do you know which root certificates are installed in the system? Let's say Windows...

http://technet.microsoft.com/en-us/library/cc754841.aspx

[Carlton Banks]

Ok, so the signature sent to the user is composed by the merchant, and the hash does what hashing should.

Can someone explain then why the signature is sent to the user, if the user does not verify it with the CA themselves? (given the case where using the CA system is used)

Can someone explain then why the signature must contain a hash of the Request Details? Just saying "it doesn't matter what data is hashed" suggests that any data could be used in place of the Request Details.

[piotr_n]

and how do you know what this function does inside?

Because we took the time to figure that out? You should try it some time.

But you did not tell me which function, nor any other specifics that I asked about.

Sigh.

https://github.com/sipa/secp256k1/blob/master/src/secp256k1.c

line 23, secp256k1_ecdsa_verify:

Are you fucking kidding me?
I've gone though every single line of sipa's code and I can guarantee you that it has nothing to do with any SSL certificates whatsoever.
Don't dare to blame this mess on the guy - he is one of a few left, if not the only one, who actually do a useful work for the satoshi client.

http://technet.microsoft.com/en-us/library/cc754841.aspx

Thank you!
And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.

[kjj]

Ok, so the signature sent to the user is composed by the merchant, and the hash does what hashing should.

Can someone explain then why the signature is sent to the user, if the user does not verify it with the CA themselves? (given the case where using the CA system is used)

Can someone explain then why the signature must contain a hash of the Request Details? Just saying "it doesn't matter what data is hashed" suggests that any data could be used in place of the Request Details.

The point of the signature itself is that it is now impossible to change the signed data without invalidating the signature.  Things that are important need to be included in the signed portion.  It would be pointless to sign a transaction request message that didn't include the Request Details in the signature, as the details could then be changed by anyone, at any time.

The certificate, and the CA's signature on the certificate, is to connect that certificate (and by extension, signatures made by the corresponding private key) with a real world identity.  In theory, the CA will not sign any random certificate they see, but will only sign the ones that appear to come from the entity named in the certificate.

Anyone can be a CA and sign whatever certificates we want.  But no one will trust your CA's signatures (and by extension, the certificates signed by you) unless you are a serious organization committed to only signing valid certificates.  The nominal reason why browser vendors charge thousands of dollars for including a certificate in their browser is because the browser vendor needs to audit (or hire an audit of) the alleged CA's policies and practices to ensure that certs signed by the CA will be trustworthy.

[riplin]

Are you fucking kidding me?
I've gone though every single line of sipa's code and I can guarantee you that it has nothing to do with any SSL certificates whatsoever.
Don't dare to blame this mess on the guy - he is one of a few left, if not the only one, who actually do a useful work for the satoshi client.

I was being facetious. The signature verification for an X.509 certificate is determined by the certificate itself.  It's nothing more than a basic crypto function and it doesn't need to connect to any 3rd party in order to verify if a signature is produced by the private key that a specific certificate represents.

see http://en.wikipedia.org/wiki/X.509 for details.

[riplin]

And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.

What if it does. What if you request the root certificate of CA "DERP" and it connects to that CA to fetch that certificate. What information is shared, other than that it requested that specific root certificate?

Nothing. The CA has no idea what you need that certificate for.

[Carlton Banks]

It would reflect better on the core devs if they were not defensive

And it would reflect better on you if you tried to actually figure out some of the basics first. You've shown a significant lack of understanding of even something as simple and instrumental as a hash function.

aversive, or insulting in their participation. I'm coming entirely from the perspective of asking questions, and attempting to answer them myself after the dev team member I was speaking to before hand reverted to being insulting, aversive and defensive.

You guys are all following the same pattern, and yet there is a distinct lack of any honest attempt to clarify. You keep focusing on the people asking the questions, and not answering the questions posed.

There have been multiple clarifying posts in this thread, yet you continue to ignore them.

I wouldn't be asking any questions, or attempting to provide my own answers if I either fully understood all of this, or if the devs weren't being awkward about it. I don't know whether you've noticed, but the stakes in this here Bitcoin system are worth money, being as it is that it is money. I kind of take an interest in the way the design and the infrastructure works, so unless being rightfully inquisitive isn't disrespectful or uncalled for, I will reserve the right to ask as many questions and get as many details wrong as it takes. Getting it wrong is not criminal, and it certainly doesn't disqualify anyone from asking more questions, the opposite if anything.

[piotr_n]

Are you fucking kidding me?
I've gone though every single line of sipa's code and I can guarantee you that it has nothing to do with any SSL certificates whatsoever.
Don't dare to blame this mess on the guy - he is one of a few left, if not the only one, who actually do a useful work for the satoshi client.

I was being facetious. The signature verification for an X.509 certificate is determined by the certificate itself.  It's nothing more than a basic crypto function and it doesn't need to connect to any 3rd party in order to verify if a signature is produced by the private key that a specific certificate represents.

see http://en.wikipedia.org/wiki/X.509 for details.

Right.
You know everything, except the basic function's name..
Well, thank you for sharing your valuable knowledge with me

[riplin]

Right.
You know everything, except the function's name..
Well, thank you for sharing your valuable knowledge with me

Because it's completely irrelevant. It's a set of crypto functions, depending on which signing algorithm is used.  The one thing I do know about these functions is that they are given all the required input data in order to verify if a signature is valid. and that's a hash of the data, depending on the hash algorithm used (SHA1, SHA256, whatever), the public key, and the signature. No other information is needed in order to verify a signature.


You somehow think that you've "won" the discussion simply because I can't tell you the name of the required function. This type of discussion is also referred to as "pigeon chess":

Refers to having a pointless debate with somebody utterly ignorant of the subject matter, but standing on a dogmatic position that cannot be moved with any amount of education or logic, but who always proclaims victory.

Origin:
"Debating piotr_n on the topic of the payment protocol is rather like trying to play chess with a pigeon; it knocks the pieces over, craps on the board, and flies back to its flock to claim victory."

[kjj]

I wouldn't be asking any questions, or attempting to provide my own answers if I either fully understood all of this, or if the devs weren't being awkward about it. I don't know whether you've noticed, but the stakes in this here Bitcoin system are worth money, being as it is that it is money. I kind of take an interest in the way the design and the infrastructure works, so unless being rightfully inquisitive isn't disrespectful or uncalled for, I will reserve the right to ask as many questions and get as many details wrong as it takes. Getting it wrong is not criminal, and it certainly doesn't disqualify anyone from asking more questions, the opposite if anything.

If you go ask a cardiac surgeon to explain how a multiple bypass surgery works, and every time he starts to answer you interrupt him by asking how that step helps to balance the humors, or some other pseudomedical nonsense, he's pretty likely to quickly become exasperated.  If you are the twelfth guy this week to pull that stunt, he may not be entirely polite when he tells you to come back when you have a better grasp on medicine.

I'm sorry that the devs didn't have time to spoonfeed "How the Internet Works, Volume 7: SSL" to you.  But this is the age of Google.  It is within your own capability to educate yourself enough to ask meaningful questions.

[piotr_n]

And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.

What if it does. What if you request the root certificate of CA "DERP" and it connects to that CA to fetch that certificate. What information is shared, other than that it requested that specific root certificate?

Nothing. The CA has no idea what you need that certificate for.

What it does - is not so important.
What is important is that you have no clue what it does - and that's dangerous. For privacy, I mean.
I cannot believe that I even need to explain it here

From what I see ATM nobody seems to really know what it does.
It needs to be established on IRC first, but we can be sure that results will be positive...

[riplin]

And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.

What if it does. What if you request the root certificate of CA "DERP" and it connects to that CA to fetch that certificate. What information is shared, other than that it requested that specific root certificate?

Nothing. The CA has no idea what you need that certificate for.

What it does - is not so important.
What is important is that you have no clue what it does - and that's dangerous. For privacy, I mean.

Hardly. Root CA's are used to sign hundreds, if not thousands of certificates. The CA has absolutely no clue which certificate you're trying to verify.

[riplin]

From what I see ATM nobody seems to really know what it does.

From what I see here, there are only a few that don't know what it does, you being one of them.

[Mike Hearn]

Perhaps we need a basic tutorial somewhere on how X.509 / PKIX works. I didn't go into details in the payment protocol FAQ because I thought people would research this if they didn't already know.

A lot of the frustration and talking past each other in this thread and elsewhere makes a lot more sense now it's clear that some people have a garbled understanding of how certificates and the PKI operate. This article is reasonable:

http://en.wikipedia.org/wiki/X.509

piotr_r, you can see the code that verifies payment requests here:

https://github.com/gavinandresen/paymentrequest/blob/master/c%2B%2B/paymentrequest-dump.cpp

Look for the functions that begin with X509_ or EVP_ to see which functions manage in it OpenSSL. Or look at the Java implementations for one that's not OpenSSL:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/validator/PKIXValidator.java?av=f

[piotr_n]

From what I see ATM nobody seems to really know what it does.

From what I see here, there are only a few that don't know what it does, you being one of them.

As for a guy who has just refereed me to a source code of ECDSA verify function, after I had asked him for the function name that verifies the SSL certificate, you seem to be pretty funny advertising your expertise in the matter

[riplin]

As for a guy who has just refereed me to a source code of ECDSA verify function, after I had asked him for the function name that verifies the SSL certificate, you seem to be pretty funny advertising your expertise in the matter

I already told you that I was being facetious. You asked me for a function that can verify a signature. That was one. Whether or not that's actually used in SSL is irrelevant. I know it's not, but the inputs to that function are exactly the same as the function you requested. Hash, public key, signature. output: true / false.

For what it's worth, ECDSA is one of the algorithms supported by X.509: http://tools.ietf.org/html/rfc5758

[piotr_n]

Perhaps we need a basic tutorial somewhere on how X.509 / PKIX works. I didn't go into details in the payment protocol FAQ because I thought people would research this if they didn't already know.

A lot of the frustration and talking past each other in this thread and elsewhere makes a lot more sense now it's clear that some people have a garbled understanding of how certificates and the PKI operate. This article is reasonable:

http://en.wikipedia.org/wiki/X.509

piotr_r, you can see the code that verifies payment requests here:

https://github.com/gavinandresen/paymentrequest/blob/master/c%2B%2B/paymentrequest-dump.cpp

Look for the functions that begin with X509_ or EVP_ to see which functions manage in it OpenSSL. Or look at the Java implementations for one that's not OpenSSL:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/validator/PKIXValidator.java?av=f

Thanks Mike.
I hope you don't take my comment personally and you understand that you work for Google while I work for the people.
We play for different teams, but it doesn't mean we cannot play fair.

So, let's get into X509_verify_cert

A complete description of the process is contained in the verify(1) manual page.

And this is the verify(1) manual page: http://www.manpagez.com/man/1/verify/

Do you still claim that there is no way that the bitcoin client can leave my IP a CA server, when you just use this function?
I am not saying that it does - I am just saying that it isn't totally clear what this function actually does. And I'm betting that it's also not totally clear for you.

[Carlton Banks]

Ok, so the signature sent to the user is composed by the merchant, and the hash does what hashing should.

Can someone explain then why the signature is sent to the user, if the user does not verify it with the CA themselves? (given the case where using the CA system is used)

Can someone explain then why the signature must contain a hash of the Request Details? Just saying "it doesn't matter what data is hashed" suggests that any data could be used in place of the Request Details.

The point of the signature itself is that it is now impossible to change the signed data without invalidating the signature.  Things that are important need to be included in the signed portion.  It would be pointless to sign a transaction request message that didn't include the Request Details in the signature, as the details could then be changed by anyone, at any time.

Ok, so only the holder(s) of the merchant's privkey can verify that the signature is a hash of the Payment Request. The merchant's certificate cannot be used to do this. Is this right?

If so, I still fail to understand the necessity of hashing the Request Details and signing that. The end user cannot verify that the hash is a result of such a hashing operation, and they are the only recipient of this signature. Only the merchant should be able to ascertain that the signature is generated by signing a hash of the Request, and they have no apparent need to verify this, being as they presume to have collected the details in a direct https session with the user.

Why use the Payment Details, which the merchant should be confident of anyway?

[riplin]

Do you still claim that there is no way that the bitcoin client can leave my IP a CA server, when you just use this function?
I am not saying that it does - I am just saying that it isn't totally clear what this function actually does. And I betting that it's also not totally clear for you.

Code:

-CApath directory
           A directory of trusted certificates. The certificates should have
           names of the form: hash.0 or have symbolic links to them of this
           form ("hash" is the hashed certificate subject name: see the -hash
           option of the x509 utility). Under Unix the c_rehash script will
           automatically create symbolic links to a directory of certificates.

       -CAfile file
           A file of trusted certificates. The file should contain multiple
           certificates in PEM format concatenated together.

So you need to supply your own trusted root certificates.

[Mike Hearn]

Look, it's late and I'm tired. If you want to learn OpenSSL then go read the documentation instead of demanding personalised tutorials whilst simultaneously talking crap about my coworkers. Your attitude reveals you to be both obnoxious and incompetent.

For example, you could start here:

http://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_flags.html

and in particular this statement:

If CRLs checking is enable CRLs are expected to be available in the corresponding X509_STORE structure. No attempt is made to download CRLs from the CRL distribution points extension.

Seriously Piotr, this stuff isn't rocket science. If you aren't capable of understanding it yet then go and read documentation until you do, then come back.