RE: inclusion of the IDEA algorithm

Marco:

Sorry about not responding earlier to your question on the licensing, I was
hopeful someone else would answer as I do not understand all of the issues
involved.  As far as the SFL is concerned, all of our code is un-restricted.
The GNU license issue comes in on the components we include, like SNACC,
Crypto++, and open-ssl (all of which have their own respective licenses, not
quite GNU).  The way I understand the licensing issue, you are welcome to
incorporate any of these components without charge, but you must make
available any changes to the components available in source form and in
theory return any improvements to the components to the original authors for
general use.  I do not believe this source requirements extends to your
application.  I do not believe you must provide the source of the public
components as part of your distribution either, simply make it available if
a user wants access to your modifications (e.g. perhaps a separate zip file
on a web page).

As to the use of the IDEA algorithm; you are absolutely correct in your
assumption that the SFL is algorithm independent (as much as is possible).
You can simply update the CTIL of choice (or create your own, painful).
This is relatively easy, for the sm_free3 CTIL, you would update the OID
init method to include the IDEA algorithm in the list for content encryption
algs, and update the SMTI_Encrypt(...) and SMIT_Decrypt(...) methods to
check for the OID(s) and perform the new operations.  If you place the
algorithm logic in a separate file and simply call your new functions in the
sm_free3.cpp file, we can place #ifdef logic to place these few changes into
the CTIL for your convenience, thus making the logic available later (I
believe the Crypto++ library provides the IDEA logic).

If this proves confusing, e-mail back, I can send you the exact module names
to update in the sm_free3 CTIL.  The hard part of adding an algorithm to the
CTIL is the testing, setting up the environment, etc.  In this case, you
will be disabling any use of Key Agreement Recipient Info (KARI) processing,
since the KARI key wrap must match the content encyrption (e.g. there are
OIDS for 3DES and RC2 for the matching key wrap algorithm).  If you use the
Crypto++ logic, the calls should match closely to the existing 3DES and RC2
class usage.

Bob Colestock
VDA

-----Original Message-----
From: Marco Scarsi [mailto:[email protected]]
Sent: Tuesday, June 12, 2001 4:20 AM
To: [email protected]
Subject: inclusion of the IDEA algorithm



Dear all,

I am wonderig whether in the SFL there are any problems in including the 
IDEA algorithm for symmetric content encryption. As from the SFL software 
design, the High-Level libary should not include algorithm specific logic. 
Hence, if one provides a crypto token that supports IDEA, and bind it to the

high-level library, everything should work fine. Is this correct?
Can anybody please confirm or reject my reasoning?

I recently posted a question concerning the GNU public licence but didn't 
get any answer yet. Any idea on this topic?

Thanks for help

Marco Scarsi
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.