OpenSSL 1.0.0 on UnixWare 7.1.4

[Tim Rice]

On UnixWare 7.1.4

.
cc -DMONOLITH -I.. -I../include  -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS 
-Kthread -DDSO_DLFCN -DHAVE_DLFCN_H -Kpentium_pro -D__i386__ -O -DFILIO_H 
-Kalloca -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM -c 
ocsp.c
UX:acomp: ERROR: "ocsp.c", line 1268: incomplete struct/union/enum timeval: tv
UX:acomp: ERROR: "ocsp.c", line 1294: undefined struct/union member: tv_usec
UX:acomp: WARNING: "ocsp.c", line 1295: improper member use: tv_sec
UX:acomp: ERROR: "ocsp.c", line 1316: undefined struct/union member: tv_usec
UX:acomp: WARNING: "ocsp.c", line 1317: improper member use: tv_sec
*** Error code 1 (bu21)
.

The struct timeval is found in sys/time.h on this platform.
In the 1.0.0 version of apps/ocsp.c the USE_SOCKETS define has been
removed so sys/time.h is not included from e_os.h as it was in 0.9.8.

Here is one possible fix
.
--- apps/ocsp.c.old 2009-02-06 08:43:52.0 -0800
+++ apps/ocsp.c 2009-04-01 22:04:40.722240006 -0700
@@ -66,6 +66,7 @@
 #include 
 #include 
 #include 
+#include  /* needed for struct timeval */
 #include "apps.h" /* needs to be included before the openssl headers! */
 #include 
 #include 
.

-- 
Tim RiceMultitalents(707) 887-1469
t...@multitalents.net


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

Re: OpenSSL v1.0 and API/ABI compatibily.

[Geoff Thorpe]

Fair comment, I'll respond to this as best I can, but this is not any 
kind of official statement.

On Wednesday 01 April 2009 14:01:18 Kurt Roeckx wrote:
> Hi,
>
> I was under the impression that for the 1.0 version you would
> change the API so that the ABI doesn't break all the time, and
> I see no changed related to that.

No, and please don't expect it to happen for v1.0. I speak only for 
myself, the others can agree/disagree as they please, but I think ABI 
compatibility is a fairly unrealistic dream when you take into account 
the SSLeay and OpenSSL legacy interfaces, current release management 
mechanisms, and community expectations (specifically souce 
compatibility, and in the case of stable-releases, even 
binary/shared-lib compatibility).

The problem is circular - to get to ABI compatibility (and other 
desirable but far-away goals) would first require a large number of 
significant breaks in API compatibility. Resistance to the latter has 
historically been more evident, and certainly more immediate, than 
support for the former.

However, we have been mulling over a new way of managing versions that 
would allow openssl to deliberately engage in API breakages across major 
releases (in ways that can be tracked, and which allow dependent 
libs/apps to prepare, etc), and to hopefully combine this with a more 
orderly/predictable release time-frame. The idea then is that working 
towards goals like ABI-stability would be possible in iterations that 
explicitly "break" certain legacy interfaces and behaviours, but do so 
in a clearly-defined manner. There would also be appropriate assurances 
for continued support of prior versions + adequate lead times to prepare 
for interface changes prior to major releases. The whole point is that 
there are types of progress we can't make by purely incremental and 
backwards-compatible steps, so this would be an attempt to address that 
without raising the ire of disgruntled users.

But as for 1.0, the real issue there is that it has been baking for far 
too long, it is now neary 4 years since the last stable branch was cut 
(0.9.8) and the accumulated changes in the development head are overdue 
for a stable release branch of their own. In fact, the changes are quite 
wide-ranging even if they're mostly "under the covers", so v1.0 it will 
be. I believe/hope we will follow that up with improved process for 
subsequent releases in order to make more meaningful progress on the 
sort of significant issues/goals you hint at. The 0.9s have been 
incubating for ages now with a fairly strong "maintenance" focus, so 
even if the 1.0 release is not unlike another 0.9 release, the hope is 
that it marks a change towards an iterative process more focussed 
on "progress".

At least that's my take on things. :-)

Cheers,
Geoff

-- 
Un terrien, c'est un singe avec des clefs de char...
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH] Fix RSA blinding locking hole

[Geoff Thorpe]

OK, I've taken a look at this, and scratched my head a little. It's a 
touch complicated by the fact that thread-ids have changed in the head 
of development relative to what you're looking at in 0.9.8. But I'm now 
wondering if you haven't misunderstood the nature of openssl's threading 
support;

On Tuesday 31 March 2009 04:52:19 Marc Haisenko wrote:
> Hi folks,
> last week I described a problem with RSA blinding and its locking[1].
> Coincidentally another user ran into the same problem in a totally
> different scenario, the work-around of disabling the blinding fixed
> the issue for him[2].
>
> So here's a patch to fix this issue.
>
> The issue is that the rsa_get_blinding method checks whether there is
> concurrent access to the blinding and tells its caller whether locking
> needs to be done. The check is done by comparing thread/process IDs.
> If they differ locking needs to be done. The problem is that locking
> is not done if the IDs are same. It is assumed that the creator
> doesn't need to do locking which is correct for a single-threaded
> application but is wrong in a multi- threaded/processed environment
> once another process has accessed the blinding.

We need to separate multi-threading from multi-processing here. Once 
you've forked, there should be no locking relationship whatsoever 
between processes, irrespective of any threads (and thread-ids) within 
those processes. Do you have some reason to believe this isn't the case? 
The fork has essentially duplicated the process and created isolation 
between the two (copy-on-write or otherwise). So our only concern 
*should* be between threads within the same process.

So ... multi-threading. My understanding of the RSA blinding (which I 
didn't write) is that rsa->blinding is lazy-initialised by whichever 
thread gets to it first. The call to RSA_setup_blinding() creates the 
blinding struct and tags it with the current thread-id. Subsequent 
accesses to RSA blinding will use rsa->blinding if and only if the 
caller is the thread that lazy-initialised it (ipso facto, if processing 
of a given RSA struct is always in one thread - this is optimal). 
Accesses to RSA blinding from other threads should use rsa->mt_blinding 
(which is lazy-initialised by the first such thread) and this places 
obligations on the caller - ie. do your own locking, don't use a common 
blinding factor, etc.

This should work. I'm wondering if I understood what you meant by "The 
problem is that locking is not done if the IDs are same." ... If the IDs 
are the same, that means you're in the same thread, period!! If that's 
not the case, then the problem is that your thread-id callback isn't set 
up correctly. For threading support to work correctly, you need to 
provide hooks in order to make openssl compatible with your thread model 
(pthreads or otherwise). For 0.9.8, the APIs include;

void CRYPTO_set_locking_callback(void (*func)(int mode,int type,
  const char *file,int line));
void CRYPTO_set_id_callback(unsigned long (*func)(void));

Locking callbacks default to nops, and id callbacks default to different 
things depending on platform, but one possibility is "&errno" (ie. the 
address of the errno var, in the hopes that it's thread-local) and 
another is getpid() (ie. in the hopes that the threads have distinct 
pids too). It may be that the default behaviour is degenerating on your 
platform and not correctly differentiating between threads.

>
> As a fix I've introduced a new flag for struct rsa_st,
> RSA_FLAG_BLINDING_NEEDS_LOCKING. Once it has been noticed that locking
> has to be done the flag is set and from then on we always do locking,
> whether we are the creator or not.
>
> However, I'm scratching my head why this fixes the issue given the
> fact that there are actually two blindings: one when doing no locking
> (rsa->blinding) and another one when doing locking (rsa->mt_blinding).
> Yet our load test indicates that this really does fix the issue:
> without it we get about a dozen Bad Record MAC per day due to the
> blinding. Since I've implemented the attached patch none has occured
> (which is about 1.5 days of load test now).

As before, the thread detection ('id_callback') might be failing you such 
that all threads appear to be "the same thread"? Try calling 
CRYPTO_thread_id() from different threads in the same process and see 
whether they return the same value. This might explain why you "fixed" 
the problem by locking all callers even when they all have the same 
thread ID...

Cheers,
Geoff

-- 
Un terrien, c'est un singe avec des clefs de char...
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL v1.0 and API/ABI compatibily.

[Kurt Roeckx]

Hi,

I was under the impression that for the 1.0 version you would
change the API so that the ABI doesn't break all the time, and
I see no changed related to that.

The problem is all the structs in the public headers.  Any time
you change anything in them you break the ABI, and your
application might break.  Turning on/off some compile time options
also changes those structs.

The solution would be to remove all, or atleast most, of those
structs from the public headers and move them to private headers.
Applications should not know the layout of the structures.  This
would also mean that you need to have functions for everything
people might want to set in those structs, or read from them.

I think 1.0 would be a perfect time to make such changes.  This
will prevent software from building, but it should be easy to
fix the software.


Kurt

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

Re: [PATCH] Fix RSA blinding locking hole

[Geoff Thorpe]

On Wednesday 01 April 2009 04:48:01 Marc Haisenko wrote:
> Forgive my frustration, but which god do I need to sacrifice to to get
> some attention ? Even a "go away, we don't care" would be OK...

I have your email tagged for attention, but haven't had a good enough 
moment to look at it. But please go ahead and sacrifice any god that 
pleases you, it'll give you something to do while I try to take a look 
at this, and it will no doubt amuse any passers-by. :-)

Cheers,
Geoff

-- 
Un terrien, c'est un singe avec des clefs de char...
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH] Fix RSA blinding locking hole

[Marsh Ray]

Marc Haisenko wrote:

...  Maybe it would be a good idea to document that on the openssl.org
homepage, because before I submitted my patch I was searching the site for 
guidelines on how the project wants to have patches submitted, to no avail. 
There is no mentioning of a Request Tracker either (or maybe I'm blind) :-)


Seconded.

I joined this list a few weeks ago for the purpose of submitting a small 
patch. I was soon directed to RT.


There are some interesting discussions here, so I've stuck around.

However, it seems like at least every week someone else tries to submit 
a patch via this list.


How do we submit a patch for the website? Hmmm... :-)

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

[openssl.org #1881] Compile Failure: openssl-1.0.0-beta1 (IRIX)

[Pete Plank via RT]

Hello,

I've encountered a compile failure of openssl-1.0.0-beta1. Details are  
as follows:

  # uname -aR
IRIX64 Kazehana 6.5 6.5.30f 07202013 IP35

  # cc -v
MIPSpro Compilers: Version 7.4.4m


./Configure --prefix=/usr/nekoware irix-mips3-cc threads

...

cc -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS -D_SGI_MP_SOURCE - 
DDSO_DLFCN -DHAVE_DLFCN_H -n32 -mips3 -O2 -use_readonly_const -G0 - 
rdata_shared -DTERMIOS -DB_ENDIAN -DBN_DIV3W   -c -o ocsp.o ocsp.c
cc-1070 cc: ERROR File = ocsp.c, Line = 1268
   The indicated type is incomplete.

 struct timeval tv;
^

1 error detected in the compilation of "ocsp.c".
gmake[1]: *** [ocsp.o] Error 2
gmake[1]: Leaving directory `/opt/build/openssl-1.0.0-beta1/apps'
gmake: *** [build_apps] Error 1

...

Thanks much,

Pete Plank

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

[openssl.org #1880] [enhancement request] load_config in ts.c

[Alexey Bezuglyi via RT]

version: openssl-1.0.0-beta1  
file: /apps/ts.c  
  
Hi, the TSA module doesn't include standard piece of code before command line 
processing:  
  
     if (!load_config(bio_err, NULL))  
               goto end;  
  
so next function  
  
          else if ((md = EVP_get_digestbyname(*argv + 1)) != NULL)  
              {  
              /* empty. */  
              }  
  
doesn't work with an engine (i.g. gost)  
  
thanks,  
  
Alexey Bezuglyi  
  

SoftWare Developer

www.mylinux.ua
  
  
  




  

  
  version: openssl-1.0.0-beta1
  file: /apps/ts.c
  
  Hi, the TSA module doesn't include standard piece of code before command line processing:
  
  
     if (!load_config(bio_err, NULL))
  
               goto end;
  
  so next function
  
  
          else if ((md = EVP_get_digestbyname(*argv + 1)) != NULL)
  
              {
  
              /* empty. */
  
              }
  
  doesn't work with an engine (i.g. gost)
  
  thanks,
  
  Alexey Bezuglyi
  
  
SoftWare Developer

www.mylinux.ua


  
  
  

Re: I hope the reports that I sent to -bugs are useful...

[Kyle Hamilton]

On Wed, Apr 1, 2009 at 6:09 AM, Lutz Jaenicke  wrote:
>
> Probably you are not around long enough for the last (0.9.8) release :-)
> In the past we tended to have the success reports sent to openssl-dev.
> The problem with the success reports is that they are actually invalidated
> with every new iteration so keeping those in the request tracker is not
> the correct way.
> I am considering on how to collect the success information which is
> probably best handled with a "yes" or "no" (or the "yes: betaX") in a
> spreadsheet.
> Failures have to be looked into one by one and hence should go into
> separate tickets in the request tracker.

You're right, I wasn't around for 0.9.8 beta. :)

So, if I'm understanding correctly, I should send success reports to
-dev, and failure reports to -bugs, along with... the reported (first)
Target in the subject?

There are two Target: lines:

[...]
Target:   darwin64-x86_64-cc
Compiler: Using built-in specs.
Target: i686-apple-darwin9
[...]

(The first is the argument to Configure, the second is the value of --target.)

However, I'm thinking that if one beta passes, and then the next
doesn't, that indicates a regression that needs to be examined -- so
having the full reports available somewhere indexed would be a good
thing?  (For a spreadsheet, my schema would be to make multiple tabs
-- the first for beta1, second for beta2, and so on.  X axis (each
column) would be the features that have been tested as working on the
platform, Y axis (each row) would be a platform tested.)

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

Re: I hope the reports that I sent to -bugs are useful...

[Lutz Jaenicke]

Kyle Hamilton wrote:
> On Wed, Apr 1, 2009 at 4:55 AM, Lutz Jaenicke  wrote:
>   
>> Hi Kyle,
>>
>> thank you very much for reports, they are currently sitting in the
>> moderation queue. I would kindly ask you and other testers to either
>> * send success messages to the list with just the platform mentioned
>> * send failures to openssl-bugs (or rt which is an alias) with a suitable
>>  subject line exposing the platform and type of problem
>>  "Re: OpenSSL 1.0.0 beta1 released" is not too useful as it will end up in
>>  many open tickets all having the same non-informative subject.
>>
>> Thank you very much,
>>Lutz
>> 
>
> Hi Lutz,
>
> The problem with 'just the platform mentioned' is that there are two
> separate types of platforms on OSX -- 32 bit and 64 bit.  I tested the
> default configuration on each.
>
> In addition, I also tested the experimental-jpake, enable-rfc3779,
> experimental-store, and basically all the other options I had
> available, in separate tests (both 32- and 64-bit).  I'd figured that
> you'd have the ability to parse the configuration lines so that you
> could identify the options in use, the platform, and any combination
> which resulted in a test failure -- and that more information would be
> easier to diagnose problems with than less.
>
> Which list should I send success reports to?  The body will need to
> include the compiler, the Configure options, and platform at the very
> least; that's a bit too much to fit into an appropriate Subject.
>
> (Or am I taking the concept of a proper, comprehensive test matrix too
> seriously for the OpenSSL team's liking?)
>
>   



Probably you are not around long enough for the last (0.9.8) release :-)
In the past we tended to have the success reports sent to openssl-dev.
The problem with the success reports is that they are actually invalidated
with every new iteration so keeping those in the request tracker is not
the correct way.
I am considering on how to collect the success information which is
probably best handled with a "yes" or "no" (or the "yes: betaX") in a
spreadsheet.
Failures have to be looked into one by one and hence should go into
separate tickets in the request tracker.

Best regards,
Lutz
I am considering how to collet
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL 1.0.0 beta 1 released

[Dr. Stephen Henson]

On Wed, Apr 01, 2009, Michael Txen wrote:

> Dear OpenSSL Project Team,
>
> are the DTLS related patches sent by Robin incorporated?
>
> The patches have been reviewed by the original author of
> the DTLS implementation and his comments have been incorporated.
> We also have successfully done an intop test with Certicom.
>

No they haven't yet. I started looking at a few relevant tickets PR#1827,
PR#1828 are broken patches, looks like line-wrap issues. PR#1829 I'm not sure
about: how portable is gettimeofday()?

Please update tickets with working patches against 1.0.0-beta1.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL 1.0.0 beta 1 released

[Peter Sylvester]

OpenSSL wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


  OpenSSL version 1.0.0 Beta 1
  



  Please download and test them as soon as possible. This new OpenSSL
  version incorporates 107 documented changes and bugfixes to the
  toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES).

  


Would it be possible to review the 517 "NEW" problems in the rt
database. some of the non-assigned ones are already 6 years old.
I think that many of the remarks are probably now obsolete and
only pollute the database. some real problems and, in particular,
proposed patches are totally hidden.

Personally I have a few reports, and some are in reality
"treated/fixed"

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

Re: I hope the reports that I sent to -bugs are useful...

[Kyle Hamilton]

On Wed, Apr 1, 2009 at 4:55 AM, Lutz Jaenicke  wrote:
> Hi Kyle,
>
> thank you very much for reports, they are currently sitting in the
> moderation queue. I would kindly ask you and other testers to either
> * send success messages to the list with just the platform mentioned
> * send failures to openssl-bugs (or rt which is an alias) with a suitable
>  subject line exposing the platform and type of problem
>  "Re: OpenSSL 1.0.0 beta1 released" is not too useful as it will end up in
>  many open tickets all having the same non-informative subject.
>
> Thank you very much,
>    Lutz

Hi Lutz,

The problem with 'just the platform mentioned' is that there are two
separate types of platforms on OSX -- 32 bit and 64 bit.  I tested the
default configuration on each.

In addition, I also tested the experimental-jpake, enable-rfc3779,
experimental-store, and basically all the other options I had
available, in separate tests (both 32- and 64-bit).  I'd figured that
you'd have the ability to parse the configuration lines so that you
could identify the options in use, the platform, and any combination
which resulted in a test failure -- and that more information would be
easier to diagnose problems with than less.

Which list should I send success reports to?  The body will need to
include the compiler, the Configure options, and platform at the very
least; that's a bit too much to fit into an appropriate Subject.

(Or am I taking the concept of a proper, comprehensive test matrix too
seriously for the OpenSSL team's liking?)

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

Re: OpenSSL 1.0.0 beta 1 released

[Michael Tüxen]

Dear OpenSSL Project Team,

are the DTLS related patches sent by Robin incorporated?

The patches have been reviewed by the original author of
the DTLS implementation and his comments have been incorporated.
We also have successfully done an intop test with Certicom.

Best regards
Michael

On Apr 1, 2009, at 12:02 PM, OpenSSL wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


 OpenSSL version 1.0.0 Beta 1
 

 OpenSSL - The Open Source toolkit for SSL/TLS
 http://www.openssl.org/

 OpenSSL is currently in a release cycle.  The first beta is now  
released.

 The beta release is available for download via HTTP and FTP from the
 following master locations (the various FTP mirrors you can find  
under

 http://www.openssl.org/source/mirror.html):

   o http://www.openssl.org/source/
   o ftp://ftp.openssl.org/source/

 The file names of the beta are:

   o openssl-1.0.0-beta1.tar.gz
 MD5 checksum: 49f265d9dd8dc011788b34768f63313e
 SHA1 checksum: 89b4490b6091b496042b5fe9a2c8a9015326e446

 The checksums were calculated using the following command:

   openssl md5 < openssl-1.0.0-beta1.tar.gz
   openssl sha1 < openssl-1.0.0-beta1.tar.gz

 Please download and test them as soon as possible. This new OpenSSL
 version incorporates 107 documented changes and bugfixes to the
 toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES) 
.


 Reports and patches should be sent to openssl-b...@openssl.org.
 Discussions around the development of OpenSSL should be sent to
 openssl-...@openssl.org.  Anything else should go to
 openssl-us...@openssl.org.

 The best way, at least on Unix, to create a report is to do the
 following after configuration:

 make report

 That will do a few basic checks of the compiler and bc, then build
 and run the tests.  The result will appear on screen and in the file
 "testlog".  Please read the report before sending it to us.  There
 may be problems that we can't solve for you, like missing programs.

 Oh and to those who have noticed the date... the joke is that it
 isn't a joke.

 Yours,
 The OpenSSL Project Team...

   Mark J. Cox Ben Laurie  Andy Polyakov
   Ralf S. Engelschall Richard Levitte Geoff Thorpe
   Dr. Stephen Henson  Bodo Möller  Ulf Möller
   Lutz JänickeNils Larsch
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBSdNEV6LSm3vylcdZAQIc4gf+Ki9AQzfwES4Up5QRKJCONzIvgIzHpajQ
laGz0L6QQXcMrSrLxubSMfYnnXqX/BfY67C28dLaefEK9xygZMxvbS5d56hm3+3m
SWLWXqHsCrxp4LWm3Kr7senmhBl06LCTYX1AC2VP0ph/UfouQPu15UkuMCt6eDV7
SEUkYDk6TA8Wr7C0nMHnTOQdqx6r/N7OnPEaCCWkMzsMC5KxTkCP9/SGrDam29dt
xV6P5+AntSgNbr9tXYAiQHgMvut9o1O8pTaGdlv2TJ/Ua2ynvmd8hsaO7Ptl3Tpt
Bkaghk+rV3qZgLzWAiHjeebEWyXTSGvMPKM6r5mi8vrqjfbSF4zUKA==
=qESg
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org



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

Re: I hope the reports that I sent to -bugs are useful...

[Lutz Jaenicke]

Kyle Hamilton wrote:
> I hope the test reports I sent to -bugs are useful.  I'm on a Mac OSX
> 10.5.6 machine, Intel-based, and I ran tests in both 32 and 64 bit
> modes, both without and with the optional features.  I do not have gmp
> installed, nor zlib, so I cannot vouch for their usability; I did not
> test krb5, and I also did not test the shared option.
>
>
>   

Hi Kyle,

thank you very much for reports, they are currently sitting in the
moderation queue. I would kindly ask you and other testers to either
* send success messages to the list with just the platform mentioned
* send failures to openssl-bugs (or rt which is an alias) with a suitable
  subject line exposing the platform and type of problem
  "Re: OpenSSL 1.0.0 beta1 released" is not too useful as it will end up in
  many open tickets all having the same non-informative subject.

Thank you very much,
Lutz

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

[openssl.org #1878] [PATCH] Fix RSA blinding locking hole

[Marc Haisenko via RT]

Hi folks,
last week I described a problem with RSA blinding and its locking[1]. 
Coincidentally another user ran into the same problem in a totally different 
scenario, the work-around of disabling the blinding fixed the issue for 
him[2].

So here's a patch to fix this issue.

The issue is that the rsa_get_blinding method checks whether there is 
concurrent access to the blinding and tells its caller whether locking needs 
to be done. The check is done by comparing thread/process IDs. If they differ 
locking needs to be done. The problem is that locking is not done if the IDs 
are same. It is assumed that the creator doesn't need to do locking which is 
correct for a single-threaded application but is wrong in a multi-
threaded/processed environment once another process has accessed the blinding.

As a fix I've introduced a new flag for struct rsa_st, 
RSA_FLAG_BLINDING_NEEDS_LOCKING. Once it has been noticed that locking has to 
be done the flag is set and from then on we always do locking, whether we are 
the creator or not.

However, I'm scratching my head why this fixes the issue given the fact that 
there are actually two blindings: one when doing no locking (rsa->blinding) 
and another one when doing locking (rsa->mt_blinding). Yet our load test 
indicates that this really does fix the issue: without it we get about a dozen 
Bad Record MAC per day due to the blinding. Since I've implemented the 
attached patch none has occured (which is about 3 days of load test now).

Bye,
Marc


[1] - http://marc.info/?l=openssl-dev&m=123754568501758&w=2
[2] - http://marc.info/?l=openssl-users&m=123788810006272&w=2

-- 
Marc Haisenko
Team Leader and Senior Developer
Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany

Tel.: +49 (0)89 548 433 321


diff -purd openssl-0.9.8k.orig/crypto/rsa/rsa_eay.c openssl-0.9.8k/crypto/rsa/rsa_eay.c
--- openssl-0.9.8k.orig/crypto/rsa/rsa_eay.c	2008-09-16 16:55:26.0 +0200
+++ openssl-0.9.8k/crypto/rsa/rsa_eay.c	2009-03-30 12:46:02.0 +0200
@@ -273,9 +273,16 @@
 	if (ret == NULL)
 		goto err;
 
-	if (BN_BLINDING_get_thread_id(ret) == CRYPTO_thread_id())
+	if (rsa->flags & RSA_FLAG_BLINDING_NEEDS_LOCK)
 		{
-		/* rsa->blinding is ours! */
+		/* We already noticed that we have to do locking. */
+		*local = 0;
+		}
+	else if (BN_BLINDING_get_thread_id(ret) == CRYPTO_thread_id())
+		{
+		/* rsa->blinding is ours and there haven't been any other
+		 * threads trying to access the blinding
+		 */
 
 		*local = 1;
 		}
@@ -289,6 +296,13 @@ static BN_BLINDING *rsa_get_blinding(RSA
 		 * stored outside the BN_BLINDING
 		 */
 
+		/* Set flag so we don't need to do this test any more. */
+		rsa->flags |= RSA_FLAG_BLINDING_NEEDS_LOCK;
+		}
+
+	if (!(*local))
+		{
+		/* Set up the shared blinding. */
 		if (rsa->mt_blinding == NULL)
 			{
 			if (!got_write_lock)
diff -purd openssl-0.9.8k.orig/crypto/rsa/rsa.h openssl-0.9.8k/crypto/rsa/rsa.h
--- openssl-0.9.8k.orig/crypto/rsa/rsa.h	2008-09-16 16:55:26.0 +0200
+++ openssl-0.9.8k/crypto/rsa/rsa.h	2009-03-30 12:37:28.0 +0200
@@ -236,6 +236,10 @@
 * be used for all exponents.
 */
 #endif
+#define RSA_FLAG_BLINDING_NEEDS_LOCK	0x0200 /* new with 0.9.8l; once we notice that the
+		* blinding needs to have a lock we set this
+		* flag to always use locking.
+		*/
 
 
 #define RSA_PKCS1_PADDING	1

I hope the reports that I sent to -bugs are useful...

[Kyle Hamilton]

I hope the test reports I sent to -bugs are useful.  I'm on a Mac OSX
10.5.6 machine, Intel-based, and I ran tests in both 32 and 64 bit
modes, both without and with the optional features.  I do not have gmp
installed, nor zlib, so I cannot vouch for their usability; I did not
test krb5, and I also did not test the shared option.

I'll happily run any other tests that you may feel useful or necessary.

(Have I said "thank you" for working on such a usually-thankless
project recently?  If I haven't, thank you.)

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

OpenSSL 1.0.0 beta 1 released

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


  OpenSSL version 1.0.0 Beta 1
  

  OpenSSL - The Open Source toolkit for SSL/TLS
  http://www.openssl.org/

  OpenSSL is currently in a release cycle.  The first beta is now released.
  The beta release is available for download via HTTP and FTP from the
  following master locations (the various FTP mirrors you can find under
  http://www.openssl.org/source/mirror.html):

o http://www.openssl.org/source/
o ftp://ftp.openssl.org/source/

  The file names of the beta are:

o openssl-1.0.0-beta1.tar.gz
  MD5 checksum: 49f265d9dd8dc011788b34768f63313e
  SHA1 checksum: 89b4490b6091b496042b5fe9a2c8a9015326e446

  The checksums were calculated using the following command:

openssl md5 < openssl-1.0.0-beta1.tar.gz
openssl sha1 < openssl-1.0.0-beta1.tar.gz

  Please download and test them as soon as possible. This new OpenSSL
  version incorporates 107 documented changes and bugfixes to the
  toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES).

  Reports and patches should be sent to openssl-b...@openssl.org.
  Discussions around the development of OpenSSL should be sent to
  openssl-...@openssl.org.  Anything else should go to
  openssl-us...@openssl.org.

  The best way, at least on Unix, to create a report is to do the
  following after configuration:

  make report

  That will do a few basic checks of the compiler and bc, then build
  and run the tests.  The result will appear on screen and in the file
  "testlog".  Please read the report before sending it to us.  There
  may be problems that we can't solve for you, like missing programs.

  Oh and to those who have noticed the date... the joke is that it
  isn't a joke.

  Yours,
  The OpenSSL Project Team...  

Mark J. Cox Ben Laurie  Andy Polyakov
Ralf S. Engelschall Richard Levitte Geoff Thorpe
Dr. Stephen Henson  Bodo Möller Ulf Möller
Lutz JänickeNils Larsch
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBSdNEV6LSm3vylcdZAQIc4gf+Ki9AQzfwES4Up5QRKJCONzIvgIzHpajQ
laGz0L6QQXcMrSrLxubSMfYnnXqX/BfY67C28dLaefEK9xygZMxvbS5d56hm3+3m
SWLWXqHsCrxp4LWm3Kr7senmhBl06LCTYX1AC2VP0ph/UfouQPu15UkuMCt6eDV7
SEUkYDk6TA8Wr7C0nMHnTOQdqx6r/N7OnPEaCCWkMzsMC5KxTkCP9/SGrDam29dt
xV6P5+AntSgNbr9tXYAiQHgMvut9o1O8pTaGdlv2TJ/Ua2ynvmd8hsaO7Ptl3Tpt
Bkaghk+rV3qZgLzWAiHjeebEWyXTSGvMPKM6r5mi8vrqjfbSF4zUKA==
=qESg
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH] Fix RSA blinding locking hole

[Marc Haisenko]

On Wednesday 01. April 2009 11:23:45 Kyle Hamilton wrote:
> On Wed, Apr 1, 2009 at 2:12 AM, Marc Haisenko  wrote:
> > On Wednesday 01. April 2009 11:03:55 Kyle Hamilton wrote:
> > I was refering to the two threads cited in my patch e-mail:
> > [1] - http://marc.info/?l=openssl-dev&m=123754568501758&w=2
> > [2] - http://marc.info/?l=openssl-users&m=123788810006272&w=2
>
> Due to a lot of problems in current web browsers (Firefox 3.0.7 had a
> critical flaw in some component or other, and I would prefer my
> machine not get pwned :) ), I tend not to go to unknown sites.  This
> mailing list is archived on Nabble, and it's likely that you'd get
> more folk to look if you linked there.

http://www.openssl.org/support/

:-)

MARC (not me, the Mail ARChive) is one of the largest mail archives on the 
web... and the one linked on the OpenSSL homepage.

> >> r...@openssl.org is the best place to send patches, as it creates a
> >> ticket in the Request Tracking system that is used by the core
> >> developers.
> >
> > Alright. Maybe it would be a good idea to document that on the
> > openssl.org homepage, because before I submitted my patch I was searching
> > the site for guidelines on how the project wants to have patches
> > submitted, to no avail. There is no mentioning of a Request Tracker
> > either (or maybe I'm blind) :-)
>
> It's actually under "Support" on the left side, then "Request Tracker"
> at the top.  I agree, the site could use a major redesign to be more
> useful.  (Right now, it's obfuscated, probably to prevent people from
> abusing it.)

Oh... now I see it. Yes, a redesign would be a very good idea :-)

Anyway, let's stop the spamming, thanks a lot for your help.
Marc



-- 
Marc Haisenko
Team Leader and Senior Developer
Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany

Tel.: +49 (0)89 548 433 321
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH] Fix RSA blinding locking hole

[Kyle Hamilton]

On Wed, Apr 1, 2009 at 2:12 AM, Marc Haisenko  wrote:
> On Wednesday 01. April 2009 11:03:55 Kyle Hamilton wrote:
> I was refering to the two threads cited in my patch e-mail:
> [1] - http://marc.info/?l=openssl-dev&m=123754568501758&w=2
> [2] - http://marc.info/?l=openssl-users&m=123788810006272&w=2

Due to a lot of problems in current web browsers (Firefox 3.0.7 had a
critical flaw in some component or other, and I would prefer my
machine not get pwned :) ), I tend not to go to unknown sites.  This
mailing list is archived on Nabble, and it's likely that you'd get
more folk to look if you linked there.

>> r...@openssl.org is the best place to send patches, as it creates a
>> ticket in the Request Tracking system that is used by the core
>> developers.
>
> Alright. Maybe it would be a good idea to document that on the openssl.org
> homepage, because before I submitted my patch I was searching the site for
> guidelines on how the project wants to have patches submitted, to no avail.
> There is no mentioning of a Request Tracker either (or maybe I'm blind) :-)

It's actually under "Support" on the left side, then "Request Tracker"
at the top.  I agree, the site could use a major redesign to be more
useful.  (Right now, it's obfuscated, probably to prevent people from
abusing it.)

The people who give base-level support don't generally get RT
accounts.  (I don't have one, for example.)  It's my thought that RT
is primarily used for the developers, rather than trying to delegate
support requests -- probably because nobody's getting paid for this
(except the developers, and then only because of support from
companies that want more features -- like Google, apparently most
recently, if the 0.9.9 changelog is any indication). :)

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

Re: [PATCH] Fix RSA blinding locking hole

[Marc Haisenko]

On Wednesday 01. April 2009 11:03:55 Kyle Hamilton wrote:
> I'm only seeing two, the one with the patch and the one with the "what
> god do you have to sacrifice?".

I was refering to the two threads cited in my patch e-mail:
[1] - http://marc.info/?l=openssl-dev&m=123754568501758&w=2
[2] - http://marc.info/?l=openssl-users&m=123788810006272&w=2

> However, that doesn't mean much of anything, as I'm horrible with
> managing my emails.
>
> r...@openssl.org is the best place to send patches, as it creates a
> ticket in the Request Tracking system that is used by the core
> developers.
>
> -Kyle H

Alright. Maybe it would be a good idea to document that on the openssl.org 
homepage, because before I submitted my patch I was searching the site for 
guidelines on how the project wants to have patches submitted, to no avail. 
There is no mentioning of a Request Tracker either (or maybe I'm blind) :-)
Marc

-- 
Marc Haisenko
Team Leader and Senior Developer
Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany

Tel.: +49 (0)89 548 433 321
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH] Fix RSA blinding locking hole

[Kyle Hamilton]

I'm only seeing two, the one with the patch and the one with the "what
god do you have to sacrifice?".

However, that doesn't mean much of anything, as I'm horrible with
managing my emails.

r...@openssl.org is the best place to send patches, as it creates a
ticket in the Request Tracking system that is used by the core
developers.

-Kyle H

On Wed, Apr 1, 2009 at 1:59 AM, Marc Haisenko  wrote:
> On Wednesday 01. April 2009 10:54:39 Kyle Hamilton wrote:
>> Submit your patch to r...@openssl.org, and it'll go into the request
>> tracking system.  I would also recommend that you wait for a bit more
>> than a single day before getting irritated with people who work on
>> this in their spare time, and have day jobs.
>>
>> -Kyle H
>
> Thanks, I'll do. I'm not frustrated that I didn't a response to my patch but
> no response to the whole issue which I reported almost two weeks ago. I am
> enough of a open source veteran to know you can't expect immediate responses
> but four e-mails and no response is frustrating.
>        Marc
>
> --
> Marc Haisenko
> Team Leader and Senior Developer
> Comdasys AG
> Rüdesheimer Str. 7
> 80686 München
> Germany
>
> Tel.: +49 (0)89 548 433 321
> __
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       openssl-dev@openssl.org
> Automated List Manager                           majord...@openssl.org
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH] Fix RSA blinding locking hole

[Marc Haisenko]

On Wednesday 01. April 2009 10:54:39 Kyle Hamilton wrote:
> Submit your patch to r...@openssl.org, and it'll go into the request
> tracking system.  I would also recommend that you wait for a bit more
> than a single day before getting irritated with people who work on
> this in their spare time, and have day jobs.
>
> -Kyle H

Thanks, I'll do. I'm not frustrated that I didn't a response to my patch but 
no response to the whole issue which I reported almost two weeks ago. I am 
enough of a open source veteran to know you can't expect immediate responses 
but four e-mails and no response is frustrating.
Marc

-- 
Marc Haisenko
Team Leader and Senior Developer
Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany

Tel.: +49 (0)89 548 433 321
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH] Fix RSA blinding locking hole

[Kyle Hamilton]

Submit your patch to r...@openssl.org, and it'll go into the request
tracking system.  I would also recommend that you wait for a bit more
than a single day before getting irritated with people who work on
this in their spare time, and have day jobs.

-Kyle H

On Wed, Apr 1, 2009 at 1:48 AM, Marc Haisenko  wrote:
> Forgive my frustration, but which god do I need to sacrifice to to get some
> attention ? Even a "go away, we don't care" would be OK...
>        Marc
>
> --
> Marc Haisenko
> Team Leader and Senior Developer
> Comdasys AG
> Rüdesheimer Str. 7
> 80686 München
> Germany
>
> Tel.: +49 (0)89 548 433 321
> __
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       openssl-dev@openssl.org
> Automated List Manager                           majord...@openssl.org
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH] Fix RSA blinding locking hole

[Marc Haisenko]

Forgive my frustration, but which god do I need to sacrifice to to get some 
attention ? Even a "go away, we don't care" would be OK...
Marc

-- 
Marc Haisenko
Team Leader and Senior Developer
Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany

Tel.: +49 (0)89 548 433 321
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH RFC -v3] Add support to Intel AES-NI instruction set for x86_64 platform

[Huang Ying]

Hi,

On Wed, 2009-04-01 at 16:02 +0800, Andy Polyakov wrote:
> > Just because the unrolled code is not too long.
> 
> As for non-interleaved loop. Reasoning is that folded loop can be
> inlined in several places to spare few cycles on call overhead. Of
> course this is under premise that it is as fast as unrolled one. Intel
> CPUs used to be very good at small loops, which is why I dared to fold
> the loop. Of course it doesn't have to be the case here and if unrolled
> loop will be proved to be faster, inline code will have to be replaced
> with calls.

Sound reasonable.

> >> - why not encode all aes instructions with .byte?
> > 
> > Just want to encode all aes instructions after some review. Now I think
> > maybe we can define aes instructions as perl function and do encoding
> > via perl.
> 
> It's done at the end of script.

Yes. Thanks.

> > I will test your code on real machine.
> 
> There is real machine? Would you care to perform several tests, so that
> we can sort out what's optimal? I mean the folded vs. unrolled, then I
> wonder if my use of .aligns is excessive in *crypt1... I don't demand
> actual figures [in case you can't disclose them], only if/how
> performance is affected... If yes, we can proceed off-list if so desired.

OK. I will do these tests.

1. folded vs. unrolled
2. .align vs no .align in *crypt1

Any other test to added?

I will test with "openssl speed" and send you the result. I will do the
test tomorrow.

> > BTW: you want me to prepare the patch or you prepare the patch yourself?
> 
> I'll manage it myself. A.

Can you send me the full patch, so I can test it.

Best Regards,
Huang Ying



signature.asc
Description: This is a digitally signed message part

RE: [openssl.org #1700]: Bug report - openssl-0.9.8h breaks building applications which depend on it

[Robbins, Aharon via RT]

*** x509.h.old  Mon Feb 23 18:14:36 2009
--- x509.h  Mon Feb 23 18:15:00 2009
***
*** 116,121 
--- 116,122 
  /* Under Win32 these are defined in wincrypt.h */
  #undef X509_NAME
  #undef X509_CERT_PAIR
+ #undef X509_EXTENSIONS
  #endif
  
  #define X509_FILETYPE_PEM 1

Hi. Attached is a patch we developed that fixes this bug.

Thanks,

Aharon (Arnold) Robbins.  Intel Israel Software Design Center, Jerusalem
Email: Pick one: aharon.robb...@intel.com or 
arnold.robb...@intel.com
Links: My Intel 
Blog   My 
Personal Home page   Books I've 
Written
  (more links coming soon)

-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.








Hi. Attached is a patch we developed that fixes this bug.


Thanks,

 

Aharon (Arnold) Robbins.  Intel Israel
Software Design
Center, Jerusalem

Email: Pick one: aharon.robb...@intel.com
or arnold.robb...@intel.com 

Links: My Intel
Blog   My Personal Home page   Books
I've Written  (more links coming soon)

 



-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Openssl doubt SSL_Write

[Balaji Kannadassan]

Hi All!

I've have some doubts regarding SSL_write in non blocking mode..

1. if SSL_write returned SSL_ERROR_WANT_WRITE,  it is mentioned that the
call has to be repeated with the same arguments.
Does this means the same buffer to be used again?? or the data
passed in the initial SSL_write call 
will be buffered by the SSL layer?

2.  In case of SSL_write returning SSL_ERROR_WANT_READ due to
re-negotiation, What are the steps to be followed?
 Is there any wait needed before the repeated SSL_write call? 
 Does the application need to take care of the re-negotiation?
 Does the application need to wait for the re-negotiation to
complete before repeating the SSL_write?


Thanks in advance
Balaji Kamal Kannadassan
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Openssl doubt SSL_Write

[Kyle Hamilton]

If SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE are returned, the
arguments *must* be *exactly* the same.  This includes the data
pointed to by the buffer.  There is a way to set a mode on the SSL
connection to allow a moving buffer, but that's it.  SSL will not
buffer the data passed to it.

If SSL_write returns SSL_ERROR_WANT_READ, then just call SSL_write
again.  (Usually, in this case, you can select() on the underlying
socket to determine if there's any pending data to be read from the
socket.)  If SSL_read returns SSL_ERROR_WANT_WRITE, just call SSL_read
again.  (You might try to select() to see if the socket is writable.)

-Kyle H

On Tue, Mar 31, 2009 at 10:50 AM, Balaji Kannadassan
 wrote:
> Hi All!
>
> I've have some doubts regarding SSL_write in non blocking mode..
>
> 1. if SSL_write returned SSL_ERROR_WANT_WRITE,  it is mentioned that the
> call has to be repeated with the same arguments.
>    Does this means the same buffer to be used again?? or the data
> passed in the initial SSL_write call
>    will be buffered by the SSL layer?
>
> 2.  In case of SSL_write returning SSL_ERROR_WANT_READ due to
> re-negotiation, What are the steps to be followed?
>     Is there any wait needed before the repeated SSL_write call?
>     Does the application need to take care of the re-negotiation?
>     Does the application need to wait for the re-negotiation to
> complete before repeating the SSL_write?
>
>
> Thanks in advance
> Balaji Kamal Kannadassan
> __
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-us...@openssl.org
> Automated List Manager                           majord...@openssl.org
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH RFC -v3] Add support to Intel AES-NI instruction set for x86_64 platform

[Andy Polyakov]

Hi,

>> - why full unroll?
> 
> Just because the unrolled code is not too long.

As for non-interleaved loop. Reasoning is that folded loop can be
inlined in several places to spare few cycles on call overhead. Of
course this is under premise that it is as fast as unrolled one. Intel
CPUs used to be very good at small loops, which is why I dared to fold
the loop. Of course it doesn't have to be the case here and if unrolled
loop will be proved to be faster, inline code will have to be replaced
with calls.

>> - why not encode all aes instructions with .byte?
> 
> Just want to encode all aes instructions after some review. Now I think
> maybe we can define aes instructions as perl function and do encoding
> via perl.

It's done at the end of script.

> I will test your code on real machine.

There is real machine? Would you care to perform several tests, so that
we can sort out what's optimal? I mean the folded vs. unrolled, then I
wonder if my use of .aligns is excessive in *crypt1... I don't demand
actual figures [in case you can't disclose them], only if/how
performance is affected... If yes, we can proceed off-list if so desired.

> And at least you can test the
> code with an emulator: SDE,

That's how the code was tested, every code branch was explicitly tested.

> BTW: you want me to prepare the patch or you prepare the patch yourself?

I'll manage it myself. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [PATCH RFC -v3] Add support to Intel AES-NI instruction set for x86_64 platform

[Huang Ying]

On Wed, 2009-04-01 at 03:45 +0800, Andy Polyakov wrote:
> Hi,
> 
> > This patch adds support to Intel AES-NI instruction set for x86_64
> > platform.
> 
> I apologize for delay.

That's all right.

> Promised to comment on submission in question.
> Well, after some consideration I reckoned that it would take longer to
> discuss it than to implement own version of assembler module. Having own
> code also makes it easier for me to maintain it:-) The module is
> available for preview at
> http://www.openssl.org/~appro/eng_aesni-x86_64.pl.txt. Major points are,
> all addressed in the new code:

Thank you very much for your work.

> - why full unroll?

Just because the unrolled code is not too long.

> - why 4x interleave when aesenc latency is [anticipated to be] 6?

Yes. It should be 6, I neglect this important information in white
paper.

> - why post-4x processing is done with non-interleaved routine, when
> interleaved can be used?

Yes. post-4x processing can be done in interleaved mode. That is faster.

> - why not encode all aes instructions with .byte?

Just want to encode all aes instructions after some review. Now I think
maybe we can define aes instructions as perl function and do encoding
via perl.

> - instruction scheduling in key setup can be [much] better;
> 
> See code and comments in code for further details. I'd appreciate if you
> could review and cross-test the code. [Counter-]comments and suggestions
> are naturally welcomed. The code will be committed to repository as soon
> as remaining issues are resolved. Remaining are build issue (as you
> pointed out yourself) and actual tests on Win64. Note that I suggest to
> name module eng_aesni-x86_64.pl instead of _asm. This implies that
> eventually there will be 32-bit version too.

I will test your code on real machine. And at least you can test the
code with an emulator: SDE, which can be downloaded from following URL:

http://linux.softpedia.com/progDownload/Intel-Software-Development-Emulator-Download-44635.html

Both Linux and windows are supported.

BTW: you want me to prepare the patch or you prepare the patch yourself?

Best Regards,
Huang Ying



signature.asc
Description: This is a digitally signed message part