Hello,
Does this mean you will be converting the source-code of Botan to Boost standards or you are going to wrap it?
1. If it is conversions two issues may rise: a) License Botan is licensed under BSD license with is different from Boost and all the code you will write for boost would not have correct license. b) Conversion to Boost means fork... How do you expect to synchronize changes in two libraries and most important security updates.
This means lots of work in the live cycle of Boost.Botan
I'll fork it, as stated in my proposal (which I sent sometime after the abstract). It'll be relicensed under BSL. As for synchronization, this will have to be done by hand (which I will do for some time).
Additional points:
- Botan uses GNU gmp library licensed under LGPL... Does it fit to Boost licensing guidelines?
It doesn't require gmp and is perfectly capable of working without it. It's available as a plugin, but a default implementation is already included.
- I think that you should be really specific what would be the advantage of using Boost.Botan library over original Botan one or OpenSSL that Boost.Asio uses.
Here are some: * Tighter integration with Boost (ASIO, and possibly iostreams) * Some functions are considerable faster (such as RSA, which the maintainer purports to be several times faster than OpenSSL. SHA-1 is SSE2 optimized). * There is plugin support for OpenSSL, so ASIO would be modified to use the plugin system (which would use the default implementation or OpenSSL).
You might want to consider adding some discussion to your proposal about the crypto library in the vault. What features are in the vault Crypto that might be useful? That aren't useful? Why do you feel that Botan is a better starting point.
The crypto library in the vault contains mostly hash algorithms, which Botan already contains (and some of them e.g. SHA-1 have a SSE optimized version). And Botan contains better documentation and testing. Also, Botan was engineered mostly by a security expert, meaning it is likely to be more secure. It is also being maintained, so security and feature patches will be made.
Your proposal is very ambitious! IMHO, that's not doable in full over the summer. If you trimmed it down into a more focused feature set (for instance replacing SSL in ASIO, or adding TLS to ASIO) it would give you a more realistic chance to finish what you are suggesting.
It is very ambitious! But as I say in my draft, it'll be done in two parts. I don't think that porting is unrealistic for the summer part of the project. Many thanks for the feedback, Chad Seibert _________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
"Chad Seibert" <chadseibert@live.com> wrote in message news:BAY113-W109DEA4654FE7B53F0F6F5D3160@phx.gbl...
Also, Botan was engineered mostly by a security expert, meaning it is likely to be more secure.
Hopefully coding skills also matter in the Boost community and sadly Botan leaves a lot to be desired in this regard. 'Hacking up' an example to test a real use case of a simple RSA+SHA256 message verification with the public key stored in static memory gives the following results: (MSVC++ 9.0 SP1, Botan built with default parameters (makefile only changed to use link time code generation)) - project with an empty main : 40.448 bytes - project with the following Botan code int main() { unsigned char const in_memory_key[] = "an invalid key" ; unsigned char const msg [] = "a dummy message"; unsigned char const sig [] = "an invalid sig"; LibraryInitializer init; DataSource_Memory botan_in_memory_key( in_memory_key, _countof( in_memory_key ) ); std::auto_ptr<X509_PublicKey> key( X509::load_key( botan_in_memory_key ) ); RSA_PublicKey* rsakey = dynamic_cast<RSA_PublicKey*>(key.get()); std::auto_ptr<PK_Verifier> verifier( get_pk_verifier( *rsakey, "EMSA1(SHA-256)") ); return verifier->verify_message(msg,sizeof(msg),sig,sizeof(sig)); } ...: 1.092.096 bytes (yup, over a megabyte!) - an equivalent project only using LibTomCrypt+LibTomMath (mentioned here http://permalink.gmane.org/gmane.comp.lib.boost.devel/202443): 84.480 bytes 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?)...
It is also being maintained, so security and feature patches will be made.
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?
-- "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
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. -- Sohail Somani http://uint32t.blogspot.com
"Sohail Somani" <sohail@taggedtype.net> wrote in message news:hpv952$89d$1@dough.gmane.org...
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
I am not 'lucky' nor write 'such simple applications': one can, for example, write fairly complex DSP applications that, as such, have nothing to do with cryptography but can use a ready digest-verification implementation for example for licence file verification...It is reasonable to expect that such a simple use case does not suddenly double your binary size..with cryptographic code that you never ever use. -- "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
On 4/14/2010 11:21 AM, Domagoj Saric wrote:
"Sohail Somani"<sohail@taggedtype.net> wrote in message news:hpv952$89d$1@dough.gmane.org...
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 I am not 'lucky' nor write 'such simple applications': one can, for example, write fairly complex DSP applications that, as such, have nothing to do with cryptography but can use a ready digest-verification implementation for example for licence file verification...It is reasonable to expect that such a simple use case does not suddenly double your binary size..with cryptographic code that you never ever use.
So let me understand: you created a program from a use case, did not use Botan's capability to include only what you need, and then you said that the resulting binary was too big? I think you should try again but only include what you need for your use case. I can believe that you would like to keep the size down but I think you should do a proper test.
"Sohail Somani" <sohail@taggedtype.net> wrote in message news:hq4op8$u3r$1@dough.gmane.org...
So let me understand: you created a program from a use case, did not use Botan's capability to include only what you need, and then you said that the resulting binary was too big? I think you should try again but only include what you need for your use case. I can believe that you would like to keep the size down but I think you should do a proper test.
Well that was exactly the problem I tried to show...the only way to make Botan 'not as big' (even with powerful linkers like the one provided by MSVC 9.0) is to manually configure it to exclude parts of itself...this always points to coupled code that uses some sort(s) of dynamic/runtime dispatching which prevents the compiler from detecting what is actually used and what isn't...
From this I can apriori know that such a library would fail the 'efficiency' test even if I exclude all but one algorithm from the build: I will still get all the runtime-goodies that dynamically dispatch always to the one and only algorithm I use...
-- "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
On 12/04/2010 7:52 AM, Domagoj Saric wrote:
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... -- Sohail Somani http://uint32t.blogspot.com
participants (3)
-
Chad Seibert -
Domagoj Saric -
Sohail Somani