Just when I thought that things were getting better since I discovered what was the problem last week, it didn’t. I thought the problem could easily be solved using OpenSSL libraries, as I had used their command line tool as part of the test last week. I looked into the source code of their command line tool, to know what functions are needed to solve my problem. But even after following what OpenSSL did, I was still getting the same issue.
I took the private key that was generated by the server application and put it into a file. Then I used the same OpenSSL command line tool as I did last week in attempt to get an uncompressed EC key, this time with that particular private key as the input. The output result surprised me. It still remains unchanged even after explicitly passing the uncompressed option to the command line tool. For the key that I used for last week’s test, that was exported from XCA, there was a clear difference in output between a compressed format and an uncompressed format. After that, I looked at the man pages to see what other options that could be supplied or if I am missing something.
There’s an option called no_public where if it is specified, the public key will not be outputted, which is strange as the command line outputs an EC private key only if given a valid EC private key, so that made the option quite redundant. I still tried it out on the key anyway and as expected no change in the results. But using that option with XCA’s key made its output smaller instead! So then I wrote a small bash script, where it outputs a compressed and uncompressed EC key, but with the no_public option specified for both commands. Giving XCA’s key as input, the result of the output was that it is smaller and it is the same for both compressed and uncompressed commands. I then checked the output for both commands without the no_public option as well, and compared.
From this, I figured out that the compression was not being done on the private key itself, but its actually being done on the public key. But how is this possible if only a private key is given? The syntax for an EC private key is defined in RFC5915 , where optionally the corresponding public key could be part of the encoding. Why would they want to do this? It’s probably because any application that receives an EC private key in this encoding does not have to compute the corresponding public key themselves, when they can get it from the encoding. The Botan library, which the server application uses, generates EC private keys without having the corresponding public key in its encoding, whereas OpenSSL, in which XCA uses internally, does include the public key by default.
So maybe if OpenSSL generates the ECDSA private key instead, the problem would be solved right? I hardcoded the uncompressed version of the XCA key into the application to test it out first. Unfortunately, even with using XCA’s private key to generate the certificate in the server application, the problem still persists. Looking at the source code of the current version of Botan that we are using, it seems that no matter what valid EC private key is given, the library still generates a compressed public key for an x509 certificate. At that point, I know its just time to move on and probably use RSA private keys temporarily instead. I have already spent too much unnecessary time trying to get ECDSA certificates to work in Windows and in macOS.
The reason why Dr Shawn wanted to use ECDSA private keys is mainly because of how it offers cryptographic strength at a smaller storage size in comparison with RSA keys, that are so huge in length. However, the product comes first so we should have something that works for now. I’ll finally spend the rest of the month setting up the store, doing more testing and some cleanup, etc.
0 Comments