Re: [FWD] Build incorrect crypt/decrypt in Win32. x86. MSVC 2003. MinGW.
Can someone comment on why this fails on windows? I too observed that the
decryption does not result in the original plain text on windows.
-Sandeep
On Sun, Oct 18, 2009 at 5:58 AM, Lutz Jaenicke wrote:
> Forwarded to openssl-users for public discussion.
>
> Best regards,
>Lutz
>
> - Forwarded message from User User -
>
> From: User User
> To: r...@openssl.org
> Subject: Build incorrect crypt/decrypt in Win32. x86. MSVC 2003. MinGW.
> Date: Sun, 18 Oct 2009 07:46:40 +0400
> Reply-To: User User
>
> Hello openssl Hackers.
> I am beginner in openssl. Learn for wrote simple crypto_test.cpp program.
> Test it under CentOS, FreeBSD and Win32.
> Linux,BSD work fine, but windows builds uncorrect.
> Build in MS VC .Net 2003 and MingGW, both not work in crypt/decrypt cycles
> correctly.
> Send code in attach, and openssl makefile and simple description in
> README.TXT
> I can't understand. is it a bug or my build problems.
> Please, show right way.
> Thank you.
> Nick.
>
> RESULTS:
>
> --[ FreeBSD ]--
> ./crypto_test -e plaintext encypt.bsd 123
> ./crypto_test -d encypt.bsd plaintext.out.bsd 123
> ./openssl dgst -rmd160 plaintext encypt.bsd plaintext.out.bsd
>
> RIPEMD160(plaintext)=
> d7ca608f0430c3248527572662af5e50d93e87ca
> RIPEMD160(encypt.bsd) =9a465d7a2304833f0d7a967ce5a04687b7350441
> RIPEMD160(plaintext.out.bsd)=
> d7ca608f0430c3248527572662af5e50d93e87ca
>
> --[ WIN32 ]--
> crypto_test.exe -e plaintext encrypt.w32 123
> crypto_test.exe -d encrypt.w32 plaintext.out.w32 123
> openssl.exe dgst -rmd160 plaintext encrypt.w32 plaintext.out.w32
>
> RIPEMD160(plaintext)=
> d7ca608f0430c3248527572662af5e50d93e87ca
> RIPEMD160(encrypt.w32) =e1ae968afaa4fa259a4f81012804769fe2d13dd6
> RIPEMD160(plaintext.out.w32)=
> 753e049eb8c31e2116e575402db6f7dd7abdbfa1
>
>
> ] Code of crypto_test.cpp
> #include
> #include
>
> #include
> #include
> #include
>
> #define BUF_SIZE32767
>
> int enc(char* fin, char* fout, unsigned char* key);
> int dec(char* fin, char* fout, unsigned char* key);
>
> int main(int argc, char* argv[])
> {
>ERR_load_crypto_strings();
>if(argc<5){
>printf("Need more args:\n\t1 - -e/-d\n\t2 - file_in\n\t3 -
> file_out\n\t4 - pass\n\t");
>exit(0);
>}
>
>int ret =0;
>if(!strcmp(argv[1], "-e")){
>ret = enc(argv[2], argv[3], (unsigned char*)argv[4]);
>}else if(!strcmp(argv[1], "-d")){
>ret = dec(argv[2], argv[3], (unsigned char*)argv[4]);
>}else{
>printf("Unknown direction: %s\n",argv[1]);
>exit(0);
>}
>
>if(!ret)
>printf("Completed\n");
>else
>printf("Error:%d",ret);
>
>ERR_free_strings();
>
>return ret;
> }
>
> int enc(char* fin, char* fout, unsigned char* key){
>int ret = 0;
>
>printf("Mode ENCRYPT\n");
>
>BIO *bin = BIO_new_file(fin, "r");
>
>if(!bin){
>ret = ERR_get_error();
>printf("Decryption failed,
> reason:%s\n",ERR_reason_error_string(ret));
>return ret;
>}
>
>BIO *bout = BIO_new_file(fout, "w");
>
>if(!bout)
>return ERR_get_error();
>
>BIO* cipher = BIO_new(BIO_f_cipher());
>
>BIO_set_cipher(cipher, EVP_bf_ecb(), key, 0, 1);
>BIO_push(cipher, bout);
>
>void* buff = malloc(BUF_SIZE+1);
>int rlen = 0, written =0;
>
>do{
>memset(buff, 0, BUF_SIZE+1);
>if(!(rlen=BIO_read(bin, buff, sizeof(buff))) ){
>break;
>}
>
>if( (written = BIO_write(cipher, buff,
> (int)strlen((char*)buff)) ) <=0 ){
>ret = ERR_get_error();
>printf("Encryption failed,
> reason:%s\n",ERR_reason_error_string(ret));
>break;
>}
>
>}while(1);
>
>free(buff);
>BIO_flush(cipher);
>BIO_free_all(cipher);
>
>return ret;
> }
>
> int dec(char* fin, char* fout, unsigned char* key){
>int ret = 0;
>
>printf("Mode DECRYPT\n");
>BIO *bin = BIO_new_file(fin, "r");
>
>if(!bin)
>return ERR_get_error();
>
>BIO *bout = BIO_new_file(fout, "w");
>
>if(!bout)
>return ERR_get_error();
>
>BIO* cipher = BIO_new(BIO_f_cipher());
>
>BIO_set_cipher(cipher, EVP_bf_ecb(), key, 0, 0);
>BIO_push(cipher, bin);
>
>void* buff = malloc(BUF_SIZE+1);
>int rlen = 0, written =0;
>
>do{
>memset(buff, 0, BUF_SIZE+1);
>
>if(!(rlen=BIO_read(cipher, buff, sizeof(buff))) ){
>break;
>}
>
>if(!BIO_get_cipher_status(cipher)){
>
Re: Debugging OpenSSL with Visual Studio
Thanks Dave. I figured out how to do this. I first built a static version of libeay32 and ssleay32 using ms\nt.mak (added /Zi and removed /Wx in CFLAGS). I then created an empty VS2005 project and added apps\req.c apps\apps.c apps\app_rand.c to the project (I had to look into req utility, similar would be the procedure for other tools). I then linked libeay and ssleay to the project. Now everything built fine. But as you said, I am able to break/stepinto/display but cannot do a go-to-defn of any OpenSSL API from my project. When I say go-to-def, it always points to the prototype declaration in a .h file. Thanks, Sandeep On Tue, Oct 20, 2009 at 6:21 PM, Dave Thompson < dave.thomp...@princetonpayments.com> wrote: > > From: owner-openssl-us...@openssl.org On Behalf Of sandeep kiran p > > Sent: Saturday, 17 October, 2009 02:12 > > > Can someone point me to the instructions that are needed to build > > and debug OpenSSL using Visual Studio on windows? I want to navigate > > through the code for the 'openssl req' command using VS. I've built a > > debug version (both static and dynamic) of OpenSSL as per the instruction > > in INSTALL.W32 doc. I have found an earlier post on a similar topic > > http://www.mail-archive.com/openssl-users@openssl.org/msg56791.html . > > But it just describes building a debug variant. > > > The question here is, do I need to create a new VS project > comprising > > of apps/openssl.c and link libeay32.lib and ssleay32.lib libraries that > > I have built earlier? When I did this, I see a lot of unresolved external > > symbols (_prime_main, _ocsp_main etc) when building the solution. Is > there > > any documented procedure for accomplishing what I intend to? > > I don't know about documented. > > If you want to compile the apps/* code in VS, I think you need to > do the whole directory; openssl.c is just a dispatcher that calls > the other 'commands'. If you're using dynamic, I think you need > (a copy of?) ms\applink.c also. But remember the 'apps' mostly just > wrap the -lcrypto and/or -lssl routines, so if you need to look at > much of what is going on, you'll probably need to debug them too. > Unless you only want to look at API-level results. > > The last time I did this, 0.9.8g on VC++6.0 (yes, a while ago), > I did commandline (nmake) build of everything including apps, > except I manually added /Zi /Yd to cflags in nt*.mak (they used to > be in util/pl/VC-32.pl but seem to have gotten lost somewhere); > then I created a VS console-exe project with nothing in it, but > in ProjectSettings Debug specified my executable (from the dir > which also contains the .pdb, and the .dll and .pdb if not static). > I could break/step/display fine, but go-to-defn etc. didn't work. > > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Re: Generating sect163k1 key pairs
Hi Doug,
You'll have to forgive my ignorance. I'm not sure why I'm having
difficulties answering you. I'll try to walk you through what I
observe.
I'm a Windows guy, so don't hold it against me that I use 'type'
instead of 'cat'. I'm also going to use F(p) rather than F(2^m) since
I believe its easier to follow. Just replace the p with m and f(x).
First, generate the domain parameters:
openssl ecparam -genkey -name secp160k1 -out c:\key.pem
type c:\key.pem
-BEGIN EC PARAMETERS-
BgUrgQQACQ==
-END EC PARAMETERS-
-BEGIN EC PRIVATE KEY-
MFACAQEEFDP8wkW6hxlp8ShA8pHL8LadtNyBoAcGBSuBBAAJoSwDKgAECUThY/ff
d9qioT+AddUV8f76s8ZufLPbZmNYWD3OUK8Ada0Jt6xBiQ==
-END EC PRIVATE KEY-
Next, strip the PBE:
openssl ec -in c:\key.pem -out c:\naked.pem
type naked.pem
-BEGIN EC PRIVATE KEY-
MFACAQEEFDP8wkW6hxlp8ShA8pHL8LadtNyBoAcGBSuBBAAJoSwDKgAECUThY/ff
d9qioT+AddUV8f76s8ZufLPbZmNYWD3OUK8Ada0Jt6xBiQ==
-END EC PRIVATE KEY-
Strip the Base 64 encoding:
openssl base64 -d -in naked.pem -out c:\key.asn1
Next, use Guttmans asn.1 dumper ('openssl asn1parse -in c:\key.asn1'
results in an error):
dumpasn1 c:\key.asn1
0 80: SEQUENCE {
21: INTEGER 1
5 20: OCTET STRING
: 33 FC C2 45 BA 87 19 69 F1 28 40 F2 91 CB F0 B6
: 9D B4 DC 81
277: [0] {
295: OBJECT IDENTIFIER secp160k1 (1 3 132 0 9)
: }
36 44: [1] {
38 42: BIT STRING
:04 09 44 E1 63 F7 DF 77 DA A2 A1 3F 80 75 D5 15
:F1 FE FA B3 C6 6E 7C B3 DB 66 63 58 58 3D CE 50
:AF 00 75 AD 09 B7 AC 41 89
: }
: }
At this point, the public key is the bit string 04 09 44 E1 ... B7 AC
41 89. It's an ECPoint type (cf: SEC-1 and RFC 5480, Setion 2.2 -
Subject Public Key).
To examine the point encoding, we need to use SEC-1
(http://www.secg.org/download/aid-780/sec1-v2.pdf). Section 2.3.3
covers Elliptic Curve Point to Octet String Conversion, and Section
2.3.4 cover Octet String to Elliptic Curve Point Conversion. Since it
appears the question is related to how is Q encoded, section 2.3.3
applies.
Note that your original example used sect163k1, so you would probably
be interested in Sections 2.3.5 and 2.3.6 which covers encoding and
decoding of Field Elements. Again, I used F(p) rather than F(2^m)
because its easier to visualize for these exercises.
If point compression is being used, the BIT STRING M =Y || X. If point
compression is not being used, then the BIT STRING M = 04 || Y || X.
Since the first octet of the bit string is 0x04, we know that point
compression is *not* being used.
I don't know how to get OpenSSL to give up the remainder of the
secrets, but I do know how to do it in Crypto++ (can anyone help me
out here?). Here's what I got from my Crypto++ program:
C:\Users\Public\Programs\Crypto++\ECParams>ecparams key.asn1
Modulus:
1461501637330902918203684832716283019651637554291
Coefficient A:
0
Coefficient B:
7
Base Point:
X: 338530205676502674729549372677647997389429898939
Y: 842365456698940303598009444920994870805149798382
Subgroup Order:
1461501637330902918203686915170869725397159163571
Cofactor:
1.
Private Exponent:
296795240612937494545889023267033046717591510145
Public Element:
X: 52917001892683237407267355347783044226963125190
Y: 630769944952357370507177294689782720716591612297
C:\Users\Public\Programs\Crypto++\ECParams>
Jeff
On Wed, Oct 21, 2009 at 11:50 AM, Doug Bailey wrote:
> - "Jeffrey Walton" wrote:
>
>> Hi Doug,
>>
>> > I am trying to figure out where the padding bits
>> > are applied?
>> > ...
>> > The two private keys are described in a different
>> > number of bytes. Since the 2nd generated private
>> > key is shown in 20 bytes i.e. 160 bits, is it assumed
>> > that the MS 3 bits are 0?
>>
>> The public key, also known as the public element, is a point Q(x, y)
>> on the curve of order R. R is the order of the subgroup generator G,
>> where G is a point called the Base Point. The private key, also known
>> as the private exponent, x, is an integer such that Q = xG. Q = xG is
>> similar to RSA's e*d mod n === 1. It's the trap door function - easy
>> to compute one way, hard to compute the other way.
>>
>> All this means is that x, Q_x, and Q_y don't have to be 163 bits.
>> We'd
>> expect them to be slightly less (since this is a finite field), but
>> not too much less since there is a relationship between R, the points
>> on the curve (U), and the cofactor (S). The relationship is U = R *
>> S,
>> and the cofactor (S) is kept small so that subgroup order (R) is
>> large.
>
> So I can understand why the byte descriptions of the keys differ in length.
>
> In your response you indicate that the public key description consists of
> two 163 bit numbers representing a point on the curve (Q_x, Q_y).
>
> Given a display like:
> pub:
> 04:01:9c:db:21:d7:49:17:cd:c4:93:56:13:e4:07:
> c2:af:1b:43:70:a3:b9:03:f1:26:f8:7b:1d:02:69:
> 21:39:cf:d5:28:ee:3b:44:3c:c5:64:7c:aa
>
> How can you tell where the delineation between Q_x and
RE: your mail
I'm using v1.0.0 Beta 3.
My code is perl xs glue but it looks something like this:
purpose= X509_PURPOSE_MIN - 1;
cert_store = X509_STORE_new();
revokes= crl_stack;
X509_STORE_set_flags(cert_store, 0);
vpm= X509_VERIFY_PARAM_new();
X509_VERIFY_PARAM_set_flags(vpm,X509_V_FLAG_X509_STRICT);
if ( revokes ) {
// .
// . perl xs stuff here
// .
if ( num_crls >= 0) {
#if (OPENSSL_VERSION_NUMBER >= 0x1003L)
X509_VERIFY_PARAM_set_flags(vpm,X509_V_FLAG_EXTENDED_CRL_SUPPORT);
#endif
// if you pass in one crl it is assumed to be the crl to check
// for the cert being verified only
X509_VERIFY_PARAM_set_flags(vpm,X509_V_FLAG_CRL_CHECK);
if ( num_crls >= 1 ) {
// if you pass in > 1 crl then it is assumed you have
// passed in one crl for every ca in the chain
// (2do: use an explicit argument for this now that we will
// have one iCRL for all)
X509_VERIFY_PARAM_set_flags(vpm,X509_V_FLAG_CRL_CHECK_ALL);
}
}
}
if (purpose > X509_PURPOSE_MIN) {
X509_VERIFY_PARAM_set_purpose(vpm, purpose);
}
X509_STORE_set1_param(cert_store, vpm);
trusted = sk_X509_new_null();
sk_X509_push(trusted,root);
//
// The UNTRUSTED STACK (as CAs come in...)
//
untrusted = sk_X509_new_null();
for (ca_idx = 0 ; ca_idx <= num_cas; ca_idx++) {
// .
// . perl xs stuff
// .
sk_X509_push(untrusted,(X509 *)ca_cert);
}
//
// The CRL STACK
//
for (crl_idx = 0 ; crl_idx <= num_crls; crl_idx++) {
// .
// . perl xs stuff
// .
sk_X509_CRL_push(crls,(X509_CRL *)crl);
}
// The certificate store verification context and actual verification
cs_ctx = X509_STORE_CTX_new();
if (!cs_ctx) {
error="malloc error";
goto CERTIFICATE_VERIFY_FAILURE;
}
if(! X509_STORE_CTX_init(cs_ctx,cert_store,cert,untrusted)) {
error="error initializing cs_ctx";
goto CERTIFICATE_VERIFY_FAILURE;
}
X509_STORE_CTX_trusted_stack(cs_ctx, trusted);
if (purpose) X509_STORE_CTX_set_purpose(cs_ctx, purpose);
if (crls) X509_STORE_CTX_set0_crls(cs_ctx,crls);
verifyResult = X509_verify_cert(cs_ctx);
ROOT (CA0)
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Red Condor, OU=PKI, CN=CA0
Validity
Not Before: Oct 11 19:36:01 2009 GMT
Not After : Oct 21 19:36:01 2010 GMT
Subject: O=Red Condor, OU=PKI, CN=CA0
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:8
X509v3 Subject Key Identifier:
A0:A0:7A:71:6C:23:26:E4:00:9A:EA:17:B9:B4:A8:7F:1D:0C:65:DE
X509v3 Authority Key Identifier:
keyid:A0:A0:7A:71:6C:23:26:E4:00:9A:EA:17:B9:B4:A8:7F:1D:0C:65:DE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
-BEGIN CERTIFICATE-
MIIBuTCCAWOgAwIBAgIBATANBgkqhkiG9w0BAQUFADAxMRMwEQYDVQQKEwpSZWQg
Q29uZG9yMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAMTA0NBMDAeFw0wOTEwMTExOTM2
MDFaFw0xMDEwMjExOTM2MDFaMDExEzARBgNVBAoTClJlZCBDb25kb3IxDDAKBgNV
BAsTA1BLSTEMMAoGA1UEAxMDQ0EwMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAPxS
gTKr9MTRGhh8OYyNfEB0kuSpPJJOH+U9BncIQO3Ff+DMtaM2DyBlUn7TY9Xb2+5i
Yz7go/XN9QRvnhO4mp8CAwEAAaNmMGQwEgYDVR0TAQH/BAgwBgEB/wIBCDAdBgNV
HQ4EFgQUoKB6cWwjJuQAmuoXubSofx0MZd4wHwYDVR0jBBgwFoAUoKB6cWwjJuQA
muoXubSofx0MZd4wDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA0EAH3bu
6vB/XW7IBYpwqUs1sihHrTsvibg5660Ry2pD2+QUDRVvOZofOoY0T3iWETItnjM2
KcZrYtj1cYXrW9T5Dw==
-END CERTIFICATE-
Indirect CRL Signer (CA0iCRL) <<
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Red Condor, OU=PKI, CN=CA0
Validity
Not Before: Oct 11 19:37:10 2009 GMT
Not After : Oct 21 19:37:10 2010 GMT
Subject: O=Red Condor, OU=PKI, CN=CA0iCRL
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:8
X509v3 Subject Key Identifier:
0E:8C:C9:D3:F4:2C:B8:6D:81:71:69:B4:2E:99:FA:08:AD:CF:A9:8F
X509v3 Authority Key Identifier:
keyid:E1:C1:46:BC:E5:6F:03:27:7A:23:C4:0B:A2:BF:F9:0F:03:BC:F8:83
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
-BEGIN CERTIFICATE-
MIIBvTCCAWegAwIBAgIBAjANBgkqhkiG9w0BAQUFADAxMRMwEQYDVQQKEwpSZWQg
Q29uZG9yMQwwCgYDVQQLEwNQS0kxDDAKBgNVBAMTA0NBMDAeFw0wOTEwMTExOTM3
MTBaFw0xMDEwMjExOTM3MTBaMDUxEzARBgNVBAoTClJlZCBDb25kb3IxDDAKBgNV
BAsTA1BLSTEQMA4GA1UEAxMHQ0EwaUNSTDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgC
QQCWgKj+xxLStKZW1ydA9w4RZee56acEqpZHRXsuwLXXUOlzI3XWPlOzcbYnGW72
leoOQ36Qi9lBOow0yct/p4X5AgMBAAGjZjBkMBIGA1UdEwEB/wQIMAYBAf8CAQgw
HQYDVR0OBBYEFA6MydP0LLhtgXFptC6Z+gitz6mPMB8GA1UdIwQYMBaAFOHBRrzl
bwMneiPEC6K/+Q8DvPiDMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAANB
AMhSoa8Ut9/eRQiJnOsPajUcgHQiimm41u3kC9zL6SjCcVlrbfyzZiSfX2g+XFma
N6xmAhQjUEXCAOSz2WmoWuM=
-END CERTIFICATE-
End Entity (AdamRosenstein) <<
Re: your mail
On Wed, Oct 21, 2009, Adam Rosenstein wrote:
> Hi, I'm trying to use indirect CRLs in my application. I cannot figure out
> how to get the CRL signer's cert to be verified though. I keep getting "CRL
> path validation error"
>
> I do something like this:
>
> cs_ctx = X509_STORE_CTX_new();
> if (!cs_ctx) {
> error="malloc error";
> goto CERTIFICATE_VERIFY_FAILURE;
> }
> if(! X509_STORE_CTX_init(cs_ctx,cert_store,cert,untrusted)) {
> error="error initializing cs_ctx";
> goto CERTIFICATE_VERIFY_FAILURE;
> }
> X509_STORE_CTX_trusted_stack(cs_ctx, trusted);
>
> if (purpose) X509_STORE_CTX_set_purpose(cs_ctx, purpose);
> if (crls)X509_STORE_CTX_set0_crls(cs_ctx,crls);
>
> verifyResult = X509_verify_cert(cs_ctx);
>
> Where 'untrusted' is a stack of potential intermediate CA's, 'trusted' is a
> stack of trusted root CA's, crls is a stack of crls, and cert_store was setup
> previously.
>
> I have tried chains like this:
>
> RootCert-+->IndCRLSigner(crldp=http://x.y.z,issrname=IndCRLSigner)->crl
> |
> +->EndEntityCert(crldp=http://x.y.z,issrname=IndCRLSigner)
>
> Crl idp == http://x.y.z
[no subject]
Hi, I'm trying to use indirect CRLs in my application. I cannot figure out how
to get the CRL signer's cert to be verified though. I keep getting "CRL path
validation error"
I do something like this:
cs_ctx = X509_STORE_CTX_new();
if (!cs_ctx) {
error="malloc error";
goto CERTIFICATE_VERIFY_FAILURE;
}
if(! X509_STORE_CTX_init(cs_ctx,cert_store,cert,untrusted)) {
error="error initializing cs_ctx";
goto CERTIFICATE_VERIFY_FAILURE;
}
X509_STORE_CTX_trusted_stack(cs_ctx, trusted);
if (purpose) X509_STORE_CTX_set_purpose(cs_ctx, purpose);
if (crls)X509_STORE_CTX_set0_crls(cs_ctx,crls);
verifyResult = X509_verify_cert(cs_ctx);
Where 'untrusted' is a stack of potential intermediate CA's, 'trusted' is a
stack of trusted root CA's, crls is a stack of crls, and cert_store was setup
previously.
I have tried chains like this:
RootCert-+->IndCRLSigner(crldp=http://x.y.z,issrname=IndCRLSigner)->crl
|
+->EndEntityCert(crldp=http://x.y.z,issrname=IndCRLSigner)
Crl idp == http://x.y.z
Re: Generating sect163k1 key pairs
- "Jeffrey Walton" wrote: > Hi Doug, > > > I am trying to figure out where the padding bits > > are applied? > > ... > > The two private keys are described in a different > > number of bytes. Since the 2nd generated private > > key is shown in 20 bytes i.e. 160 bits, is it assumed > > that the MS 3 bits are 0? > > The public key, also known as the public element, is a point Q(x, y) > on the curve of order R. R is the order of the subgroup generator G, > where G is a point called the Base Point. The private key, also known > as the private exponent, x, is an integer such that Q = xG. Q = xG is > similar to RSA's e*d mod n === 1. It's the trap door function - easy > to compute one way, hard to compute the other way. > > All this means is that x, Q_x, and Q_y don't have to be 163 bits. > We'd > expect them to be slightly less (since this is a finite field), but > not too much less since there is a relationship between R, the points > on the curve (U), and the cofactor (S). The relationship is U = R * > S, > and the cofactor (S) is kept small so that subgroup order (R) is > large. So I can understand why the byte descriptions of the keys differ in length. In your response you indicate that the public key description consists of two 163 bit numbers representing a point on the curve (Q_x, Q_y). Given a display like: pub: 04:01:9c:db:21:d7:49:17:cd:c4:93:56:13:e4:07: c2:af:1b:43:70:a3:b9:03:f1:26:f8:7b:1d:02:69: 21:39:cf:d5:28:ee:3b:44:3c:c5:64:7c:aa How can you tell where the delineation between Q_x and Q_y is? Is Q_y always described in 163 bits and Q_x is appended to that? Is there ever any padding inserted onto the numbers output by the -text option?What is the magic decoder ring to the display provided by the -text option? > > A fellow named Marcel Martin wrote a really nice Curve and Parameter > generator. According to Marcel, the program correctly counts points > on > the curve (which can be tricky business). For Marcel's Elliptic Curve > Builder (ECB), see http://www.ellipsa.eu/. For a small Curve and > Domain Parameter writeup, see > http://www.cryptopp.com/wiki/Elliptic_Curve_Builder. > > Jeff > > On Tue, Oct 20, 2009 at 3:36 PM, Doug Bailey > wrote: > > I have been trying to generate keys for a ECDSA system that uses a > sect163k1 key > > pair. > > > > In generating some of the key sets, I notice that the printed length > of the keys > > differ when using the -text command option. Since openssl is > displaying a 163 > > bits in a byte-wise display, I am trying to figure out where the > padding bits are > > applied? > > > > For example: > > > > ~$ sudo openssl ecparam -genkey -name sect163k1 -out testkey1.pem > > ~$ sudo openssl ec -text -in testkey1.pem > > read EC key > > Private-Key: (163 bit) > > priv: > > 00:c4:5c:43:a9:17:57:89:ff:e8:fe:f9:d6:b0:d4: > > 52:fc:d4:6b:71:98 > > pub: > > 04:01:9c:db:21:d7:49:17:cd:c4:93:56:13:e4:07: > > c2:af:1b:43:70:a3:b9:03:f1:26:f8:7b:1d:02:69: > > 21:39:cf:d5:28:ee:3b:44:3c:c5:64:7c:aa > > ASN1 OID: sect163k1 > > writing EC key > > -BEGIN EC PRIVATE KEY- > > MFICAQEEFMRcQ6kXV4n/6P751rDUUvzUa3GYoAcGBSuBBAABoS4DLAAEAZzbIddJ > > F83Ek1YT5AfCrxtDcKO5A/Em+HsdAmkhOc/VKO47RDzFZHyq > > -END EC PRIVATE KEY- > > > > ~$ sudo openssl ecparam -genkey -name sect163k1 -out testkey2.pem > > ~$ sudo openssl ec -text -in testkey2.pem > > read EC key > > Private-Key: (163 bit) > > priv: > > 65:06:db:ea:88:38:0d:50:37:9e:3a:92:77:15:ca: > > 3c:76:d0:00:12 > > pub: > > 04:07:7d:dd:c1:89:12:75:42:d6:9e:06:79:24:e1: > > 8b:4a:49:df:57:ac:e2:04:95:a1:2f:b9:dc:a7:8c: > > 5f:c3:18:a5:a7:9c:fc:9d:be:7f:e6:d7:4e > > ASN1 OID: sect163k1 > > writing EC key > > -BEGIN EC PRIVATE KEY- > > MFICAQEEFGUG2+qIOA1QN546kncVyjx20AASoAcGBSuBBAABoS4DLAAEB33dwYkS > > dULWngZ5JOGLSknfV6ziBJWhL7ncp4xfwxilp5z8nb5/5tdO > > -END EC PRIVATE KEY- > > > > The two private keys are described in a different number of bytes. > > > > Since the 2nd generated private key is shown in 20 bytes i.e. 160 > bits, is it > > assumed that the MS 3 bits are 0? > > > > How is the public key partitioned? Where are the padding bits added > in this > > display? > > > > Thanks > > Doug Bailey > > > __ > OpenSSL Project > http://www.openssl.org > User Support Mailing List > openssl-users@openssl.org > Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
