s_server supporting multiple clients

2012-02-21 Thread Erwin Himawan
Hi folks,

Can the s_server support multiple clients connections?

Thanks,
Erwin


Re: weak key check?

2012-02-21 Thread Chris Dodd

On 02/19/2012 07:36 PM, anthony berglas wrote:

 Exactly. So you need about 112 bits of entropy / Pass Phrase to
 generate a good 2048 bit key. Remember that the vast majority of 2048
 bit numbers are not valid key pairs.

 My question is, has this been done, or would it be easy to do given
 the existing structure.


No, this is NOT true.  While it is the case that a good 2048 bit RSA key
gives you only about 112 bits of security, its not at all clear that you
can generate such a good key from less than 2048 bits of entropy.

Indeed, from the recently published Lenstra/Hughes attack, its clear
that using 112 bits of entropy to generate an RSA key (of any length)
cannot possibly give you more that 56 bits of security, and probably
far less.

Chris Dodd
d...@csl.sri.com

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Extract of Public key and Serial number from Certificate

2012-02-21 Thread praveenpvs

Thanks Stephen and DaveThank you very much for your inputs..

X509 *x509;


int main()
{
 x509 = NULL; 
fp=fopen(RSAKey.cer,rb); 
if(fp == NULL)
{
printf(Could not open the file \n);
return 0;
}
else
{
printf(Certificate file opened successfully \n);
}

x509 = PEM_read_X509(fp,NULL,NULL,NULL); 
if(x509 == NULL)
{
printf(error reading \n); 
}
else 
{
printf(reading success\n); 
ExtractSerialNumber();
ExtractPubKey();
}
fclose(fp); 
X509_free(x509);
}
int ExtractSerialNumber()
{
ASN1_INTEGER *ptr;
int iIndex = 0;
printf(Entered func - ExtractSerialNumber\n);
ptr = X509_get_serialNumber(x509);

printf(\nThe length of the serial number is %d \n,ptr-length);
while(iIndex  (int)ptr-length )
{
sprintf(gszSerialNumber+iIndex*2, %0.2X,ptr-data[iIndex++]);
}
printf(Serial Number is = %s\n, gszSerialNumber);
return 1;
}

int ExtractPubKey()
{
FILE *fp; 
EVP_PKEY *PubKey;
int iRetVal = 0;
printf(Entered func - ExtractPubKey\n);
fp = fopen(RSAPubKey.Dat, w+);
if(fp == NULL)
{
printf(Some problem with the file opening/creation \n);
return 0;
}
else
{
printf(File is opened \n);
}
PubKey = X509_get_pubkey(x509);
iRetVal = PEM_write_PUBKEY(fp, PubKey);
printf(The return value of PEM_write_PUBKEY is %d \n, iRetVal);
free(fp);
return iRetVal;
}
 
Thank you very much


Dr. Stephen Henson wrote:
 
 On Mon, Feb 20, 2012, Dave Thompson wrote:
 
  From: owner-openssl-us...@openssl.org On Behalf Of praveenpvs
  Sent: Sunday, 19 February, 2012 23:15
 
  I am new to OPENSSL. I have a certificate, i need to extract 
  public key and
  serial number from it. I know the command to do that, but i 
  wanted to use
  api in my application.
 snip
  Could you please help me with the corresponding apis for 
  these two commands?
  
 OpenSSL's X509_* module is mostly older code and does not 
 have a full opaque API as some more recent modules do.
 
 You first get the cert into a variable of type X509 
 which is actually struct x509_st declared in x509.h.
 Actually your code uses a pointer to such a struct 
 which is allocated and deallocated by OpenSSL calls.
 For a cert in a PEM-format file, which is what your 
 commandlines used, PEM_read_X509 declared in pem.h 
 reads it in and creates the X509. For other input 
 formats there are other options.
 
 Then just use fields from the struct as needed.
 myx509-cert_info-serialNumber is the serial and 
 myx509-cert_info-key is the subjectPublicKeyInfo.
 Note these are in internal formats: serialNumber 
 is an ASN1_INTEGER which can be converted with ASN1_* 
 routines to (or from) other numeric or text forms;
 key is another struct containing an AlgorithmIdentifier 
 (containing an OID and possibly but rarely parameters) 
 and a BIT STRING which in turn contains the encoding of 
 the actual key in a format dependent on the type of key.
 What you do with these depends on what you want to do.
 
 When you're done, x509_free() the pointer.
 
 
 Although some modules don't have an opaque API direct structure access is
 inadvisable if functions exist which can be used instead.
 
 In ths OPs case they do and the functions X509_get_serialNumber and
 X509_get_pubkey should be used.
 
 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
 
 
-- 
View this message in context: 
http://old.nabble.com/Extract-of-Public-key-and-Serial-number-from-Certificate-tp33354749p33361471.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: Extract of Public key and Serial number from Certificate

2012-02-21 Thread praveenpvs

I am having some problem with the following piece of code..

When I extracted the public key and saved to file, the Public key file looks
like:

-BEGIN PUBLIC KEY-
MIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQCcKeojdze5WBip9ZT5GzNu6gcg
X/Vw4hftCDIQ5TQ6DHDxKxBfapCgKx/4tIgomsm3P9Q6JjhxOZjv/zOvlmQDtVb5
qnNnV8TxnA5n8LT7lrgKX2aiPVLmmaA2VnpAetL7shUUy46Tu+prSIIne3n80vRI
5vR7e5ghrRZAGSs2YQIBAw==
-END PUBLIC KEY

The above Public key is not valid. It misses out -- at the end.

I am not able to figure out what is problem.
Any suggestions/thoughts??

Thank you


Thanks Stephen and DaveThank you very much for your inputs..

X509 *x509;


int main()
{
 x509 = NULL; 
fp=fopen(RSAKey.cer,rb); 
if(fp == NULL)
{
printf(Could not open the file \n);
return 0;
}
else
{
printf(Certificate file opened successfully \n);
}

x509 = PEM_read_X509(fp,NULL,NULL,NULL); 
if(x509 == NULL)
{
printf(error reading \n); 
}
else 
{
printf(reading success\n); 
ExtractSerialNumber();
ExtractPubKey();
}
fclose(fp); 
X509_free(x509);
}
int ExtractSerialNumber()
{
ASN1_INTEGER *ptr;
int iIndex = 0;
printf(Entered func - ExtractSerialNumber\n);
ptr = X509_get_serialNumber(x509);

printf(\nThe length of the serial number is %d \n,ptr-length);
while(iIndex  (int)ptr-length )
{
sprintf(gszSerialNumber+iIndex*2, %0.2X,ptr-data[iIndex++]);
}
printf(Serial Number is = %s\n, gszSerialNumber);
return 1;
}

int ExtractPubKey()
{
FILE *fp; 
EVP_PKEY *PubKey;
int iRetVal = 0;
printf(Entered func - ExtractPubKey\n);
fp = fopen(RSAPubKey.Dat, w+);
if(fp == NULL)
{
printf(Some problem with the file opening/creation \n);
return 0;
}
else
{
printf(File is opened \n);
}
PubKey = X509_get_pubkey(x509);
iRetVal = PEM_write_PUBKEY(fp, PubKey);
printf(The return value of PEM_write_PUBKEY is %d \n, iRetVal);
free(fp);
return iRetVal;
}
 
Thank you very much

-- 
View this message in context: 
http://old.nabble.com/Extract-of-Public-key-and-Serial-number-from-Certificate-tp33354749p33364574.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: FIPS fingerprint in .data not .rodata

2012-02-21 Thread Andy Polyakov
 Though in FIPS 2.0 there is new option that might work in this case.
 Besides switching to another compiler that is. Introduced to rectify
 situation with rodata segments not being position-independent on Win64,
 defining __fips_constseg might prove useful even in this situation. See
 if defining it in fips/fipssyms.h to __attribute__((section(.rodata)))
 makes it work. Keep in mind that me suggesting this doesn't make it
 validated. If it works, it still has to be separately validated by
 authorities.

 Ok, so I did this and added it to appropriate locations in
 fips_canister.c
 Right, you need the __attribute__ in question even for
 FIPS_rodata_[start|end]. I failed to mention this. Good catch.

 
 Well, this idea at first looked like it would do the trick, however,
 when the __attribute__((section(.rodata))) call makes a .rodata
 section, it isn't *the* .rodata section, it is just *a* .rodata
 section and in fact is made writeable,

Well, then it's tough break, switch to another compiler.

Of course one can name section something else, e.g. .rofips, and write
a script that would set the read-only flag in fipscanister.o after it's
linked. Or! It would be possible to modify incore to set the flag. I
mean fipscanister.o can have .rofips that is not read-only, but it can
become read-only in applications and shared lib in the process of
embedding the signature. Well, whatever you do requires code change, so
you have to validate it separately (change letter through
opensslfoundation.com might be alternative)...

 The assembler code looks correct for FIPS_text_startX returning its
 memory location.

The question was if FIPS_text_start returns FIPS_text_startX's address
[of its first instruction], *not* what does FIPS_text_startX return!
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: FIPS fingerprint in .data not .rodata

2012-02-21 Thread Kevin Fowler
On Tue, Feb 21, 2012 at 1:11 PM, Andy Polyakov ap...@openssl.org wrote:
 Though in FIPS 2.0 there is new option that might work in this case.
 Besides switching to another compiler that is. Introduced to rectify
 situation with rodata segments not being position-independent on Win64,
 defining __fips_constseg might prove useful even in this situation. See
 if defining it in fips/fipssyms.h to __attribute__((section(.rodata)))
 makes it work. Keep in mind that me suggesting this doesn't make it
 validated. If it works, it still has to be separately validated by
 authorities.

 Ok, so I did this and added it to appropriate locations in
 fips_canister.c
 Right, you need the __attribute__ in question even for
 FIPS_rodata_[start|end]. I failed to mention this. Good catch.


 Well, this idea at first looked like it would do the trick, however,
 when the __attribute__((section(.rodata))) call makes a .rodata
 section, it isn't *the* .rodata section, it is just *a* .rodata
 section and in fact is made writeable,

 Well, then it's tough break, switch to another compiler.

 Of course one can name section something else, e.g. .rofips, and write
 a script that would set the read-only flag in fipscanister.o after it's
 linked. Or! It would be possible to modify incore to set the flag. I
 mean fipscanister.o can have .rofips that is not read-only, but it can
 become read-only in applications and shared lib in the process of
 embedding the signature. Well, whatever you do requires code change, so
 you have to validate it separately (change letter through
 opensslfoundation.com might be alternative)...


Another option (but shoot it down if its bogus :-): I noticed that if I compile
fipscanister.o without -fPIC, then the const variables do get placed in
the (really readonly) .rodata section as desired. I thought maybe if I did
that and went the static route - build libcrypto with no-shared and link
libcrypto.a statically into my app - then maybe I would have a validate-able
solution. I checked that the FIPS-bounded .text and .rodata regions are
the same for the app and the fipscanister.o, and the app integrity
test passes and fips mode gets enabled on the target.

Per your comment below, FIPS_text_start (and end) also looks
correct in the disassembled code:

0181ae34 FIPS_text_start:
 181ae34:   3c 60 01 82 lis r3,386  (0x182)
 181ae38:   38 63 ae 40 addir3,r3,-20928( - 0x51c0)
 181ae3c:   4e 80 00 20 blr( = 0x181ae40)

0181ae40 FIPS_text_startX:
 181ae40:   7c 08 02 a6 mflrr0
 181ae44:   48 00 00 05 bl  181ae48 FIPS_text_startX+0x8
 181ae48:   7c 68 02 a6 mflrr3
 181ae4c:   7c 08 03 a6 mtlrr0
 181ae50:   4e 80 00 20 blr

I am expecting to have to do a change letter validation - just trying
to minimize the necessary changes so that it will qualify for that option
rather than a full-blown validation - which probably would not be viable for us.

I assume that if a target can't support shared libraries properly then it is
still ok to have the static alternative validated..?

 The assembler code looks correct for FIPS_text_startX returning its
 memory location.

 The question was if FIPS_text_start returns FIPS_text_startX's address
 [of its first instruction], *not* what does FIPS_text_startX return!
 __
 OpenSSL Project                                 http://www.openssl.org
 Development Mailing List                       openssl-...@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


Re: FIPS fingerprint in .data not .rodata

2012-02-21 Thread Andy Polyakov
 Another option (but shoot it down if its bogus :-): I noticed that if I 
 compile
 fipscanister.o without -fPIC, then the const variables do get placed in
 the (really readonly) .rodata section as desired. I thought maybe if I did
 that and went the static route - build libcrypto with no-shared and link
 libcrypto.a statically into my app - then maybe I would have a validate-able
 solution.

The prime reason for why FIPS 2.0 module is compiled with -fPIC is to
make it versatile. Idea is to validate *single* fipscanister.o usable in
either context, statically-linked application or dynamic library.
Reasoning is that while it's plain inappropriate to use non-PIC code in
dynamic library, linking PIC statically was proven to work on all tested
platforms, therefore -fPIC.

This naturally means that if you are positively not interested in
unified/versatile fipscanister.o nothing prevents you from giving up on
-fPIC and targeting statically-linked application only. I.e. introducing
config-line without -fPIC through change letter is as validate-able as
anything else.

 Per your comment below, FIPS_text_start (and end) also looks
 correct in the disassembled code:

 0181ae34 FIPS_text_start:
 ...

Yes, it looks proper.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: FIPS fingerprint in .data not .rodata

2012-02-21 Thread Jeffrey Walton
On Tue, Feb 21, 2012 at 3:51 PM, Andy Polyakov ap...@openssl.org wrote:
 Another option (but shoot it down if its bogus :-): I noticed that if I 
 compile
 fipscanister.o without -fPIC, then the const variables do get placed in
 the (really readonly) .rodata section as desired. I thought maybe if I did
 that and went the static route - build libcrypto with no-shared and link
 libcrypto.a statically into my app - then maybe I would have a validate-able
 solution.

 The prime reason for why FIPS 2.0 module is compiled with -fPIC is to
 make it versatile. Idea is to validate *single* fipscanister.o usable in
 either context, statically-linked application or dynamic library.
 Reasoning is that while it's plain inappropriate to use non-PIC code in
 dynamic library, linking PIC statically was proven to work on all tested
 platforms, therefore -fPIC.

 This naturally means that if you are positively not interested in
 unified/versatile fipscanister.o nothing prevents you from giving up on
 -fPIC and targeting statically-linked application only. I.e. introducing
 config-line without -fPIC through change letter is as validate-able as
 anything else.
I believe you might also get a small performance boost since -fPIC
results in use of %ebx on x86 (IIRC).
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


Re: FIPS fingerprint in .data not .rodata

2012-02-21 Thread Kevin Fowler
On Tue, Feb 21, 2012 at 3:51 PM, Andy Polyakov ap...@openssl.org wrote:
 Another option (but shoot it down if its bogus :-): I noticed that if I 
 compile
 fipscanister.o without -fPIC, then the const variables do get placed in
 the (really readonly) .rodata section as desired. I thought maybe if I did
 that and went the static route - build libcrypto with no-shared and link
 libcrypto.a statically into my app - then maybe I would have a validate-able
 solution.

 The prime reason for why FIPS 2.0 module is compiled with -fPIC is to
 make it versatile. Idea is to validate *single* fipscanister.o usable in
 either context, statically-linked application or dynamic library.
 Reasoning is that while it's plain inappropriate to use non-PIC code in
 dynamic library, linking PIC statically was proven to work on all tested
 platforms, therefore -fPIC.

 This naturally means that if you are positively not interested in
 unified/versatile fipscanister.o nothing prevents you from giving up on
 -fPIC and targeting statically-linked application only. I.e. introducing
 config-line without -fPIC through change letter is as validate-able as
 anything else.

That is certainly sensible. But for my present needs, the static would
be just fine - I really need something as a bridge to a newer OS/gcc
version I'll be doing at a later point, and on which the -fPIC option
will likely be supported better...

I'll keep your last suggestion above in my back pocket though. Thanks
for your insight and keeping me on a correct track.


 Per your comment below, FIPS_text_start (and end) also looks
 correct in the disassembled code:

 0181ae34 FIPS_text_start:
 ...

 Yes, it looks proper.
 __
 OpenSSL Project                                 http://www.openssl.org
 Development Mailing List                       openssl-...@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


RE: Extract of Public key and Serial number from Certificate

2012-02-21 Thread Dave Thompson
 From: owner-openssl-us...@openssl.org On Behalf Of praveenpvs
 Sent: Tuesday, 21 February, 2012 10:24

 When I extracted the public key and saved to file, the Public 
 key file looks like [---END--- line incomplete]
snip code
 I am not able to figure out what is problem.
 Any suggestions/thoughts??
 
There's no fclose() in the code you posted. Without that or 
at least fflush(), depending on what happens later in the 
same process the file MIGHT not get written properly.

Also, ExtractSerialNumber is storing to gszSerialNumber, 
presumably a global buffer, without checking for overflow.
Any buffer overflow in C can be Very Bad News. serial 
values in X.509 certs nowadays are usually randomized 
and 10 or 20 or more bytes (though not by openssl 'ca').

And, if fopen() fails it is usually more helpful to show 
strerror(errno), or call perror() which does that for you, 
rather than just saying some problem. Similarly, if any 
OpenSSL routine (with a few exceptions) returns an error 
indication (like NULL from PEM_read_* or 0 from SSL_connect) 
it is almost always helpful to show OpenSSL's error queue. 
The easy and standard way is to call ERR_print_errors[_fp] 
usually on stderr, having done SSL_load_error_strings 
(or similar) at initialization. If you want to format 
differently see man ERR_get_error . Note
http://www.openssl.org/support/faq.html#PROG6
http://www.openssl.org/support/faq.html#PROG7

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org