[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CSM_Buffer memory allocation sheme, AppLogin and 3DES Encrypt ion



Simon:

Basically you have the correct logic.  Unfortunately you are fighting some
limitations we placed in the logic in the beginning design phases; you must
have a private key to encyrpt.  This is due to the various encryption
algorithms supported that do require a private key.  We have the artificial
restriction that even RSA must have a private key.  This aligns the proper
algorithms to be supported.  We may be able to fix this in the future; in
the mean-time you can use one of our test PKCS12 RSA private keys as a
substitute, you will have to set the Applicable and UseThis flags on the
appropriate RSA login.

Your assignment of RecipientInfos are correct.

As to AllocMoreMem(...), we are just starting to look at memory performance
issues.  I have encrypted messages over 1 MByte and not suffered the timing
you mention.  We could certainly improve the timing here by per-allocating
the expected known size.  We have been investigating ways to improve the
SNACC buffer performance for encoding and decoding as well. I will attempt
to pre-allocate the buffer in RawEncrypt to improve performance when my
tasks lighten up.  You should be able to test this concept by simply adding
a statement similar to the following:

<<<<<<< in ./SMIME/libsrc/hilevel/sm_Encrypt.cpp; Around line 1190
...
   // encrypt the provided content
   bufEncryptedContent.Alloc(pContent->Length() + 100);	//<<<<ADDED for
performance.
   if ((status =
pTmpInstance->AccessTokenInterface()->SMTI_Encrypt(pContent,
         &bufEncryptedContent, &bufContentParameters, &bufMEK)) !=
SM_NO_ERROR)
      SME_THROW(status, "SMTI_Encrypt returned error.", NULL);
...

This should pre-allocate an appropriate amount of memory avoiding the
AllocMoreMem(...) call.

Bob Colestock
VDA

-----Original Message-----
From: Simon Blanchet [mailto:sblanche@xxxxxxxxxx]
Sent: Wednesday, June 13, 2001 2:36 PM
To: imc-sfl@xxxxxxx
Cc: Philippe Leroux
Subject: CSM_Buffer memory allocation sheme, AppLogin and 3DES
Encryption



I've been trying to work with SFL since a little time and I'm experiencing
some problems.  First of all, I only wanted
to encrypt a very simple mail message using an previously generated X.509
Certificate (using OpenSSL).  I'm not totally
sure of the step that I used to do so.

More Information about my current Setup:

OS: Windows 2000
CTIL: sm_Free3DLL (using Crypto++ (I don't Have RSA BSafe))
SFL Version: 1.9

Basically here is what I'm trying to do:

1- I have a text file (filename: FromOutlook.txt) that represents a "upper
level" MIME Entity (Begin with
Content-Type:...).
2- I have a X.509 DEREncoded Certificate previously generated with OpenSSL
(filename: SimonBlanchetCert.cer)

What I'm trying to do:

(Only Encrypt, no signing, not including sender's cert)

1- Encrypt the FromOutlook.txt using 3DES-EDE3-CBC (for the CEK)
2- Encrypt the CEK with the Public Key of Certificate SimonBlanchetCert.cer
3- Obtain the resulting CMS Message (Encoded BLOB)

Now I'll present how I tried to do what I wanted (please correct me where
I'm wrong)

1- Login to SFL using CSM_AppLogin

CSM_AppLogin* pAppLogin = new CSM_AppLogin("sm_free3DLLd", "sm_free3DLL NULL
NULL NULL sm_FREE3");

2- Create an CSM_Buffer in order to construct an CSM_MsgToEncrypt

CSM_Buffer buf("FromOutlook.txt");

3- Create an CSM_MsgToEncrypt with the CSM_Buffer

CSM_MsgToEncrypt msg(&buf);

4- Trying to assing a recipient's Certificate

msg.SetContentEncryptOID(new CSM_OID("1.2.840.113549.3.7"));  // Necessay
Step??? (is there any other ways)

CSM_Buffer cert("SimonBlanchetCert.cer");

CSM_RecipientInfo recipient(cert);

msg.m_pRecipients = new CSM_RecipientInfoLst;  // Is it the right way? (why
it's my responsability to allocate memory?)

msg.m_pRecipients->AppendL(&recipient);  // It works (but does not looks
like the right way...)

5- Try to encrypt the thing...

msg.Encrypt(pAppLogin);  // Takes arround 4 minutes for a ContentData of
~300k !!!!

It works until it tries to encrypt CEK with Recipient Info (it was not
initialized (don't know how... it looks like...))


I misUnderstand a lot of thing (I think):

- AppLogin (I only want to encrypt so I don't need to initialize with
PrivateKey or PKCS12... (at least I think...))
- How to assign recipients (Certificates and Recipients ID?)
- Memory allocation while encrypting (CSM_Buffer::AllocMoreMem is called
like so many time for nothing)

I have many questions:

- Why does it takes so long to encrypt a very simple mail (size: ~300k) is
it because of the fact that you are
allocating memory with 8 bytes chunks within CSM_Buffer::Write?  Do I need
to do a special setup first to tell the size
of the resulting encryption?  By the way the lenght of the resulting BLOB is
previsible no? (we can compute it for
single allocation before doing the processing... (just round the
ContentToEncrypt to the next multiple of blockSize for
a BlockCipher))?

- Is it possible to Login without providing PrivateKey information in the
case that you Encrypt Only (using 3DES for
Symmetric Encryption and RSA to encrypt CEK for the recipient)?

- What is the "Right" way to add (and constructs) recipient related
information to a content that you only want to
encrypt?


By the way I'm not even sure if a use your SFL Library like it is supposed
to be used (Read: Maybe I'm trying to do
something really simple the wrong way).

Thanks a lot for your support (and your futur answers)


|=========================================
| Simon Blanchet
| Software Designer
|
| Email: sblanche@xxxxxxxxxx
|=========================================