Re: [boost] Crypto Proposal
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#378aea09f9.... 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#378aea09f9...). 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:W...
On 12/04/2010 2:52 PM, Chad Seibert wrote:
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?
You know, one other option is to have ASIO support Botan for SSL and drop the whole Boostify part of it (for now.) That would remove a lot of busy work and let you get to the stuff you enjoy which you said is the actual cryptography. I did some cryptography in my senior year, fyi. I have selfish reasons for ASIO+SSL, but just a thought :) -- Sohail Somani http://uint32t.blogspot.com
"Chad Seibert" <chadseibert@live.com> wrote in message news:BAY113-W22637C5D23F9712BD3FB39D3120@phx.gbl...
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?)...
That's because you built Botan in whole; it has the ability to build only parts of itself.
I built other libraries like that and they still fared (much) better. When you avoid 'shooting your optimizer in the foot' with virtual functions/function pointers/similar 'brick wall' indirections, a decent linker (supporting function level linking or even link time code generation) can pretty much discard most/all unused code from (statically) linked libraries. The worst, bloat-wise, possible ofense one can make is to mix template classes with virtual functions and dynamic_casts (this creates huge RTTI records as well as exposes your class names in the final binary).
If we don't like the inheritance structure, I can certainly remove it when porting.
'An' inheritance structure is not wrong in itself if it flows naturally from the problem domain and 'good' design rules, but 'hardcoding' the use of virtual inheritance and/or virtual functions (or even dynamic memory allocation and exceptions), when those are not actually necessary for all usage models, _is_ 'evil' (among other things, that's what makes std::streams the terrible failure that they are)... Any such design descisions that prevent even the best optimizers from removing unused functionality apriori fail the 'you do not pay for what you do not use' rule...
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.
Well it is actually not bad "in itself", to the contrary it is quite useful if not necessary in the most general use cases (like detecting algorithms from textual sources like HTML)...it becomes 'really bad' or 'downright evil' when it is the 'only' way to do it or the way that the library internaly does it...
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 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.
Great...but, since you seem to care about general efficiency issues (which makes me very happy ;) I must ask again, why Botan? ...because, of the libraries I've tested, it was the worst in this regard... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
participants (3)
-
Chad Seibert -
Domagoj Saric -
Sohail Somani