Hi, In fact, if you get connected sometimes does not mean that there is no enc/dec problem, because it can be due to block size (for stream), padding (for CBC mode), or things like this... ;( Be carefull with network, because using a crypto accelerator involves performances (RSA bottleneck removing), so you may have network load. The delay in the ENGINE implementation should not impact SSL handshake as the handshake is sequential (no asynchronous task). Have a look to RSA_BLINDING flag which can imply a double RSA calculation.
I suggest you to: - test your DES implementation with the DES test provided in openssl test directory (you can also test MD5 and SHA1 if i remember well) - just add the ciphering alg and test before adding hash ones. Moreover we find that hashing on the board reduces performances. Hope it could help. Fred PS: if can send me your engine code or some debug ouput (where it hangs..etc..) -----Original Message----- From: [EMAIL PROTECTED] on behalf of Riaz Rahaman Sent: Mon 2/21/2005 12:23 PM To: openssl-users@openssl.org Cc: Subject: Re: ENGINE implementaion done but facing errors Hi Fred, Thanks for the reply....I was assuming that my mails were not being delivered to the group. I am not able to find the bug as some times the s_cleint gets connected with out any problem and some times it gives errors. If there is a bug with enc or dec functionality then it should never get connected. Possibility of network error is ruled out, as I try the same s_client with software implementation and there are no problems at all. My engine implementation provides DES, CBC, EDE etc modes + RSA, SHA, MD5 and RAND. I have found a peculiar behaviour when I use printf to debug my functionality the engine works quite stable not 100% though. I suspect it to be a delay required at some point, but am not able to find where can the problem be by seeing the error commands when using the s_client. Do you have any suggestions as how to go about using it? How did you fix the issue for NSCrypto board? On Thu, 17 Feb 2005 12:05:27 +0100, Frédéric Donnat <[EMAIL PROTECTED]> wrote: > Hi, > > Just take a look at man engine.. ;) > > We already encouter this probleme when implementing our one ENGINE for our > NSCrypto board, especially xhen adding symmetric ciphering.. > > The error you describe "could" comes from a bad symmetric enc/dec. > A "bad mac record with READ" sounds like openssl decrypt the data, but does > not found that the MAC is ok ==> this could mean that the decryption is not > correct, but this can also comes from the network. > > Could you tell more about what functionnalities your ENGINE provides? > > regards, > > Fred > > -----Original Message----- > From: [EMAIL PROTECTED] on behalf of Riaz Rahaman > Sent: Wed 2/16/2005 9:07 AM > To: openssl-users@openssl.org > Cc: > Subject: ENGINE implementaion done but facing errors > Hi, > I am trying to connect using s_client, it works fine > for a couple of hours and after that I keep getting this error > message. > > ========================================================= > $ openssl s_client -ssl3 -connect IP_NUMBER:PORT(443) > CONNECTED(00000003) > depth=0 /CN=XYZ 7FDA7830/O=XYZ Co./OU=000E7FDA7830/OU=AS961A > 3REJ7961A > verify error:num=18:self signed certificate > verify return:1 > depth=0 /CN=XYZ 7FDA7830/O=XYZ /OU=000E7FDA7830/OU=AS961A > 3REJ7 > verify return:1 > 1608:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad > record mac:s3_pkt.c:1031:SSL alert number 20 > 1608:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake > failure:s3_pkt.c:514: > ========================================================= > > I am using the hardware engine. I had sent a mail sometime back asking > why the engine is not getting enabled by default. Well I did manage to > get a solution. > When using the engine from application point of view, you do require > to set the default engine from the application code, but when your > engine has to come up > and be set as default, then you have to set your engine functions as > default by using the API ENGINE_set_default_RSA(ENGINE *e) and the > same goes for all > the functions that are to be done using the hardware. This is mainly > intended for stand alone applications. Also even before the openssl > comes up, you have to call the ENGINE_load_builtin_engines which > initializes the engine tables with the available engines and during > this phase when you make a call to the bind_helper you have to set > which engine is going to be your default implementation after binding > the function pointers through the API ENGINE_set_default_RSA or what > ever you need to set as default. The reason for calling the > ENGINE_load_builtin_engines before your openssl comes up is, because, > when you don't initialize your engine and set it as default, the > openssl code takes the software implementation as default. So it is as > safe implementation if you can do that in the start. > Hope the above info helps. And some one please advice me about the > above error... > > -- > Thank you, > Best Regards > Riaz Ur Rahaman > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > > > -- Thank you, Best Regards Riaz Ur Rahaman ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
<<winmail.dat>>
