Re: [boost] Crypto Proposal

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

Thanks for all the feedback!

> On 11/04/2010 7:25 PM, Rob Riggs wrote:
> On 04/11/2010 10:53 AM, Chad Seibert wrote:
>> Here's an example of boostified code, from one of the examples on the
>> site. It's not too different from the original code (it's just
>> commented out); this is because I don't want it to be a chore to port
>> from Botan to Boost.Botan. Also, it is intuitively designed and I see
>> no reason to change it. Of course, if it needs redesigning, we can
>> discuss that afterwards
> ...
>>        //std::auto_ptr<PKCS8_PrivateKey>
>> privkey(PKCS8::load_key(arg_ca_key, rng, arg_passphrase));
>>        std::auto_ptr<boost::botan::pkcs8::private_key>
>> privkey(pkcs8::load_key(arg_ca_key, rng, arg_passphrase));
> Hi Chad,
>
> Would it make sense to have privkey() return the private key by value?
> Is it non-copyable?
 
> I think the reason is because a PKCS#8 key can be RSA/DSA or whatever else.
 
> I'd like to be able to hold keys by value but I'm not sure whether that 
> is useful. I can't really see a need to copy keys around, but then again 
> who knows?
 
> A Boostified Botan should consider this problem as Botan requires the 
> use of lots of yucky pointers in places because of the polymorphism.

It's returned by pointer, since private keys are memory locked by SecureVector (see http://files.randombit.net/botan/doxygen/html/namespaceBotan_1_1PKCS8.html), to prevent flushing to disk (and other potential bugs noted here: http://files.randombit.net/botan/doxygen/html/secmem_8h-source.html). A bigger issue I see is AlgorithmIdentifier/OID mess I see in http://files.randombit.net/botan/doxygen/html/namespaceBotan.html#378aea09f9e0d7b35a62e908cc8c594e. Definitely needs to get replaced with something else. 

There is some rational reasoning with this, though. For example, when we load a pksc#8 key, we get an algo id, which leads to a huge if/else if statement (http://files.randombit.net/botan/doxygen/html/namespaceBotan.html#378aea09f9e0d7b35a62e908cc8c594e). It's also dependent on which libraries get build (the BOTAN_HAS_* defines). In any case, it's still far from perfect and needs to be thoughtout. I'll think about it, and get back to you.

> On 12/04/2010 7:52 AM, Domagoj Saric wrote:
> IMNHO that's a failed test by any standard (worse than OpenSSL and Crypto++)...
> (must I really pay for e.g. virtual inheritance, dynamic_casts,
> by-std::string-runtime-algorithm-lookups etc. etc... for such a simple use
> case?)...
 
> 1) If you write such simple applications, you are very lucky
> 2) I think one "issue" on Botan for Windows is the entropy gatherer. 
> It's slow and takes a lot of memory if.. memory serves. For applications 
> where entropy is not THAT important, I replace it. For applications 
> where it IS important, I would take out life insurance.

That's because you built Botan in whole; it has the ability to build only parts of itself. If we don't like the inheritance structure, I can certainly remove it when porting. For example, despite public keys being very similar in structure, they should NOT inherit from a common base simply because they are entirely different objects. Also, I certainly agree that the runtime lookup of algos is REALLY BAD and doesn't take advantage of the IH, as noted above. I agree it needs to be replaced. As for the RNG's they are easily swapped, so maybe a less expensive one should be created in the process?

>> From this I gather that the original author plans to continue to develop and
> maintain the original library, in which case I wonder what would be the purpose
> of having a library that is nothing more but a 'parallel' 'boostified' version
> of the original that in itself offers nothing new and is updated only after the
> original one is updated?
 
>  I also think it is useless if Jack does not intend to treat the Boost 
>  version as *the* version.
 
>  However, in the transition period, I think it is only sensible that the 
>  student manually merges changes. Will take some planning...

I agree that this version should become *the* version, but I was completely absent-minded and didn't bring that up when discussing this with him. I'll ask him ASAP.

Hopefully this alleviates some issues,
Chad Seibert
                                               
_________________________________________________________________
Hotmail has tools for the New 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_1