via RT | 4 Jan 08:19 2007
Picon

[openssl.org #1453]


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Gisle Vanem | 4 Jan 16:57 2007
Picon

ccgost on DOS

There is a problem building OpenSSL on a 8+3 filesystem like
DOS due to the files:
 engines/ccgost/gost2001.c
 engines/ccgost/gost2001_keyx.c

The latter overwrites the first using djgpp's tar. Could you please
rename them to something like:
 engines/ccgost/gost01.c
 engines/ccgost/gost01_keyx.c

so they become 8+3 unique?

Gisle V.

# rm /bin/laden 
/bin/laden: Not found 
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Victor B. Wagner | 4 Jan 19:58 2007
Picon

Re: ccgost on DOS

On 2007.01.04 at 16:57:35 +0100, Gisle Vanem wrote:

> There is a problem building OpenSSL on a 8+3 filesystem like
> DOS due to the files:
> engines/ccgost/gost2001.c
> engines/ccgost/gost2001_keyx.c

Sorry, when I named files I haven't thought than anybody still use real
DOS with no long names support of some sort as development platform.
Personally I use linux-hosted cross-compiler when I need to compile
something for DJGPP platform.

It'll be interesting to see if ccgost engine can work at all under DOS -
we never intended it to be used on the platform without dynamic loading,
and OpenSSL doesn't support dynamic loading, available in DJGPP 2.04.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Andy Polyakov | 5 Jan 00:06 2007
Picon
Picon

linux-arm hardware

Guys,

I've written some ARM assembler and would like to benchmark it. So if 
anybody on the list has access to linux-arm hardware, please contact me 
for instructions. A lot of thanks in advance. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Andy Polyakov | 5 Jan 00:09 2007
Picon
Picon

Re: Make PadLock engine dynamic

Engine is moved to ./engine in HEAD, but in 098 I've chosen more 
conservative eng_all.c-only patch. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Andy Polyakov | 5 Jan 00:22 2007
Picon
Picon

Re: [openssl.org #1447] [bug] 0.9.8d: rc4 cpuid test broken on dual core cpus

> there is a cpuid test in rc4_skey.c which tests the hyperthreading cpuid 
> bit to distinguish between two implementations of rc4... unfortunately 
> this fails to properly distinguish the cpus.  all dual core cpus (intel or 
> amd) report HT support even if they don't use symmetric-multithreading 
> like some p4 do.

So HT flag is no longer HyperThreading, but something else... Will look 
into it... There is another place HTT flag is checked and it's AES...

> it seems somewhat fortunate that core2 CPUs track the p4 behaviour
> w.r.t. these two rc4 implementations.  here are the core2 results with the
> stock code / HT test:
> 
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
> rc4             166799.58k   180552.87k   182437.93k   183381.67k   183206.87k
> 
> and with cpuid test disabled:
> 
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
> rc4             123361.30k   128102.17k   129876.57k   128787.22k   129419.95k
> 
> for the record, core2 64-bit code seriously underperforming the 32-bit
> code...  here's the 32-bit results (with cpuid test enabled):
> 
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
> rc4             254164.64k   279901.10k   279364.38k   283617.62k   276690.26k

... The key feature in 32-bit code with cpuid test is that corresponding 
loop is not unrolled. Can you test following in *64-bit* build on Core2 
hardware. Open rc4-x86_64.pl in text editor and make jump to .Lcloop1 at 
(Continue reading)

Elwin Stelzer Eliazer | 5 Jan 00:58 2007
Picon

Cavium TurboSSL type of optimizations

Hi,

I am experimenting with a CAVIUM SSL hardware accelerator, and there seems to be two ways to use the hardware.
One option is through OpenSSL Engine interface. The other option is by using their proprietary TurboSSL library, which appears to be a port of OpenSSL.
I do see more work involved in porting our apps on to TurboSSL, but some of the optimizations they have done seem to be very effective.
I would like to know if OpenSSL will have any of these types of optimizations in the next releases?

Thanks.

cheers,
Elwin.


dean gaudet | 5 Jan 08:21 2007

Re: [openssl.org #1447] [bug] 0.9.8d: rc4 cpuid test broken on dual core cpus

On Fri, 5 Jan 2007, Andy Polyakov wrote:

> > there is a cpuid test in rc4_skey.c which tests the hyperthreading cpuid bit
> > to distinguish between two implementations of rc4... unfortunately this
> > fails to properly distinguish the cpus.  all dual core cpus (intel or amd)
> > report HT support even if they don't use symmetric-multithreading like some
> > p4 do.
> 
> So HT flag is no longer HyperThreading, but something else... Will look into
> it... There is another place HTT flag is checked and it's AES...

yeah HT flag now basically means "multi-threading or multi-core
package"... because when amd/intel went dual core they didn't want silly
license managers to charge for every core.

hmm i don't see any OPENSSL_ia32cap_P test for AES in 0.9.8d ... maybe
i should be looking at the cvs?  i'm seeing 17.5 cycles per byte for
aes-128-cbc on core2, which is pretty good.

> > it seems somewhat fortunate that core2 CPUs track the p4 behaviour
> > w.r.t. these two rc4 implementations.  here are the core2 results with the
> > stock code / HT test:
> > 
> > type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> > bytes
> > rc4             166799.58k   180552.87k   182437.93k   183381.67k
> > 183206.87k
> > 
> > and with cpuid test disabled:
> > 
> > type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> > bytes
> > rc4             123361.30k   128102.17k   129876.57k   128787.22k
> > 129419.95k
> > 
> > for the record, core2 64-bit code seriously underperforming the 32-bit
> > code...  here's the 32-bit results (with cpuid test enabled):
> > 
> > type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> > bytes
> > rc4             254164.64k   279901.10k   279364.38k   283617.62k
> > 276690.26k
> 
> ... The key feature in 32-bit code with cpuid test is that corresponding loop
> is not unrolled. Can you test following in *64-bit* build on Core2 hardware.
> Open rc4-x86_64.pl in text editor and make jump to .Lcloop1 at line 154
> unconditional, i.e. replace jz to jmp. make, benchmark and report back. A.

small improvement...

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
rc4             174197.47k   182564.34k   184536.23k   185292.63k   186258.77k

i think this hints that the problem with the unrolled code is the manual
load/store alias avoidance -- there's fancy new hardware in core2 for
dealing with this (obviously it's not fancy enough :)... and it seems
the 32-bit code pushes the alias problem onto the hardware.

oh and i tried using cmove with no luck either.

bizarre... i think i copied the 32-bit code into the 64-bit Lcloop1 case 
and it's still not performing like it does in 32-bit... maybe i screwed up 
though.

-dean
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Annie Yousar via RT | 5 Jan 10:32 2007
Picon

[openssl.org #1454] RSA key exponents different from 3 and F4


Dear all,
Bleichenbacher's attack shows that it was possible to forge a PKCS #1
v1.5 signature signed by a key using exponent 3.

Unfortunately the implementation of the OpenSSL command
	openssl genrsa ...
allows only to create keys with exponent 3 or F4. Nevertheless the new
RSA key generation routine RSA_generate_key_ex available in 0.9.8 works
already with arbitrary exponents.

The included minor patch of apps/genrsa.c adds a new option for exponent
selection to the genrsa command.

Because OpenSSL version 0.9.7 doesn't use RSA_generate_key_ex with
exponents BIGNUM but unsigned long, this patch is applicable to version
0.9.8++ only.

Regards,
Ann

--
    Annie Yousar at egbg dot de

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Dr. Stephen Henson | 5 Jan 14:35 2007
Picon

Re: linux-arm hardware

On Fri, Jan 05, 2007, Andy Polyakov wrote:

> Guys,
> 
> I've written some ARM assembler and would like to benchmark it. So if 
> anybody on the list has access to linux-arm hardware, please contact me 
> for instructions. A lot of thanks in advance. A.

I know someone: me. I have access to a XScale IXP420 if it helps.

I also have a mibile phone with an OMAP 750 but that's a bit awkward to use.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org


Gmane