Re: [openssl-users] QNX cross-compiled openssl with fips

[Piotr Łobacz]

Yeah i have tried with it and modified it. But mine problem is that i am
cross-compiling. I have used incore to generate digest and it works with
qcc and i386-pc-nto-qnx6.4.0-gcc. But with i386-pc-nto-qnx6.4.0-g++ and
QCC which is for c++ it does not work it generates bad digest. What is a
problem because i have to use a machine with qnx to run the compiled
code to get the proper digest and than recompile with it, what actually
works because i've tested it.

Dnia 2015-04-02, czw o godzinie 02:34 -0400, Jeffrey Walton pisze:
> On Thu, Apr 2, 2015 at 2:19 AM, Piotr Łobacz  
> wrote:
> > Ok finally my app is working and compiled with c++ compiler but the
> > problem persist because elf incore is bad for QNX apps compiled with g++
> > or QCC compiler. It generates bad digest. Even incore2 generates bad
> > digest, and i dunno why that happens. Any suggestions?
> 
> You might try fipsld++
> (https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B). Its for
> handling C++ compilers.
> 
> I'm not sure why the various symbols are not exported with extern "C".
> 
> I don't recall trying it with a cross compile, though. It may work, it
> may not work. Either way, it may give you some ideas.
> 
> Jeff

-- 


Piotr Łobacz

Biuro Systemów i Oprogramowania

RADMOR S.A.

tel. (58) 6996 929

e-mail: piotr.lob...@radmor.com.pl

www.radmor.com.pl




RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia

NIP: 586-010-21-39

REGON: 190432077

KRS: 074029 (Sąd Rejonowy Gdańsk-Północ w Gdańsku)

Kapitał zakładowy wpłacony: 9 282 830 PLN

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] QNX cross-compiled openssl with fips

[Piotr Łobacz]

Ok finally my app is working and compiled with c++ compiler but the
problem persist because elf incore is bad for QNX apps compiled with g++
or QCC compiler. It generates bad digest. Even incore2 generates bad
digest, and i dunno why that happens. Any sugesstions?

Dnia 2015-03-31, wto o godzinie 12:41 +0200, Piotr Łobacz pisze:
> Ok i have finally managed to cross-compile openssl with fips for QNX
> platform. What i did wass modifing the fipsld script not to input this
> magical number[ $? -ne 42 ] && exit $? and the returned output of
> "${FIPS_SIG}" -exe "${TARGET}" was saved in SIG variable, because this
> line SIG=`"${TARGET}" tried to execute QNX compiled code on linux, what
> is rather impossible, to get the returned digest and recompile the
> target with it. Now with these little changes i was finally able to run
> openssl fips cross compiled app on qnx and i can gladly say that it
> works.
> 
> Dnia 2015-03-27, pią o godzinie 11:04 +0100, Piotr Łobacz pisze:
> > Another problem is that compiled cross-compiled OpenSSL with fips should
> > start in its own prompt but it only spews the expected signature and
> > exits. I have modified fipsld scripts as shown in the manual and this
> > does not help. Incore was used from the tarball but maybe i have to use
> > some special modifications for QNX incore?
> > 
> > Dnia 2015-03-26, czw o godzinie 08:46 +0100, Piotr Łobacz pisze:
> > > Hello,
> > > i have been able to cross-compile openssl with fips module and what i
> > > want now is to use it within my project which is using C++. According to
> > > the manual https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B i have
> > > to modify fipsld to fipsld++. Everything works properly if i'm compiling
> > > my own libraries which are being linked with static crypto.a but if i'm
> > > going to compile some tests which are linking with those libraries i get
> > > this error:
> > > 
> > > /usr/lib/fips_premain.o: In function `FINGERPRINT_premain()':
> > > /usr/lib/fips_premain.c:103: undefined reference to `FIPS_text_start()'
> > > /usr/lib/fips_premain.c:116: undefined reference to
> > > `FIPS_incore_fingerprint(unsigned char*, unsigned int)'
> > > 
> > > According to the manual, problem occurs with C++ linker, but i have it
> > > modified in fipsld++ so that now PREMAIN_DSO looks like:
> > > 
> > > -x c "${PREMAIN_C}" -x none \
> > > 
> > > and this does not help. On Linux with gcc this was helpful but on QNX
> > > cross compilation it does not.
> > > 
> > > I would be pleased if somebody could point me what am i doing wrong...
> > > 
> > 
> 

-- 


Piotr Łobacz

Biuro Systemów i Oprogramowania

RADMOR S.A.

tel. (58) 6996 929

e-mail: piotr.lob...@radmor.com.pl

www.radmor.com.pl




RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia

NIP: 586-010-21-39

REGON: 190432077

KRS: 074029 (Sąd Rejonowy Gdańsk-Północ w Gdańsku)

Kapitał zakładowy wpłacony: 9 282 830 PLN

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Is it mandatory to reverse windows signature while doing verification in OpenSSL?

[Rishabh K Dubey]

Thanks Tom for Quick response.

Regards,
Rishabh

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Tom 
Francis
Sent: Wednesday, April 01, 2015 7:17 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Is it mandatory to reverse windows signature while 
doing verification in OpenSSL?

If you mean you’re using CryptSignHash(), and are reversing the bytes in the 
resulting signature, then yes, this is normal.  You’ll need to reverse the 
bytes when verifying the signature with ANY other toolkit/library, including 
CNG. :)  If it’s not too late, you should store the signature with the bytes 
reversed, and then reverse the bytes when you want to verify the signature with 
CryptVerifySignature(), so that nothing else needs to reverse the bytes.  If 
you later switch from CryptoAPI to CNG, then you’ll be able to remove the byte 
reversing code, since CNG uses the same byte order as OpenSSL.

CryptoAPI tends to put all large integer data in least significant byte first 
order (probably because somebody was accustomed to little endian on x86?).  
Every other library I’ve used does the opposite, so I strongly recommend any 
storage be different from what CryptoAPI produces/expects unless your main 
intent is to work only with CryptoAPI.

TOM


> On Apr 1, 2015, at 2:12 AM, Rishabh K Dubey  wrote:
> 
> Dear,
> 
>  
> 
> We have signed data on Win 7 using Crypto APIs and generated signature. We 
> have observed this such reversing of signature bytes is valid operation or 
> not. Thanks in advance.
> 
>  
> 
> Regards,
> 
> Rishabh
> 
> 
> ~~Disclaimer~~~
> Information contained and transmitted by this e-mail is confidential and 
> proprietary to IGATE and its affiliates and is intended for use only by the 
> recipient. If you are not the intended recipient, you are hereby notified 
> that any dissemination, distribution, copying or use of this e-mail is 
> strictly prohibited and you are requested to delete this e-mail immediately 
> and notify the originator or mailad...@igate.com. IGATE does not enter into 
> any agreement with any party by e-mail. Any views expressed by an individual 
> do not necessarily reflect the view of IGATE. IGATE is not responsible for 
> the consequences of any actions taken on the basis of information provided, 
> through this email. The contents of an attachment to this e-mail may contain 
> software viruses, which could damage your own computer system. While IGATE 
> has taken every reasonable precaution to minimise this risk, we cannot accept 
> liability for any damage which you sustain as a result of software viruses. 
> You should carry out your own virus checks before opening an attachment. To 
> know more about IGATE please visit www.igate.com.
> 
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

~~Disclaimer~~~
Information contained and transmitted by this e-mail is confidential and 
proprietary to IGATE and its affiliates and is intended for use only by the 
recipient. If you are not the intended recipient, you are hereby notified that 
any dissemination, distribution, copying or use of this e-mail is strictly 
prohibited and you are requested to delete this e-mail immediately and notify 
the originator or mailad...@igate.com . IGATE does 
not enter into any agreement with any party by e-mail. Any views expressed by 
an individual do not necessarily reflect the view of IGATE. IGATE is not 
responsible for the consequences of any actions taken on the basis of 
information provided, through this email. The contents of an attachment to this 
e-mail may contain software viruses, which could damage your own computer 
system. While IGATE has taken every reasonable precaution to minimise this 
risk, we cannot accept liability for any damage which you sustain as a result 
of software viruses. You should carry out your own virus checks before opening 
an attachment. To know more about IGATE please visit www.igate.com 
.

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS errors: finding causes for failure

[Dr. Stephen Henson]

On Wed, Apr 01, 2015, jonetsu wrote:

> Hello,
> 
>   As part of development, still using the fips_hmac test code, this time on a 
> target unit using 1.0.1e, the following errors are shown at the console:
> 
> 3069614096:error:2D088086:FIPS
> routines:FIPS_selftest_x931:selftest
> failed:fips_rand_selftest.c:171:
> 
> 3069614096:error:2D082086:FIPS
> routines:FIPS_selftest_cmac:selftest
> failed:fips_cmac_selftest.c:178:
> 
> 3069614096:error:2D080086:FIPS
> routines:FIPS_selftest_aes:selftest
> failed:fips_aes_selftest.c:97:
> 
> 3069614096:error:2D090086:FIPS
> routines:FIPS_selftest_aes_xts:selftest
> failed:fips_aes_selftest.c:383:
> 
> 3069614096:error:2D083086:FIPS
> routines:FIPS_selftest_des:selftest
> failed:fips_des_selftest.c:102:
> 
> What is the troubleshooting path from here ?  Is it only by going to the 
> appropriate code line ?  In the first case, the FIPS_selftest_x931() is 
> concerned, with the 171 line being: 
> FIPSerr(FIPS_F_FIPS_SELFTEST_X931,FIPS_R_SELFTEST_FAILED).  Which basically 
> means that the actual test code has to be examined. There is documentation in 
> the User Guide, section 6.3.1, although it does not seem to be practical to 
> find out the cause of the failure.  There are seemingly no log messages 
> generated.  Information that would give hints as to why a specific test could 
> fail would be useful.  In this case, there's mention of the V seed value 
> being corrupted but only for simulation mode.
> 
> In short, how to find what could be the cause(s) of FIPS test(s) failure(s) ?
> 

Does fips_test_suite from the FIPS module produce similar errors?

Most tests are known answer tests (KAT). That is they pass known inputs to
the algorithm and check to see if the output matches the expected value. As
such the only reason a self test could fail is that the algorithm is
misbehaving: the most common reason for that is a compiler bug.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] FIPS errors: finding causes for failure

[jonetsu]

Hello,

  As part of development, still using the fips_hmac test code, this time on a 
target unit using 1.0.1e, the following errors are shown at the console:

3069614096:error:2D088086:FIPS
routines:FIPS_selftest_x931:selftest
failed:fips_rand_selftest.c:171:

3069614096:error:2D082086:FIPS
routines:FIPS_selftest_cmac:selftest
failed:fips_cmac_selftest.c:178:

3069614096:error:2D080086:FIPS
routines:FIPS_selftest_aes:selftest
failed:fips_aes_selftest.c:97:

3069614096:error:2D090086:FIPS
routines:FIPS_selftest_aes_xts:selftest
failed:fips_aes_selftest.c:383:

3069614096:error:2D083086:FIPS
routines:FIPS_selftest_des:selftest
failed:fips_des_selftest.c:102:

What is the troubleshooting path from here ?  Is it only by going to the 
appropriate code line ?  In the first case, the FIPS_selftest_x931() is 
concerned, with the 171 line being: 
FIPSerr(FIPS_F_FIPS_SELFTEST_X931,FIPS_R_SELFTEST_FAILED).  Which basically 
means that the actual test code has to be examined. There is documentation in 
the User Guide, section 6.3.1, although it does not seem to be practical to 
find out the cause of the failure.  There are seemingly no log messages 
generated.  Information that would give hints as to why a specific test could 
fail would be useful.  In this case, there's mention of the V seed value being 
corrupted but only for simulation mode.

In short, how to find what could be the cause(s) of FIPS test(s) failure(s) ?

Regards.


___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Is it mandatory to reverse windows signature while doing verification in OpenSSL?

[Tom Francis]

If you mean you’re using CryptSignHash(), and are reversing the bytes in the 
resulting signature, then yes, this is normal.  You’ll need to reverse the 
bytes when verifying the signature with ANY other toolkit/library, including 
CNG. :)  If it’s not too late, you should store the signature with the bytes 
reversed, and then reverse the bytes when you want to verify the signature with 
CryptVerifySignature(), so that nothing else needs to reverse the bytes.  If 
you later switch from CryptoAPI to CNG, then you’ll be able to remove the byte 
reversing code, since CNG uses the same byte order as OpenSSL.

CryptoAPI tends to put all large integer data in least significant byte first 
order (probably because somebody was accustomed to little endian on x86?).  
Every other library I’ve used does the opposite, so I strongly recommend any 
storage be different from what CryptoAPI produces/expects unless your main 
intent is to work only with CryptoAPI.

TOM


> On Apr 1, 2015, at 2:12 AM, Rishabh K Dubey  wrote:
> 
> Dear,
> 
>  
> 
> We have signed data on Win 7 using Crypto APIs and generated signature. We 
> have observed this such reversing of signature bytes is valid operation or 
> not. Thanks in advance.
> 
>  
> 
> Regards,
> 
> Rishabh
> 
> 
> ~~Disclaimer~~~
> Information contained and transmitted by this e-mail is confidential and 
> proprietary to IGATE and its affiliates and is intended for use only by the 
> recipient. If you are not the intended recipient, you are hereby notified 
> that any dissemination, distribution, copying or use of this e-mail is 
> strictly prohibited and you are requested to delete this e-mail immediately 
> and notify the originator or mailad...@igate.com. IGATE does not enter into 
> any agreement with any party by e-mail. Any views expressed by an individual 
> do not necessarily reflect the view of IGATE. IGATE is not responsible for 
> the consequences of any actions taken on the basis of information provided, 
> through this email. The contents of an attachment to this e-mail may contain 
> software viruses, which could damage your own computer system. While IGATE 
> has taken every reasonable precaution to minimise this risk, we cannot accept 
> liability for any damage which you sustain as a result of software viruses. 
> You should carry out your own virus checks before opening an attachment. To 
> know more about IGATE please visit www.igate.com.
> 
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users