Re: [boost] Crypto Proposal

Subject: Re: [boost] Crypto Proposal
From: Chad Seibert (chadseibert_at_[hidden])
Date: 2010-04-14 12:44:35

Here's a response to a question asked on the private review system:

The design and architecture is based on dynamic polymorphism, for
better or worse. In the process of porting it to Boost.Botan, it would
be made static. On the mailing list, someone created a simple project
that creates a certificate and the exe grew from 40kb to 1mb. Having
static polymorphism would solve this problem. Also, we won't have to
pay the runtime penalties for dp (especially since it's not needed -
something that Boost libraries have shown time and time again).

Looking at other libraries under similar licenses yielded similar
results. Crypto++ also uses DP (and has even larger hierarchies) and
for simple uses, the entire library get's built and included with
project. For example,
http://www.cryptopp.com/docs/ref/class_s_h_a1.html. SP will solve this
problem, and Botan uses less DP which should make it easier to convert.
I couldn't find a valid libtomcrypt homepage, so I don't know how it's
structured.

The interface of Botan is simple and intuitive. Looking at their
sample programs (and other samples), there doesn't seem to be a simpler
method to implement the various techniques and still remain flexible.
Crypto++ samples seem to be a bit difficult to digest, requiring manual
creation of secure memory blocks and ugly dynamic casting. More can be
seen here: http://www.cryptopp.com/wiki/Diffie-Hellman.
All in all, Botan has a simpler interface and a DP hierarchy that
shouldn't be (as) difficult to convert to SP. I wanted to compare
against libtomcrypt, but couldn't find a valid implementation.
An example of how something might get ported would be the following.
Botan.AES_128 has the inheritance hierarchy
Botan->SymmetricAlgorithm->BlockCipher->AES->AES_128.
Writing this as SP would look like the following (if I understand SP
correctly):

Before:

class SymmetricAlgorithm {

  void set_key(...)

}
class BlockCipher: SymmetricAlgorithm {

  virtual void encrypt(...)

  virtual void decrypt(...)

}
class AES: BlockCipher {

  void encrypt(...);

  void decrypt(...);

}
class AES_128: AES {

}

There is no reason for AES. I'd first remove that class and have
AES_128 derive from BlockCipher directly. Converting this to SP yields
(sorry, I don't have a compiler to test this atm):

template<class BlockCipher>
struct SymmetricAlgorithm {

  void set_key_impl() {

     static_cast<*BlockCipher>(this)->set_key();

  }

}
template <class AES_128>
struct BlockCipher: SymmetricAlgorithm<BlockCipher>{

  void set_key();

  //More stuff

}

However, there is one concern. SymmetricAlgorithm is the base class
of three major hierarchies: BlockCipher, MessageAuthenticationCode, and
StreamCipher. If this inheritance hierarchy stays, it will mean lot's
of template metaprogramming (some of which I don't know how to do).
In any case, it's easier to work with than Crypto++. For example, SHA1 in Crypto++ has a hierarchy depth of 9; Botan 5.

Hope this answers some questions! Glad you are interested in my work!

Chad Seibert
                                               
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3