[openssl.org #1453]

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

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

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

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

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

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 

Cavium TurboSSL type of optimizations

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

[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

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