SSL -> EVP functions [was: xlat lower/upper]

[Alan DeKok]

Alexander Clouter wrote:

> The Little Tin God known as 'Efficiency' is displeased with your 
> patch...
> 
> *Two* if() statements and two additional pointers, -3 to wisdom. :)

  Yes, well... I didn't have your example to follow.

> Although I do now ponder why I bothered doing an 'upper' function in my 
> patch.

  Now added, too.

> Now, if you could rewrite all your calls to the OpenSSL library code to 
> use EVP functions instead I would be able to use my crypto-accelerators, 
> then I say you are ready for a point release.  On a serious note would 
> that be a case of me having to do this if I wanted it?

  I don't have a crypto accelerator...

> The reason I ask is that I have put FreeRADIUS on an OpenRD[1] 
> (replacing the old 600W Dull boxen we have with a £200 7W nicety) and 
> although regular non-EAP requests are fast I think the EAP ones are alot 
> more expensive CPU wise due to the SSL overhead.  Of course I have not 
> profiled anything yet (do you have any profiling data supporting this or 
> do I need to generate my own?) so could be wrong.  Anyway, as with most 
> ARM/MIPS SoC's they come with lots of goodies, including hardware 
> crypto.

  My $0.02 is that a reasonably modern machine can do many 100's of 2K
RSA key ops per second.  That should be enough for most purposes.

> I got OpenSSL using it which is nice, however I then discovered the hard 
> way that FreeRADIUS does not use the EVP functions in OpenSSL and so 
> offload engines cannot be used.

  Yes, well....

> Would you accept a change like this, or would I be wasting my time 
> trying to submit this sort of thing?

  I'm interested in the patch.  The easiest way to get it in is to break
it into a series of small patches (i.e. github) that each add a small
piece of functionality.

  Most of my hesitation in adding patches is:

1) formatting / portability
2) breaking *existing* functionality
3) multiple independent changes in one patch
4) reading 1000 lines of patch, trying to figure out WTF it does

  I haven't looked into the OpenSSL acceleration code, so I don't know
how complicated it is to do.  My suggestion is to break it up into
patches as follows:

1) configuration options && data structures for using the engines
   i.e. CONF_PARSER stuff, etc.  This lets it be configured, even it
   it does nothing.  This change won't break anything, and should be
   simple to audit

2) actually using the engine...

3) maybe re-working the MD5/SHA calls in src/lib/* to use the OpenSSL
   engine?  I don't know if that would be worth it, tho...

  Alan DeKok.