[PATCH] to fix compilation issues of openssl v100a for WCE 420/WM5/WM6 target platform

[Pierre DELAAGE]

Dear All,
I am a contributor to the WCE port of stunnel, using intensively openssl.
I have recently completed the port of stunnel v434 to WCE platform,
and needed a refreshed version of openssl for that target.

I have recompiled openssl v100a with MS EVC4 sp4 free compiler, MS 
WCE420 SDK and essemer/wcecompat 1.2 library,
and fixed many compilation issues (mostly undefined symbols, a few 
inexistant routines, some libs missing at link time).



I DID NOT fix any "operational" issue, ie execution-time issue.
My code is basically a PORTING effort, not at all a rewrite or enriching 
effort. In particular I have a special concern to have wce code as close 
as possible as win32 code.



Please find enclosed my patch in "diff -ur orig patched" format.

SUMMARY of fixes for compilation issues :

  ./apps/apps.c:
strings.h is not relevant in WCE environment.

  ./apps/apps.h
FD_SET must include proper cast for WCE, as for win32.
NOTA: this cast should be corrected in the future to UNIT_PTR,
instead of "unsigned int", as it is defined like this in the MS SDK.

  ./crypto/bio/bss_dgram.c
get_current_time NEEDED a WCE code,
as _ftime DOES NOT exist in WCE420 SDK.
Nota: one day my code should go in wcecompat (I have to discuss with 
Maurice Kalinowski about that, and about the replacement of wccompat 1.2 
by mauricek or alike version).


  ./crypto/bio/bss_fd.c
some functions ARE missing definition for WCE.

BIO *BIO_new_fd(int fd,int close_flag)
int BIO_fd_non_fatal_error(int err)
int BIO_fd_should_retry(int i)
BIO_METHOD *BIO_s_fd(void)

By default I put a stub.
Is it sufficient ? at least it works with stunnel.

  ./crypto/cryptlib.c
"raise" DOES NOT exist in WCE environment.
Nota: In win32 _exit(3) is redundant with raise(sigabrt),
because raise implies exit(3), dixit MS doc.

  ./crypto/dso/dso_win32.c
len=0 just put to AVOID a warning of the compiler
because this variable is NOT used in CE code.

  ./crypto/o_str.c
strings.h is not relevant in WCE environment.

  ./crypto/opensslconf.h : no need of any explanation, automatically 
generated file.


  ./e_os.h
"winsock2/ws2tcp" includes ARE needed in WCE environment.

EACCES symbol must be defined in WCE: fix would have to be included in 
wcecompat stream one day.


  ./engines/ccgost/gost_lcl.h
Missing type "off_t"

  ./engines/e_capi.c
In WCE SDK, only UNICODE version of some Crypt function exist.
But openssl explicitely uses ANSI fucntions.
So I offer some code for this :
CryptEnumProvidersA
CryptAcquireContextA
CryptSignHashA

These ARE NOT STUB, but code really doing something.

  ./Makefile
automatically generated, some lines changed due to change in VC-32.pl

  ./ssl/d1_lib.c
get_current_time needed to be defined with "real code", not stub.
Nota: This code is a DUPLICATE of bss_dgram.c code :
same function get_current_time, same code.


  ./util/pl/VC-32.pl
VERY IMPORTANT : strangely the link process was supposed to link with 
winsock 1 lib !
It is a big error as all openssl code is using winsock2, which is much 
more bsd compliant than winsock1.
So the linkage must be done with ws2.lib (which is for WCE what 
ws2_32.lib is for win32).


crypt32.lib IS ALSO MANDATORY now in WCE port, as in win32.


NOTE : I would also suggest to modify the INSTALL.WCE file just to 
mention EVC4 and wcecompat 1.2 instead of evc3 and wcecompat 1.1, and 
also the fact that out32dll path is now out32dll_$(TARGETCPU)


NOTE 2 : just in case it may help, precompiled (patched) versions of 
openssl v100a and stunnel v434 for ARMV4 processors/WCE420 platform,

are available at http://delaage.pierre.free.fr.
The result works fine for HTC WM6 smartphones, and should work for WM5 
phones.


Thank you very much for your work.
Yours sincerely,

Pierre Delaage



diff -ur orig/apps/apps.c patched/apps/apps.c
--- orig/apps/apps.c2010-09-25 16:45:29.563877500 +0200
+++ patched/apps/apps.c 2010-09-26 07:12:44.368479500 +0200
@@ -118,7 +118,7 @@
 #include 
 #include 
 #include 
-#if !defined(OPENSSL_SYSNAME_WIN32) && !defined(NETWARE_CLIB)
+#if !defined(OPENSSL_SYSNAME_WIN32) && !defined(OPENSSL_SYSNAME_WINCE) && 
!defined(NETWARE_CLIB) //pdelaage 20100926
 #include 
 #endif
 #include 
diff -ur orig/apps/apps.h patched/apps/apps.h
--- orig/apps/apps.h2009-10-31 14:34:19.0 +0100
+++ patched/apps/apps.h 2010-09-26 07:13:54.676479500 +0200
@@ -202,8 +202,9 @@
 #  endif
 #endif
 
-#ifdef OPENSSL_SYSNAME_WIN32
-#  define openssl_fdset(a,b) FD_SET((unsigned int)a, b)
+// pdelaage 20100926 #ifdef OPENSSL_SYSNAME_WIN32
+#if defined(OPENSSL_SYSNAME_WIN32) || defined(OPENSSL_SYSNAME_WINCE)
+#  define openssl_fdset(a,b) FD_SET((unsigned int)a, b) // pdelaage uint 
should be UINT_PTR !
 #else
 #  define openssl_fdset(a,b) FD_SET(a, b)
 #endif
diff -ur orig/crypto/bio/bss_dgram.c patched/crypto/bio/bss_dgram.c
--- orig/crypto/bio/bss_dgram.c 2010-01-07 11:44:21.0 +0100
+++ patched/crypto/bio/bss_dgram.c  2010-09-24 22:28:07.948264500 +0200
@@ -815,10 +815,43 @@
 static void 

Re: FIPS PowerOn self test

[Vivek Madani]

> 
>
>>>
>>> What OS is this running on? That error can be caused by a DLL being loaded 
>>> to
>>> an address that is already in use under Windows and relocation would
>>> invalidate the signature.
>>>
>>> You can work around that by specifying an alternative load address when the
>>> DLL is compiled.
>>>
>>
>> This is Win2K3 on a virtual machine. I thought about the load address
>> and is looking through ProcessExplorer to see where the conflict is.
>> Will try a recompile.
>>
>
> One more query: Shouldn't fips_test_suite.exe report failure as well?
> That passes without any issues.
>

Sorry for fragmenting my queries. Just figured out that there is
another DLL loaded at 0xFAF which occupies 0x44000 bytes. So I
guess that explains why libeay32.dll is not getting loaded at
0xFB0. Now my query is if I recompile it with a different base
address, isn't there a rare possibility that I might see this issue in
some other environment? Anyway I can be sure that this will work
always?

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

Re: FIPS PowerOn self test

[Vivek Madani]

>>
>> What OS is this running on? That error can be caused by a DLL being loaded to
>> an address that is already in use under Windows and relocation would
>> invalidate the signature.
>>
>> You can work around that by specifying an alternative load address when the
>> DLL is compiled.
>>
>
> This is Win2K3 on a virtual machine. I thought about the load address
> and is looking through ProcessExplorer to see where the conflict is.
> Will try a recompile.
>

One more query: Shouldn't fips_test_suite.exe report failure as well?
That passes without any issues.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: FIPS PowerOn self test

[Vivek Madani]

>> >
>> >> Hi,
>> >>
>> >> What are the conditions when power-on self tests may fail. We have an
>> >> application using OpenSSL in FIPS mode and the power on self test has
>> >> always succeeded. However, today on one of the virtual machines the
>> >> test failed. What could have possibly lead to this failure? Any ideas?
>> >>
>> >
>> > If the test worked before then the most likely cause is that the binary got
>> > corrupted somehow and this resulted in the integrity test failing. If you 
>> > log
>> > the error produced it should give you more information.
>> >
>>
>> Here is some more information:
>> 1. fips_mode_set(1) is failing always if I run my application on a
>> virtual machine through VMWare console. fips_test_suite.exe does not
>> show any failures.
>> Error String: error:2D06906F:lib(45):func(105):reason(111)
>> Error Code: 755404911
>>
>> 2. fips_mode_set(1) works fine and is successful if I run same
>> application (same binaries) on same virtual machine but now through
>> Microsoft Terminal Server Client (RDP) instead of VMWare console.
>>
>> I know this is strange but I am yet to derive why this behavior is observed.
>
> What OS is this running on? That error can be caused by a DLL being loaded to
> an address that is already in use under Windows and relocation would
> invalidate the signature.
>
> You can work around that by specifying an alternative load address when the
> DLL is compiled.
>

This is Win2K3 on a virtual machine. I thought about the load address
and is looking through ProcessExplorer to see where the conflict is.
Will try a recompile.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: FIPS PowerOn self test

[Dr. Stephen Henson]

On Mon, Sep 27, 2010, Vivek Madani wrote:

> On Mon, Sep 27, 2010 at 6:10 PM, Dr. Stephen Henson  wrote:
> > On Sat, Sep 25, 2010, Vivek Madani wrote:
> >
> >> Hi,
> >>
> >> What are the conditions when power-on self tests may fail. We have an
> >> application using OpenSSL in FIPS mode and the power on self test has
> >> always succeeded. However, today on one of the virtual machines the
> >> test failed. What could have possibly lead to this failure? Any ideas?
> >>
> >
> > If the test worked before then the most likely cause is that the binary got
> > corrupted somehow and this resulted in the integrity test failing. If you 
> > log
> > the error produced it should give you more information.
> >
> 
> Here is some more information:
> 1. fips_mode_set(1) is failing always if I run my application on a
> virtual machine through VMWare console. fips_test_suite.exe does not
> show any failures.
> Error String: error:2D06906F:lib(45):func(105):reason(111)
> Error Code: 755404911
> 
> 2. fips_mode_set(1) works fine and is successful if I run same
> application (same binaries) on same virtual machine but now through
> Microsoft Terminal Server Client (RDP) instead of VMWare console.
> 
> I know this is strange but I am yet to derive why this behavior is observed.

What OS is this running on? That error can be caused by a DLL being loaded to
an address that is already in use under Windows and relocation would
invalidate the signature.

You can work around that by specifying an alternative load address when the
DLL is compiled.

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

RE: where is the memory being held

[Scott Neugroschl]

As David said, yes.
 
On the other hand, you could re-implement malloc() and free() for your platform.



From: owner-openssl-us...@openssl.org on behalf of zhu qun-ying
Sent: Sun 9/26/2010 11:14 PM
To: openssl-users@openssl.org
Subject: Re: where is the memory being held



Does it mean that it is hard to change the behavior?
--
qun-ying


--- On Fri, 9/24/10, David Schwartz  wrote:
>
> Sounds like OpenSSL wasn't what you wanted. OpenSSL is
> intended for use on general-purpose computers with virtual
> memory. It is not designed to return virtual memory to the
> system, which in your case means it won't return physical
> memory to the system. Ouch.
>
> DS
>



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

Re: where is the memory being held

[David Schwartz]

On 9/26/2010 11:14 PM, zhu qun-ying wrote:


Does it mean that it is hard to change the behavior?


Yes, because it's not implemented in any one particular place. It's a 
fundamental design assumption throughout OpenSSL that it's aimed at 
general-purpose computers with virtual memory subsystems.


DS

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

Re: Does OpenSSL have any plans of supporting SSL_read / SSL_write on the same SSL_S from multiple threads?

[David Schwartz]

On 9/25/2010 9:31 AM, Jayaraghavendran k wrote:


(a) Does OpenSSL plan to support this feature in any of it's future
releases? (Or does any of the releases already support it? I went
through the Change Logs, but couldn't find anything), If no, why not?


I can't answer whether there are any plans, but I doubt it. The reason 
not to is that the library is not the right place to implement that kind 
of logic.



(b) As far as I understand, the main problem with the parallel
SSL_read / SSL_write is renegotiation, i.e. a call to SSL_read can
lead to a send call and vice-versa, so, if I ensure I don't do
renegotiation at all (both sides use my application) then will the
code work fine?


No, it will still break. The SSL connection has one and only one state, 
and you are trying to manipulate it from two places at the same time.



(c) I would also like to know the reason behind such a design
considering the fact that TCP supports parallel send / recv. Is it
enforced by the protocol design or any other design parameters forced
such a design?


This is how every other library works. TCP is an exception.

Take, for example, a typical string library. You can perform 'read' 
operations (those that do not change state) from multiple threads to the 
same string at the same time. But you would never expect the string 
library to support two 'write' operations (those that do change state) 
to be supported to the same string at the same time. If you did, say 
'a+="A";' and 'a+="B";' at the same time in two different threads, you 
wouldn't expect a sensible result.


Another problem is that there's basically no way OpenSSL could provide 
this capability without a service thread. Consider if a blocking 
SSL_read is terminated from another thread that calls a shutdown 
function -- what thread is left to complete the SSL protocol shutdown? 
TCP handles lingering data in the kernel with the kernel's own threads, 
but OpenSSL can't do that. And unless you use a service thread per 
connection in flux, you wind up in the very platform-specific world of 
I/O multiplexing.


All of this can be done, but not sensibly inside OpenSSL.

DS

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

Error signing certificates with my own CA... Configuration file?

[Chris Rider]

  I've found the alternative to self-signing (namely signing with your 
own CA) to be a potentially great path for the web application that we 
develop; however I can't quite figure out how exactly to tweak the 
configuration file to get what I want. It is hard (impossible?) to find 
any detailed information about each of the directives in that file.


Basically, I've successfully(?) created my own CA (the certificate is 
able to be installed automatically as trusted root, and everything), but 
when I go to sign or use a server certificate (for the end-user) using 
that, I get problems.


In order to attempt all this voodoo, I've basically created two separate 
directories (one for my CA and another for my end-user certificates)... 
each containing their own directory structure (private, certs, etc.) and 
their own openssl config files. Is this the right approach, first of 
all? I assume since the CA has its own unique configuration directives 
(e.g. CA=True), the end-user cert should be different... right?


So, first, I want to make sure I am creating the CA keys properly
Can someone provide a list of configuration directives (or link to them) 
that are necessary for a CA in my type of situation?


I at least know CA=True and keyUsage needs to include certSign (many 
thanks to Patrick!)... but what, if anything, else?


Then, same for the end-user certificates... anything special there?

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

Re: LNK4078 and LNK4210 linking with x64 static libs

[per frykenvall]

Hi, again,

Could anybody with insight in the OPENSSL_cpuid_setup have a look at 
this issue? What is the impact when it doesn't get called on win x64? 
Does the section need some flag? I haven't found any resolution to the 
problem.


Best regards,
Per Frykenvall

Jakob Bohm wrote:

Actually, that section (specifically, the DQ line) places a single
pointer constant in a data section with the "magic" name ".CRT$XCU".

Background:

The Microsoft linker, upon seeing a $ sign in a section name will
merge this section with all other sections name ".CRT" or 
".CRT$whatever", but only after it has ordered the layout of that

section alphabetically according to the non-truncated section name.
Thus the constants in .obj section ".CRT$XCU" will be placed between
anything in sections ".CRT$XCT" (or less) and anything in sections
".CRT$XCV" (or more).

The Microsoft C runtime startup code contains declarations for dummy
NULL variables in sections ".CRT$XCA" and ".CRT$XCZ" and a loop
which treats the data between those sections (including the DQ placed
there by this ASM file and any constructors for C++ global variables
etc.) as an array of function pointers to be called before
invoking main().  A similar method (with a different letter after X
is used for functions to call after main() returns or during a call to
exit()).

The above description matches at least the C runtime in Visual Studio
2005 (look at the files VC\CRT\src\crt0init.c and VC\CRT\src\crt0dat.c).

Error message analysis:

The warning complains that something in section .CRT has been given
the section attributes 0x6020 (meaning Read/Execute, contains code),
even though the rest of the file section it ultimately goes into 
(".rdata") has attributes 0x4040 (meaning Read, contains 
initialized data).


Thus my guess is that the line "section.CRT$XCU" is lacking
some keywords to tell the assembler to mark that section as
read-only data, not code.  Unfortunately, I am not sure of the
syntax to do that in the x86_64 version of MASM.


On 23-09-2010 15:09, Jack Zhang wrote:

According to my understanding, that section is just a declaration of an
external function. The section is needed to be there only if the
function is called in the x86_64cpuid.asm. So, I don't think it will
affect anything. In fact, my x64 version build runs perfectly. (I am
using openssl 1.0.0 and then 1.0.0a)



On Thu, Sep 23, 2010 at 7:12 AM, per fry kenvall mailto:per...@got.wmdata.se>> wrote:

Hi,

Thanks for your suggestion! But as far as I see, the assembler code
in x86_64cpuid.asm _is_ the reference to OPENSSL_cpuid_setup! The
runtime will call the functions given in the .CRT$XCU section before
calling the main() entry. And it seems to me that the
OPENSSL_cpuid_setup function in crypto/cryptlib.c does have useful
code on Windows platforms, and so should be called, shouldn't it? It
initializes a static variable with some processor specific info,
whose value may be taken via the OPENSSL_ia32cap_loc() function.

I tried printf("%lu", *OPENSSL_ia32cap_loc()), which prints out 0
using the x64 code, while printing 2951479295 using 32-bit code,
indicating that OPENSSL_cpuid_setup has only been executed with the
32-bit code. What's the impact of this? Isn't it a bug?

Cheers,
Per

Jack Zhang wrote:

I had got the same problem. I just simply deleted that section
  EXTERNOPENSSL_cpuid_setup
  section.CRT$XCU
  ALIGN8
  DQOPENSSL_cpuid_setup

  section.text code align=64

from the asm file because the extern OpenSSL_cpuid_setup is
never referenced.

Good luck

On Tue, Sep 21, 2010 at 9:57 AM, perfry wrote:

Hi,

I've built 1.0.0a on Windows with VS2005, using nt.mak to 
get

static libraries.
With x64 I get warnings when linking applications, both
openssl.exe and test programs like sha1test.exe. A 
snippet of

output from nmake -f ms\nt.mak:
  link /nologo /subsystem:console /opt:ref /debug
/out:out32\openssl.exe
@C:\DOCUME~1\FRYKEN~1\LOCALS~1\Temp\nm3B3.tmp
LIBCMT.lib(crt0init.obj) : warning LNK4254: section '.CRT'
(6020) merged into '.rdata' (4040) with different
attributes


And when linking our own application on x64/Release 
platform:

  libeay32.lib(x86_64cpuid.obj) : warning LNK4078: multiple
'.CRT'
sections found with different attributes (60500020)
  libeay32.lib(x86_64cpuid.obj) : warning LNK4210: .CRT 
section

exists; there may be unhandled static initializers or
terminators


The linker command can be deduced from the following:
  Creating temporary file
"c:\utv\ccbas4\ccbase\x64\Release\RSP132444832.rsp" with
contents
  

Re: how to use ecdsa-with-sha2 algorithm with ecdsa signature algorithm

[adkelkar]

Hi Rajan,
Bad stuck at the ecdsa with sha256 and sha384 cert and key generation.
Have really short deadlines.
Tried hunting lots

Finally found this but didnt see any reply to your query.
Hope you got your answer..

Can you please help me in generating this cert and key?

Regards,
-Amol




rajanchittil wrote:
> 
> Hi all,
> 
> I tried to generate certificate with ecdsa algorithm . but whenever i
> displayed the certificate, i can see the 
> following signtaure algorithm 
> 
>   X509v3 extensions:
> X509v3 Subject Key Identifier:
>
> 58:7C:AD:AF:E4:4D:AF:E8:37:E8:81:DC:49:C8:B0:6F:2D:CD:A4:18
> X509v3 Authority Key Identifier:
>
> keyid:58:7C:AD:AF:E4:4D:AF:E8:37:E8:81:DC:49:C8:B0:6F:2D:CD:A4:18
> DirName:/C=US/ST=CA/L=Mountain View/O=Sun Microsystems,
> Inc./OU=Sun Microsystems Laboratories/CN=Test CA (Elliptic curve
> secp160r1)
> serial:E3:87:8E:A5:E8:D7:9C:23
> 
> X509v3 Basic Constraints:
> CA:TRUE
> Signature Algorithm: ecdsa-with-SHA1
> 
> I want to use ecdsa-with-SHA2 algorithm .
> 
> This is the step i followed to generate the certificate 
> 
> 1. Generating curve parameters
> 
> openssl ecparam -name prime192v2 -out server.pem
> 
> 2. Generate a new certificate request 
> 
> openssl req -nodes  -keyout server.key.pem -newkey ec:server.pem -new -out
> server.req.pem
> 
> 3. Sign the certificate request  using the CA certificate 
> 
> openssl x509 -req -in server.req.pem -CA CA_File.cert.pem -CAkey
> CAFile.key.pem -out server.cert.pem -CAcreateserial
> 
> 4.  Display the certificate
> 
> openssl x509  -in server.cert.pem -text
> 
> Can you guide me how to use to ecdsa-with-SHA2 algorithm . Please help
> 
> Thanks
> 
> Rajan
>  
> 

-- 
View this message in context: 
http://old.nabble.com/how-to-use-ecdsa-with-sha2-algorithm-with-ecdsa-signature-algorithm-tp23254140p29815743.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

Legal use OpenSSL / cryptography

[TS]

Hi,


I'm from and live in Denmark. I make and sell a 
program (shareware, not someone making me 
rich mind you) which has a website crawler. 
I use Indy HTTP library for HTTP communication.

...

However, I would like to use OpenSSL with Indy for https:

If I allow my users to download OpenSSL *themselves* to
application directory and enable OpenSLL in my program 
config, can I still get in trouble? What about my end-users?

(I realize it's probably 100% okay in DK and Europe.
But suppose I were to travel to US some day?)

Suppose a download website links to my application?
Would they get in trouble then? Even though my 
software does not distribute OpenSSL itself?

...

I may have to give up on supporting https
or opt for another route. But OpenSSL works, 
so if it was within realm of possibility to get
legality cleared, then that would be great.


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

Re: Signed Certificates and Revoking the Certs with CRLs

[Tomas Gustavsson]

Why no try the open source PKI book as a starter...

http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm

Cheers,
Tomas

On 09/24/2010 10:13 PM, Hasan Rezaul-CHR010 wrote:

Hi All,

Would anyone kindly point me to literature that CLEARLY explains exactly
how:

Certificates and CRLs may be used in conjunction such that certificate
CSRs are generated, signed by an authority, then signed certs downloaded
and being used on a system.

At a later time, the certificate is revoked in the CRL, the CRL.pem file
is downloaded on the system, and then the corresponding cert becomes
unusable due to its mention in the CRL.

Is there a good place for me to educate myself on this whole mechanism,
and a place where it shows exactly how to implement all this with
examples... Oh I am running on Linux, with openssl 0.9.8g.

Thanks a bunch in advance.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-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

Re: FIPS PowerOn self test

[Vivek Madani]

On Mon, Sep 27, 2010 at 6:10 PM, Dr. Stephen Henson  wrote:
> On Sat, Sep 25, 2010, Vivek Madani wrote:
>
>> Hi,
>>
>> What are the conditions when power-on self tests may fail. We have an
>> application using OpenSSL in FIPS mode and the power on self test has
>> always succeeded. However, today on one of the virtual machines the
>> test failed. What could have possibly lead to this failure? Any ideas?
>>
>
> If the test worked before then the most likely cause is that the binary got
> corrupted somehow and this resulted in the integrity test failing. If you log
> the error produced it should give you more information.
>

Here is some more information:
1. fips_mode_set(1) is failing always if I run my application on a
virtual machine through VMWare console. fips_test_suite.exe does not
show any failures.
Error String: error:2D06906F:lib(45):func(105):reason(111)
Error Code: 755404911

2. fips_mode_set(1) works fine and is successful if I run same
application (same binaries) on same virtual machine but now through
Microsoft Terminal Server Client (RDP) instead of VMWare console.

I know this is strange but I am yet to derive why this behavior is observed.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: FIPS PowerOn self test

[Dr. Stephen Henson]

On Sat, Sep 25, 2010, Vivek Madani wrote:

> Hi,
> 
> What are the conditions when power-on self tests may fail. We have an
> application using OpenSSL in FIPS mode and the power on self test has
> always succeeded. However, today on one of the virtual machines the
> test failed. What could have possibly lead to this failure? Any ideas?
> 

If the test worked before then the most likely cause is that the binary got
corrupted somehow and this resulted in the integrity test failing. If you log
the error produced it should give you more information.

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

Re: SHA1 Message Digest Getting Generated less than 160 Bits i.e. 152 bits.

[Jean-Marc Desperrier]

Kedar Sabnis wrote:

in some specific case SHA1 digest is coming as 152 bits long instead of
160 bits long.


All possible 160 bits values have the same chance of being the output of 
a SHA1 digest, *including* those that comprise long strings of all zeros 
or all ones.


This mean that, statistically, for 256 SHA1 hash values you generate you 
get one for which the initial byte is all zero. Depending on your code, 
this may make that value look like it's only 152 bits long instead of 160.

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

Re: [openssl-users] RE: Creating Extended Validation SSL Certificates

[Erwann ABALEA]

Bonjour,

Hodie V Kal. Oct. MMX, Gumbie scripsit:
>   I apologize to all for not looking into this more, before asking.
>   It isn't just a matter of adding the proper extensions. The
>   various browser software actually has the corporate policy OID
>   hard coded into the browser code. At first glance I would never of
>   thought this, as the delay to getting your product to the web
>   market may be a factor.

Please be more explicit about "your product". Is "your product" a
device? A server? If yes, then the delay is clearly not an issue, an
EV certificate can be bought and delivered in 1 or 2 days, if you're
ready for the necessary validations (EV stands for Extended
Validation).

>   Again unless you pay outrageous fees for
>   basically getting a notary seal from one of the certificate CA's
>   that have their policy already in place or you're out of luck!

Outrageous fees? A free SSL certificate is exactly of this value.
Zero, as nearly no verification is performed, or they're completely
automatic ones (i.e. send a challenge to a predefined email address,
wait for the answer, update the database to say 'OK, this guy controls
this address').

An EV certificate costs money:
 - robust facility, with safes, HSM, access controls, guaranteed
   connectivity (to provide revocation information), redundant sites
 - trained employees, and employees background screening (done on a
   regular basis)
 - up-to-date procedures; you seem to have downloaded the 1.0 version
   of the guidelines, dated 2007, an 1.2 version is already out, some
   work is currently done to update it; CAs must follow this work, and
   be informed about cryptography advances
 - "enrollment" of the CA on end-user products (some of them require
   work to be done, some of them require payment)
 - most sensible operations performed under screening and validation
   of a notary (namely key ceremonies)
 - audits performed each year
 - certificate request validations performed manually (i.e. by
   humans), with access to different information repositories (some of
   them may not be free), contact of the entity requesting the
   certificate, gathering and controlling necessary documents (ID
   information, for example)
 - usually using a proprietary software, written by the company
   itself, with quality controls, certifications, documentation,
   testing, etc.

All this has a price.

Try to live in a free world if you want to, but be prepared not to get
paid at all.

>   Again it's not the fact you have to meet the guidelines, my issue
>   is with the fees places like (no names mentioned) charge for
>   certificates. I do think they should get paid for work done, but I
>   don't think the current fees are in proportion with the product /
>   service provided...

I think you should have looked a bit more into it, before complaining
:)

> Sorry if I offended anyone,

No offense, really. (We provide EV certificates, among other things,
and everything described above is really done)

-- 
Erwann ABALEA 
Département R&D
KEYNECTIS
11-13 rue René Jacques - 92131 Issy les Moulineaux Cedex - France
Tél.: +33 1 55 64 22 07
http://www.keynectis.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: SHA1 Message Digest Getting Generated less than 160 Bits i.e. 152 bits.

[Dongsheng Song]

On Sat, Sep 25, 2010 at 21:09, Kedar Sabnis  wrote:

>
> HI,
>
> I am an openSSL User. We implemented SHA1 algorithm.
>
> Here in some specific case SHA1 digest is coming as 152 bits long instead
> of 160 bits long.
>
> Please suggest if any bug fix is there for this issue.
>
> Thanking you in anticipation.
>
>
According to *FIPS 180-1*, SHA1 is fixed 160 bit long:
http://www.itl.nist.gov/fipspubs/fip180-1.htm

But you can truncate the 160 bit result to 152 bit as your like.

SHA1 Message Digest Getting Generated less than 160 Bits i.e. 152 bits.

[Kedar Sabnis]

HI,

I am an openSSL User. We implemented SHA1 algorithm.

Here in some specific case SHA1 digest is coming as 152 bits long instead 
of 160 bits long.

Please suggest if any bug fix is there for this issue.

Thanking you in anticipation.

Thanks & Regards,
Kedar Anilrao Sabnis
Tata Consultancy Services
SDF-V  GROUND  Unit No.130/131,SDF-V
Seepz,Andheri(East)
Mumbai - 400096,Maharshtra
India
Mailto: kedar.sab...@tcs.com
Website: http://www.tcs.com

Experience certainty.   IT Services
Business Solutions
Outsourcing

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you