headers
John Stark | 11 Mar 2004 17:40
Favicon

PKCS#12 files without passwords


Hello,

I am attempting to port an application that I developed a little over 2
years ago from SFL release 2.1 to release 2.3.

I have a problem using PKCS#12 files without passwords.  Our application
is non-interactive and if there is a password it has to be configured. 
We prefer not to use them most of the time, as they are just something
to get wrong that can break the configuration, and add no security.

SFL 2.1 used some code from OpenSSL to read PKCS#12 files.  Although the
SMIME/alg_libs/sm_free3 code as shipped required a password to work, the
underlying OpenSSL code worked without one, and I was able to apply a
trivial fix to the sm_free3 code to enable it to be used.

SFL 2.3 has its own code for reading PKCS#12 files, which clearly wasn't
written with the possibility of not having a password in mind.  I have
tried fixing it up in the obvious manner but without success.  It then
returned the user certificate incorrectly decrypted.  I think I must
have got some subtlety of the way the password is converted to make a
Unicode string, then hashed with a salt value to make the decryption key
wrong.

Could you please tell me if there is a fix to this problem, and if so
when it will be available.

John Stark
--

-- 
John Stark
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stark | 11 Mar 2004 19:59
Favicon

Patches for totally independent debug and release builds of SFL 2.3

The attached tar file contains some patches to the SFL 2.3 makefiles to
enable totally independent debug and release sets of the SFL libraries
to coexist in the same build tree.  This requires the debug builds of
the crypto++ and SNACC libraries to be given the "_d" suffix.

The remaining files in the tar file are the GNUmakefile for Crypto++
5.1, modified correspondingly, and two scripts mklinux and clean.sh that
I use to make the debug and release builds - these are merely for
illustration, as the crypto++ makefile is maintained separately by its
author.  (Running clean.sh deletes everything necessary to do a debug
build after a release build or vice versa without deleting any libraries
from SMPDist.)

Would it be possible for the patches or an equivalent change to be
incorporated in the SFL source base, so that in future releases the
independence between the debug and release sets of libraries is
preserved?

Another thing I note is that the libcert(_d).a and libsm(_d).a are built
as static libraries, whereas all the other SFL components are shared
libraries.  Is there any good reason for this?

Thank you.
--

-- 
John Stark
Tel: +44 1223 566732
Mobile: +44 7968 110628
E-mail: jas <at> metanate.com
Web: http://www.metanate.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stark | 12 Mar 2004 11:24
Favicon

Encryption performance problem


Hello,

I am attempting to port an application from SFL 2.1 to 2.3.  In SFL 2.1
there was a serious memory management flaw in the class CSM_Buffer. 
When encrypting a message, however large, it realloc'ed the buffer to
add 8 bytes at a time.  Hence it took several minutes to encrypt a 10MB
content.  I fixed CSM_Buffer to do fewer reallocs and gained acceptable
performance.  I submitted my fix to this list at the time.

The SFL 2.1 code containing my fix will encrypt a 10MB message using
3DES in around 3.4 seconds, using a release build on a 3000MHz P4. 
However, I have just written a test program using SFL 2.3 and found that
3DES encryption of a 10MB content takes around 24 seconds, about 2/3 of
which is in system calls, on the same system.  So it would appear that
the memory management in SFL 2.3, whilst not as broken as in 2.1, still
has severe deficiencies.  As it stands it cannot be deployed in our
application, which is often run on systems much slower than my PC.

RC2 encryption yields similar results.  AES encryption takes 19 seconds,
but very little is system CPU time, which suggests that the memory
management is better but the implementation of the algorithm is slow. 
The AES encryption in SFL 2.1 was faulty anyway.

SFL 2.1 also had another problem which emerged during stress testing
(initially attempted with a 1GB message).  Even if I supplied the
content to encrypt or sign in a file-based CSM_Buffer (which worked
fine), the SFL classes internally allocated memory-based rather than
file-based CSM_Buffers.  Memory usage peaked at around 4x the content
size during encryption or 6x the content size when signing.  I have not
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stark | 12 Mar 2004 13:50
Favicon

SNACC::SnaccException m_errorCode clashes and literal constants


I am trying to write a function that, given a caught
SNACC::SnaccException object, turns the m_errorCode field into a
string.  As it stands, my function is as shown below.

There are 2 problems:

1. Parts of the sm_free3 code call SME_THROW with literal integer
constants rather than #defined values.  This was also the case in SFL
2.1, but I was hoping it would have been remedied in SFL 2.3.  Instead
more code has been added that follows the same practice.

2. Both SNACC and sm_free3 define 6000 as the base for their error
codes, and there are 9 clashes.  I believe that a caught SnaccException
could potentially contain an error code from either group, so I cannot
determine which string is appropriate.  I think this problem may have
been caused by the merging of exception classes.

Please let me know if my function has omitted any codes that may be
returned, and confirm that these issues will be resolved in the next SFL
release.

--

-- 
John Stark
Tel: +44 1223 566732
Mobile: +44 7968 110628
E-mail: jas <at> metanate.com
Web: http://www.metanate.com

static const char *error_string(const unsigned sfl_error_code)
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stark | 16 Mar 2004 20:11
Favicon

SNACC::SnaccException and CML::ASN::Exception


Hello,

I notice that most of the SFL 2.3 code now throws the exception class
SNACC::SnaccException, which contains an error code, a string and a call
stack, and is defined in SNACC's snaccexcept.h.

However parts of the CML code use a subclass of Snacc::SnaccException
CML::ASN::Exception, which only adds a separate error code of its own. 
The CML errors don't occupy the same number space as the other SFL
errors, and as far as I can tell, when a CML::ASN::Exception is thrown
the base SNACC::SnaccException's m_errorCode member is left set to a
meaningless value.

Would it not be better to abolish the separate CML::ASN::Exception
subclass, use SNACC::SnaccException throughout, and renumber the CML
error codes into the same number space as the error codes used
elsewhere?  This would save all my functions that use SFL having to
contain double catch handlers like:

try
{
  // code that calls SFL methods ...
}
catch (CML::ASN::Exception &e)
{
  // cleanup code ...
  error_code   = static_cast<CML::ASN::Error>(e);
  error_string = CMU_GetErrorString(error_code);
}
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stark | 16 Mar 2004 20:24
Favicon

A couple of places where const_cast is needed


I notice that a number of methods in SFL 2.3 have gained const
parameters or return values which were not defined as const in SFL 2.1. 
Whilst this is generally an improvement, there are a couple of places
where it has not been applied consistently, so I have to resort to using
const_cast to cast to non-const values:

1. Methods such as CSM_MsgToVerify::AccessEncapContentClear() return
   a const CSM_Content* pointer.  To extract the data from this I
   have to cast the member m_content to a non-const CSM_Buffer*
   pointer, because none of CSM_Buffer::Open(), CSM_Buffer::cRead()
   or CSM_Buffer::Close() are defined as const methods.

2. CSM_RecipientIdentifier::AccessIssuerAndSerial() returns a
   const CSM_IssuerAndSerialNumber* pointer, but this has to
   be cast to a non-const pointer because its GetIssuer() and
   GetSerial() methods are not defined as const.

It would be nice if these classes' use of const was made self-consistent
in the next SFL release so I can remove the const_cast's.

--

-- 
John Stark
Tel: +44 1223 566732
Mobile: +44 7968 110628
E-mail: jas <at> metanate.com
Web: http://www.metanate.com
Permalink | Reply | 0 comments |
headers
Nicholas, Richard | 16 Mar 2004 22:12

RE: SNACC::SnaccException and CML::ASN::Exception


John,

Good suggestion.  We'll combine the CML errors into the shared error
number space in the next version.  By eliminating the need to store CML
errors in a different exception class, applications can simply catch
SnaccExceptions.

- Rich
-------------------
Richard E. Nicholas
Secure Systems Consultant
DigitalNet Government Solutions
Richard.Nicholas <at> DigitalNet.com
(301) 939-2722

-----Original Message-----
From: John Stark [mailto:jas <at> metanate.com]
Sent: Tuesday, March 16, 2004 2:11 PM
To: imc-sfl <at> imc.org
Subject: SNACC::SnaccException and CML::ASN::Exception

Hello,

I notice that most of the SFL 2.3 code now throws the exception class
SNACC::SnaccException, which contains an error code, a string and a call
stack, and is defined in SNACC's snaccexcept.h.

However parts of the CML code use a subclass of Snacc::SnaccException
CML::ASN::Exception, which only adds a separate error code of its own.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stark | 19 Mar 2004 00:34
Favicon

sm_free3.cpp patch for RSA verify


The patch shown below enables the sm_free3 CTIL to perform verification of
RSA signatures when the user has a DSA private key.  This fix had already
been applied in one of three places where it is needed.  It would be nice if
this fix is included in the next SFL release.

John Stark
Tel: +44 1223 566732
Mobile: +44 7968 110628
E-mail: jas <at> metanate.com
Web: http://www.metanate.com

*** sm_free3.cpp        9 Mar 2004 13:33:37 -0000       1.1
--- sm_free3.cpp        18 Mar 2004 18:07:40 -0000      1.2
***************
*** 4852,4857 ****
--- 4852,4860 ----
              // generate a new FREE CTI class
              if ((pFree = new CSM_Free3(id_dsa)) == NULL)
                 SME_THROW(SM_MEMORY_ERROR, NULL, NULL);
+             // JAS: added this.
+             pFree->SetDefaultOIDs(rsa);   // Add RSA, DSA already present.
+
              // CSM_Free3 constructor set's Alg IDsa
              pFree->SetCSInst(pNewInstance);
                             // SINCE we generated a CSM_CSInst, not a
CSM_CtilInst.
***************
*** 6165,6170 ****
--- 6168,6176 ----
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stark | 19 Mar 2004 19:36
Favicon

Patch for PKCS#12 files without passwords

The attached patch enables PKCS#12 files without passwords to be used
with the sm_free3 CTIL in SFL release 2.3.  Please could this feature be
incorporated in the next SFL release.
--

-- 
John Stark
Tel: +44 1223 566732
Mobile: +44 7968 110628
E-mail: jas <at> metanate.com
Web: http://www.metanate.com
Attachment (sm_free3Internal.cpp.patch): text/x-patch, 3431 bytes
Permalink | Reply | 0 comments |
headers
John Stark | 24 Mar 2004 17:41
Favicon

Memory management problems in SFL 2.3

I have been testing an application that I have ported from SFL 2.1 to SFL
2.3.  As part of this process I have been running it with the "mpatrol"
heap checking library.  The following is a summary of the problems I have
encountered.  Some of these, together with the 3DES and RC2 performance
issue that I reported a while ago, are serious enough to prevent us being
able to deploy SFL 2.3 in place of SFL 2.1.  Others also affected SFL
2.1 but we hoped that a newer release would eliminate them.

These tests were done using GCC 3.3.2 on a Linux system, but nothing
about them suggests platform-dependence.

We would be interested in knowing when a new release is likely to be
available that remedies these deficiencies, plus the others that I
have reported over the last two weeks.

1. Memory leaks

Both signing and signature verification appear to have significant
memory leaks.  The signing memory leak does not occur in the most
trivial case, but does occur in either of the following circumstances:

a. I have set the flag to include the signer's certificates.
b. I have attached a signed attribute (signing time)

The verify leaks occur when processing the messages that exhibited
a leak during signing.  These leaks are reported in:

a. SNACC::AsnRvsBuf::AsnRvsBuf(SNACC::AsnBuf const&)
   - 8 occurrences per verify operation, 24 per sign operation
b. SNACC::AsnBuf::insert(SNACC::AsnBuf const&)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane