Re: Error (0.9.8n) or segfault (1.0.0d) in s_server/s_client using Kirkwood 88F6281 hardware acceleration

2011-07-11 Thread Coda Highland
On Sun, Jul 10, 2011 at 9:19 PM, Coda Highland chighl...@gmail.com wrote:
 --snip--

 Following up on this:

 I received a reply directing me to try
 http://carnivore.it/2011/04/23/openssl_-_af_alg, so I did. It was
 straightforward to install and test,  but unfortunately the results
 are the same, except it doesn't segfault; I just get the error
 message:

 --snip--
 SSL_accept:SSLv3 read client key exchange A
 SSL3 alert write:fatal:bad record mac
 SSL_accept:error in SSLv3 read certificate verify A
 ERROR
 1074403296:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
 failed or bad record mac:s3_pkt.c:478:
 shutting down SSL
 CONNECTION CLOSED

 This at least narrows it down (it seems unlikely that both
 cryptodev-linux and af_alg have the same bug) but I'm still not sure
 where to start debugging. Perhaps I should be focusing on the kernel
 code for the hardware? Advice would be appreciated.

 /s/ Adam


Following up on THIS: Success!

Markus, the developer for af_alg, suggested that I remove SHA-1
offloading by removing this line from e_af_alg.c:

   !ENGINE_set_digests (e, af_alg_digests))

I wasn't expecting this to work because building OpenSSL without
-DUSE_CRYPTODEV_HASHES didn't solve anything, but to my pleasant
surprise SSL is up and running now with hardware acceleration.

So many thanks to Markus and I hope my findings prove useful for
someone else in the future.

Thanks again!
/s/ Adam
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Need Help: Building crypto libraries to link with Visual C++

2011-07-11 Thread rick freitag
Questions include:

Why do I need ActivePerl not plain Perl?
I am only using the Cryptolibrary functions from Visual C++.


Thanks,

Fred


[openssl.org #2557] Bug in perlasm/cbc.pl with short/partial blocks?

2011-07-11 Thread Wim Lewis via RT
I noticed this odd sequence of instructions in cbc.pl, near line 171. It seems 
like a bug, but the code hasn't been modified since 1998, and it seems unlikely 
this bug would have gone unnoticed for that long[1]:

 set_label(ej3);
 movb(HB(ecx),   BP(2,$in,,0));
 xor(ecx, ecx) if $ppro; # ppro friendly
 shl(ecx,8);


I'm guessing the xor should be before the movb (as it is a few lines earlier in 
a parallel piece of code), not after. As it is, this bug would occur if you 
compile with $ppro=1 and feed the CBC encrypt function with a buffer whose 
length%8==3. The last byte of input would always be read as 0.

I'm not sure the xor is even needed, to be honest (but I don't know much about 
ppro optimization). ECX and EDX are zeroed right before the indirect jump to 
ej3, so wouldn't that already prevent a partial register stall? Or does the 
indirect jump cause the ppro to forget the tag?


[1] On the other hand, looking through earlier bugs like RT#1801, it sounds 
like the higher layers of OpenSSL never pass partial blocks to the CBC code 
anyway, so this bug would only be visible to people who are bypassing the EVP_* 
layer.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Build Error on 1.0.1 with FIPS

2011-07-11 Thread Tyrel Haveman
Hello again,

We've noticed now that while we are able to build the FIPS module for 64-bit
Windows, we cannot for 32-bit Windows. Following these steps:

set FIPSDIR=..\out
perl Configure VC-WIN32
ms\do_ms
nmake -f ms\ntdll.mak

We get this error:
link /nologo /subsystem:console /opt:ref /debug
/out:out32dll\fips_standalone_sha1.exe
@C:\Users\TyrelHa\AppData\Local\Temp\nmC2ED.tmp
sha1dgst.obj : error LNK2019: unresolved external symbol
_fips_sha1_block_data_order referenced in function _fips_sha1_update
out32dll\fips_standalone_sha1.exe : fatal error LNK1120: 1 unresolved
externals
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\BIN\link.EXE' : return code '0x460'
Stop.

I know we should be using do_fips.bat, but it won't let me do a 32-bit build
on a 64-bit platform, so we're using these steps instead.

Any thoughts?

Thanks,
Tyrel

On Thu, Jun 30, 2011 at 4:07 PM, Tyrel Haveman ty...@binarypeople.netwrote:

 Ah, okay. We tried that out and the FIPS module does build great
 afterwards. But then, later, the 1.0.1 fips-capable build fails to
 build with this reasoning:

nasm -f win64 -DNEAR -Ox -g -o tmp32dll\rc4-x86_64.obj
 tmp32dll\rc4-x86_
 64.asm
 tmp32dll\rc4-x86_64.asm:755: error: symbol `L$SEH_begin_RC4_set_key'
 undefined
 tmp32dll\rc4-x86_64.asm:756: error: symbol `L$SEH_end_RC4_set_key'
 undefined
 NMAKE : fatal error U1077: 'C:\devel\crypto\tools\nasm.EXE' : return code
 '0x1'
 Stop.

 On Thu, Jun 30, 2011 at 2:28 PM, Dr. Stephen Henson st...@openssl.org
 wrote:
  On Thu, Jun 30, 2011, Tyrel Haveman wrote:
 
  Thanks Steve, but now it's running into this instead:
   Assembling: tmp32dll\x86_64cpuid.asm
  tmp32dll\x86_64cpuid.asm(9) : error A2008:syntax error : SEGMENT
  tmp32dll\x86_64cpuid.asm(12) : error A2008:syntax error : ENDS
  NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual
  Studio 10.0\VC\BIN\x86_amd64\ml64.EXE' : return code '0x1'
  Stop.
 
  The code at those lines looks like this:
  .data SEGMENT
  COMM  fips_openssl_ia32cap_p:DWORD:2
 
  .data ENDS
 
  I don't know MASM syntax so I'm not sure how to correct this.
 
 
  You have to use NASM for the build and the build process is simply:
 
  ms\do_fips
 
  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
  Development Mailing List   openssl-dev@openssl.org
  Automated List Manager   majord...@openssl.org
 



Re: Error (0.9.8n) or segfault (1.0.0d) in s_server/s_client using Kirkwood 88F6281 hardware acceleration

2011-07-11 Thread Coda Highland
On Mon, Jul 11, 2011 at 11:20 AM, Coda Highland chighl...@gmail.com wrote:
 Following up on THIS: Success!

 Markus, the developer for af_alg, suggested that I remove SHA-1
 offloading by removing this line from e_af_alg.c:

               !ENGINE_set_digests (e, af_alg_digests))

 I wasn't expecting this to work because building OpenSSL without
 -DUSE_CRYPTODEV_HASHES didn't solve anything, but to my pleasant
 surprise SSL is up and running now with hardware acceleration.

 So many thanks to Markus and I hope my findings prove useful for
 someone else in the future.

 Thanks again!
 /s/ Adam

Never mind on the success; it seems that was premature.

I can connect now; that much works fine. But after I transfer
somewhere around 512KB of data over the connection it bombs out with:

DONE
SSL3 alert write:warning:close notify

on the client side and

SSL3 alert read:warning:close notify
DONE
shutting down SSL
CONNECTION CLOSED

on the server side. So clearly there's still some sort of problem. I'm
guessing that there's a renegotiation happening around this time or
something, but I'm back to my original question:

What advice can you give me for how to debug this issue?

/s/ Adam
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Build Error on 1.0.1 with FIPS

2011-07-11 Thread Dr. Stephen Henson
On Mon, Jul 11, 2011, Tyrel Haveman wrote:

 Hello again,
 
 We've noticed now that while we are able to build the FIPS module for 64-bit
 Windows, we cannot for 32-bit Windows. Following these steps:
 
 set FIPSDIR=..\out
 perl Configure VC-WIN32
 ms\do_ms
 nmake -f ms\ntdll.mak
 
 We get this error:
 link /nologo /subsystem:console /opt:ref /debug
 /out:out32dll\fips_standalone_sha1.exe
 @C:\Users\TyrelHa\AppData\Local\Temp\nmC2ED.tmp
 sha1dgst.obj : error LNK2019: unresolved external symbol
 _fips_sha1_block_data_order referenced in function _fips_sha1_update
 out32dll\fips_standalone_sha1.exe : fatal error LNK1120: 1 unresolved
 externals
 NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio
 10.0\VC\BIN\link.EXE' : return code '0x460'
 Stop.
 
 I know we should be using do_fips.bat, but it won't let me do a 32-bit build
 on a 64-bit platform, so we're using these steps instead.
 

The target platform is determined from the environment. Try this before
calling do_fips:

set PROCESSOR_ARCHITECTURE=x86

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
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org