|
Posted by Mike on November 24, 2006, 7:41 pm
If you were Registered and logged in, you could reply and use other advanced thread options
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
|
|
Posted by Sebastian Gottschalk on November 25, 2006, 5:56 am
If you were Registered and logged in, you could reply and use other advanced thread options
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.
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.
Sockets are nothing special. In-Depth networking is already covered by
Libpcap.
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.
There has been much more engineering effort put into these by many more
people than yours will ever have.
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.
|
|
Posted by JAB on November 25, 2006, 7:38 am
If you were Registered and logged in, you could reply and use other advanced thread options
> 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.
|
|
Posted by Mike on November 25, 2006, 10:34 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> 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
|
|
Posted by Sebastian Gottschalk on November 26, 2006, 6:20 am
If you were Registered and logged in, you could reply and use other advanced thread options
>> 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.
No, that's the description of C++ STL.
> 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.
Well, this doesn't belong in there - this belongs to a separate utility
collection class for string manipulation.
> 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.
And again, you mixed stuff together with no need. Reference counting is
exactly what LibBoost adds, and stack-based strings are, well, strange.
>> 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.
IBTD, this is exactly what OpenSSL and GnuTLS do.
>> 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.
OK, and what about unit testing, bug testing, real-world testing?
|
| Similar Threads | Posted | | LayerOne Technology Conference | April 29, 2004, 5:26 pm |
| Validy Technology: A program protection method that really works. | August 3, 2005, 6:09 am |
| Management of Innovation and Technology Conf (21-23 June 2006, Singapore) | July 23, 2005, 2:32 am |
| Motorola Biometrics Solution Will Help Protect Delaware Citizens with Improved Identity Technology | April 11, 2006, 2:22 am |
| X.509 certificate pkcs#1 v2.1 support | January 28, 2006, 11:17 am |
| HPSBUX0101-137 HP9000 series 700/800 Support Tools Manager | April 8, 2004, 6:37 am |
| HPSBUX0101-137 rev.3 HP-UX Support Tools Manager (xstm,cstm,stm) | May 17, 2004, 2:11 pm |
| SSRT3613 rev.0 HP-UX B6848AB GTK+ Support Libraries elevated privileges | May 17, 2004, 2:29 pm |
| SSRT3613 rev.1 HP-UX B6848AB GTK+ Support Libraries elevated privileges | February 24, 2005, 12:43 pm |
| Encryption Wizard Offers Large Object Binary support for Oracle Customers. | May 20, 2005, 12:52 pm |
|
XML site map