On Fri, Aug 15, 2008 at 5:11 PM, Fred Picher <[EMAIL PROTECTED]> wrote:
[...]
>> If this is not sufficient you may check out ssl/sslv3.c etc and
>> actually remove the ciphers you don't want to support in your
>> libssl from the registration tables.
>
> As a test, I've commented out every cipher definition in
> ssl/s3_lib.c, like this example:
[...]
> Now, 3DES might by somehow dynamically added to the list when DES
> is present. That could make sense and would mean that the actual
> DES-specific code would have to be modified to separate 3DES.
[...]
Ahh... This brings back memories... I had to do the same 'selective
compilation' back before 2000 when the USA would prohibit cipher
export at 128 bit and beyond unless you had a specific license.
I know (but can't quote chapter and verse) that those restrictions
have been 'lessened' in that the max. allowable number of bits and
type of ciphers has been increased. Unless you are exporting to Mr.
Bush's axis-of-evil states and other friendly neighbours that are
currently frowned upon by the administration.
Anyway, what I did back then is track down all the 'undesirable' code
in the crypto/*/ directories and add a few lines in each along the
lines of:
#if 0
...
#endif
around all the code (des3 is a prime example and the cipher is
implemented in easily located functions which you can disable this
way).
When done, recompile and let the linker errors (error 666: "missing
function you just #if-nulled :-(") guide you to the code using these
functions and 'strip out' those bits as well using the #if 0 ...
#endif approach (tip: a bit more typing but way safer than /* ... */
commenting code as the latter will be screwed up when you wish to
strip code containing comments itself!).
IIRC most of the use of the ciphers is regulated through neat objects.
Why this approach: just commenting out those ciphers in that list will
not withstand a code review by government officials (something I had
to cope with back then; anal retentiveness has its uses sometimes) as,
without those extra #if 0...#endif additions, you will find that
several bits and pieces of 'restricted software weaponry' may still
show up in the final compiled binary. Which was highly illegal back
then, even if that code was proven to be essentially 'dead code'.
Hence the only way to placate government was to brutally strip the
offending crypto source code lines and then make the remaining OPenSSL
code and makefile cope with this. The #if 0 ... #endif approach was
accepted (as we used a special preprocessor which produced a
'restricted code base' from this by simply discarding all #if 0-ed
code lines.)
This may sound like a daunting task, but back then (was it 0.9.5?) it
was rather easy and I think it still is. Machines are faster now so
your 'make - fix' cycle will be even faster.
Except for 3DES (which sits in the /DES/ subdir, but in separate
source files), each cipher has it's own subdir so that makes things
rather elegant: slap-bang #if 0/#endif around each of those .c sources
in there and you're good to go for an initial round of "make-check
linker errors-fix code". My guestimate is you need around 4 rounds if
you tackle all ciphers in one go.
Just my 0.02 USD.
PS: of course, a nice 'feature' added to your work would be to use a
makefile-provided #define, say -DCUSTOM_ALLOW_GOOD_CRYPTO and use
#if defined(CUSTOM_ALLOW_GOOD_CRYPTO)
...
#endif
instead of that overly rude #if 0 ... #endif
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: [EMAIL PROTECTED]
mobile: +31-6-11 120 978
--------------------------------------------------
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
