What security technology should I support?

Hello,

I have been implementing a C++ class library for several years that I
plan to publish as open source. It currently implements a lot of core
objects such as strings, lists, maps, sockets, etc. but has a fair
amount of security-based objects as well: RSA, DSA, and Diffie-Hellman,
X.509v3 certificates and certificate revocation lists (CRL's),
transport layer security (SSL/TLS), and SMTP, POP3, and FTP clients all
capable of negotiating TLS.

My question is: if I were to make this library public today, what would
you consider to be missing? I am kind of at a loss for what to work on
next.

Thanks for any suggestions,

Mike

Sebastian Gottschalk wrote:
> So, if your library doesn't have any special benefit (f.e. having received
> a special certification like ISO 9006, Common Criteria or FIPS 140-2,
> extreme compliance to some coding standard, highly portable and still
> plattform-optimized implementation), you won't receive much attention.

One thing I would like to see is implementation of algorithms that are
fully compliant with some of existing specifications and not just part
of them. An example could be Diffie-Hellman fully complaint with say
NIST SP 800-56A.

Mike wrote:

> Hello,
>
> I have been implementing a C++ class library for several years that I
> plan to publish as open source. It currently implements a lot of core
> objects such as strings, lists, maps, sockets, etc. but has a fair
> amount of security-based objects as well: RSA, DSA, and Diffie-Hellman,
> X.509v3 certificates and certificate revocation lists (CRL's),
> transport layer security (SSL/TLS), and SMTP, POP3, and FTP clients all
> capable of negotiating TLS.
>
> My question is: if I were to make this library public today, what would
> you consider to be missing? I am kind of at a loss for what to work on
> next.
>
> Thanks for any suggestions,
>
> Mike

Victorinox' trademark. <ha ha, only serious>

In more level-headed terms, from an engineering standpoint, I would
recommend you split this little library into two or more segments, one for
your user interface object, as strings; one for internals, as maps and
sockets, and one or more others for security/networking. That way, each
segment can be focused on a discrete number of challenges, and answer them
more effectively than if everything were in one big class.

Sebastian Gottschalk wrote:
> Mike wrote:
>
> > I have been implementing a C++ class library for several years that I
> > plan to publish as open source. It currently implements a lot of core
> > objects such as strings, lists, maps, sockets, etc. but has a fair
> > amount of security-based objects as well: RSA, DSA, and Diffie-Hellman,
> > X.509v3 certificates and certificate revocation lists (CRL's),
> > transport layer security (SSL/TLS), and SMTP, POP3, and FTP clients all
> > capable of negotiating TLS.
> >
> > My question is: if I were to make this library public today, what would
> > you consider to be missing? I am kind of at a loss for what to work on
> > next.
>
> Well, no-one would use it. Basic data structures like strings, lists and
> maps are already covered by the C++ STL and probably well-extended by the
> Boost Library.

The big advantage of using my library is that the interfaces are very
clean and easy to use. I also have added lots of functionality to,
say, my string class that you won't find in STL string. Unicode 5.0
support including normalization (all 4 forms), upper/lower case
conversions, and collation to name a few.

In fact, since it's impossible to come up with the representation of a
string to suit everyone, my string is templatized on that. I have
created stack based strings that don't allocate any memory,
non-reference-counted heap based strings, reference-counted strings
that are safe for use in multi-threaded programs, and faster
reference-counted strings that can be used
in a single-threaded program. If you don't like any of those, then you
can create you own, and the whole library will work with your custom
string representation.

> Sockets are nothing special. In-Depth networking is already covered by
> Libpcap.

Again my Socket interface is very easy to use. In fact if you decide
to add TLS support to a program, you only need a couple extra lines of
code. The rest of the program doesn't change. With OpenSSL or gnutls,
that is not the case.

> For cryptographic stuff, we already have LibCrypt, Crypto++, LibTomCrypt,
> OpenSSL and LibGCrypt. For TSL we've got OpenSSL and GnuTLS. Various
> application procotols are covered by either being trivial or covered by
> many libraries.

Well honestly, I use OpenSSL's libcrypto for all the encryption and
public key algorithms. I just put a pretty face on them that again is
much easier to use. I implemented all SSL/TLS code myself though, and
it supports version 1.1 (OpenSSL currently only supports TLS 1.0), and
even supports the current draft of TLS 1.2.

> There has been much more engineering effort put into these by many more
> people than yours will ever have.

I'm not conceited, but you underestimate me. I've been writing C++
code since 1993 and am quite fast -- it took less than 10 weeks to
fully implement SSL3/TLS 1.0, 1.1, and 1.2, complete with session
caching and resumption, session renegotiation, client authentication,
and some TLS extensions.

> So, if your library doesn't have any special benefit (f.e. having received
> a special certification like ISO 9006, Common Criteria or FIPS 140-2,
> extreme compliance to some coding standard, highly portable and still
> plattform-optimized implementation), you won't receive much attention.

Thanks for providing something constructive. I will look into what it
would take to get certified. As for portability, I have computers
running Windows XP, Suse Linux (64-bit), and Mac OS/X. Programs using
my toolkit compile and run unmodified on each. There is no reason the
code wouldn't readily port to any other version of UNIX.

I would bet that even you would use my library, and you would hope your
competitors don't.

Mike

Mike <mike-list@pobox.com> wrote:
> I have been implementing a C++ class library for several years that I
> plan to publish as open source. It currently implements a lot of core
> objects such as strings, lists, maps, sockets, etc. but has a fair
> amount of security-based objects as well: RSA, DSA, and Diffie-Hellman,
> X.509v3 certificates and certificate revocation lists (CRL's),
> transport layer security (SSL/TLS), and SMTP, POP3, and FTP clients all
> capable of negotiating TLS.
> My question is: if I were to make this library public today, what would
> you consider to be missing? I am kind of at a loss for what to work on
> next.

Again strings, lists and maps? What's with the C++ standard library and
Boost?

Beside that: thank you for hacking Free Software.

Yours,
VB.
--
"Life was simple before World War II. After that, we had systems."
Grace Hopper