[openssl.org #782] IBM patches to OpenSSL-0.9.7c

Hi. Richard, Saw your email. Is it possible for you to send the ibm.patches to us. Would appreciate it greatly Dave Coleman AirZip, Inc. 10051B Pasadena Avenue Cupertino, CA 95014 408 446 4111 Ext 360 650-280-3366 mobile [EMAIL PROTECTED] AirZip Fax 408 446 4141 AirZipTech Support 408 446 41

[openssl.org #789] OpenSSL's crypto support for crippled keys

[EMAIL PROTECTED] - Tue Dec 9 20:56:58 2003]: > Steve, thanks for you answer. > Unfortunately, the crippled PKCS#1 key encoding that I produced > contained > the primes and CRT components of 1 byte in length and a value of 0 in > order to circumvent an error condition in the OpenSSL's key > con

Re: [openssl.org #789] OpenSSL's crypto support for crippled keys

Steve, thanks for you answer. Unfortunately, the crippled PKCS#1 key encoding that I produced contained the primes and CRT components of 1 byte in length and a value of 0 in order to circumvent an error condition in the OpenSSL's key conversion/importing routines (the d2i_RSAPrivateKey, I beli

Re: [openssl.org #785] AutoReply: bug in RSA blinding code [WAS: Re: Seg fault in BN_mod_exp]

About a week ago I submitted the report below. Has any developer plans to look into this? Kind regards, Paul > - > I've tracked down the problem. It is in the RSA blinding code, because > RSA_blinding_off(rsa) after the RSA

Re: [openssl.org #748] bug in speed.c

Hello Lutz, seems to be I find answer :) "type/block size" in "openssl speed" is just buffer size for calling cbc routines. and "block size" is fixed for different algorithms (as 8 bytes for DES). but now I don't clear about "type". Is it simply "input data size" and can be not only 16,64,256,1024

Re: [openssl.org #748] bug in speed.c

Hello Lutz, Last month I try find answer for: What block (I mean what are long the block) is "standard" for cbc's like des/idea/aes and using in SSH/SSL and other "well known" applications? "openssl speed" dive me too many results and I want to choose major. Can You help me? -- Best regards,

Re: [openssl.org #788] AutoReply: [PATCH] up to 1.4x RSA throughput using SSE2

On Tue, 9 Dec 2003, Nils Larsch via RT wrote: > Wouldn't it be better to include the call to the run-time detection > function in a global init function (like OpenSSL_add_all_algorithm) > instead of including it in BN_new & BN_init ? yeah that would be better :) assuming everyone has to call th

Re: [openssl.org #788] [PATCH] up to 1.4x RSA throughput using SSE2

On Tue, 9 Dec 2003, Andy Polyakov wrote: > appears appropriate under this ABI. But keep in mind that OpenSSL is not > exclusively about Linux and we have to think of a common denominator oh don't worry -- those ELF ABI calling conventions are used on all x86 unix (and are essentially the same if

Re: [VOTE] SHA1 IA-32 assembler tune-up

On Tuesday 09 December 2003 08:28, Andy Polyakov wrote: > This is a poll for votes. > > It was noted that [at least] Intel IA-32 compiler, linux-ia32-icc > target, generates *noticeably*, 30% to be specific, faster code for SHA1 > than hand-coded assembler implementation on at least P4 platform. I

[openssl.org #789] OpenSSL's crypto support for crippled keys

[EMAIL PROTECTED] - Tue Dec 9 14:51:37 2003]: > Hello: > Actually, this is more of a question than a request for enhancement. > Does > OpenSSL's crypto support crippled PKCS#1 encoded private keys? > Crippled PKCS#1 encoded keys are keys that don't have all the PKCS#1 > components. I have keys

Re: [VOTE] SHA1 IA-32 assembler tune-up

In message <[EMAIL PROTECTED]> on Tue, 09 Dec 2003 14:28:23 +0100, Andy Polyakov <[EMAIL PROTECTED]> said: appro> This is a poll for votes. appro> appro> It was noted that [at least] Intel IA-32 compiler, linux-ia32-icc appro> target, generates *noticeably*, 30% to be specific, faster code for S

[openssl.org #791] CBC padding patch for FIPS-81

The attached patch allows for the FIPS-81 padding scheme to be permitted on decryption of a symmetric cipher. New padding modes are defined in evp.h, and can be set using EVP_CIPHER_CTX_set_padding(). FIPS-81 allows for random bytes in between the last byte of plaintext and the last byte of the

[openssl.org #790] [patch] support shared library on oler version of AIX4

type of request:patch operationg system: IBM AIX4 version of OpenSSL: 0.9.7c I apply following patch to complie OpenSSL 0.9.7c on AIX4. (1) `cc -G' is not support at C for AIX version 4. (2) `ld -G' (to use runtime linker) is not support at AIX4.1, AIX3.2. -

[openssl.org #789] OpenSSL's crypto support for crippled keys

Hello: Actually, this is more of a question than a request for enhancement. Does OpenSSL's crypto support crippled PKCS#1 encoded private keys? Crippled PKCS#1 encoded keys are keys that don't have all the PKCS#1 components. I have keys that contain only the modulus, and the public and the pr

[VOTE] SHA1 IA-32 assembler tune-up

This is a poll for votes. It was noted that [at least] Intel IA-32 compiler, linux-ia32-icc target, generates *noticeably*, 30% to be specific, faster code for SHA1 than hand-coded assembler implementation on at least P4 platform. I have re-tuned SHA1 assembler implementation which now performs as

Re: [openssl.org #788] [PATCH] up to 1.4x RSA throughput using SSE2

> [note -- i changed the cc to rt because there's something preventing me > from posting to openssl-dev... and rt seems to be one way for me to get my > messages through.] And my yesterday reply didn't appear in RT... > > "- Transition from x87 FPU to MMX technology instructions or to SSE or >

Re: [openssl.org #788] AutoReply: [PATCH] up to 1.4x RSA throughput using SSE2

Hi Dean, [EMAIL PROTECTED] via RT wrote: > i've added a second patch > -- the > second patch includes run-time detection of SSE2 and selects between two > implementations of bn_mul_add_words so that it can be used in a general >