Boost logo

Boost :

Subject: Re: [boost] [GSoC] Distinct check, hash and block cipher library ?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2011-04-03 12:23:52

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Pierre Talbot
> Sent: Saturday, April 02, 2011 10:08 AM
> To: boost_at_[hidden]
> Subject: [boost] [GSoC] Distinct check, hash and block cipher library ?
> Hello everyone.
> My name is Pierre Talbot and I'm a Belgian student who'd like to work with
> Boost community in the context of GSoC, and if it's possible I hope much
> I'm also (note the "also") interested in the checks and hashes projects.
> I tried to code an interface of the checks and hashes projects and
actually I
> thought we could split this project into two distinct projects. Actually,
the checks
> and the hashes are different in many ways. Indeed I though we could
> them :
> the check project :
> - Control redundancy check : CRC 16/32/64
> - Checksums : Fletcher, Adler, Luhn, and Verhoeff algorithm
> - Credit card checks : VISA, Mastercard, AMEX, ...
> - International number : ISBN, ISSN, EAN, IBAN, ...
> the hash project :
> - MD family : MD5, MD6 (optionnal).
> - SHA-1 and SHA-2 family : SHA-224, SHA-256, SHA-384, SHA-512
> - SHA-3 as Black or Groslt,...
> - Tiger
> - RIPEMD family (RIPEMD-128, RIPEMD-160, RIPEMD-256)
> - RadioGatun
> - Very Smooth Hashing (VSH)
> - Optionnal(?) : Non cryptographic hash function
> Why so many different algorithms ? I think the users need a larger range
> hashing functions. Some hashes are quicker, lighter or more resistant to
> collision. Others are better for the micro-controllers, and some systems
> other hashes than SHA-1 or MD5.
> Why split one project into two distinct ones? Because I think that in the
> context, these two projects are too much work for a single person to
provide a
> complete documentation. Indeed if you think it's impossible to split it, I
> that the hashes should be limited to the SHA-1/2 and MD5 algorithms
> there are the most widespread). Furthermore, the documentation of the hash
> project should be even more complete if we want to provide details about
> speed/ usage of an algorithm.
> I also want to discuss the possibility of building a Block Cypher
Algorithm Library.
> Firstly I would like "to share a plan of a library" :
> - The three 128 bits algorithms recognized by ISO : AES (Rijndael),
> Camellia, and SEED.
> - Two very powerful algorithms : Blowfish (currently resistant to
> cryptanalysis) and Twofish (finalist to the AES contest).
> - Serpent (finalist to the AES contest).
> - The old DES and Triple-DES algorithms
> I read about the timing attacks on this kind of algorithms. In the first
place, I
> think we could ignore those attacks because the attackers need to know
> about the server configuration (processor, amount of RAM, ...).
> They also need to know the precise time of each algorithm's instruction in
> processor. So this attack needs to be carried out in a "local context"
> and not on the internet. (Considering that packets have a variable
> It's for these reasons that I think these attacks are highly theoretical.
I think we
> should improve this library later.
> What do you think about all of this ?

It would be possible to split into two projects. I am certainly very keen
to have a project that really does get finished, but the scope is 'elastic',
so this should be possible.

One caution I would give is that Boost library stuff must be under the Boost
entirely free license, and not subject to patent problems.

There should be detailed acknowledgement of any copyright or patent issues
in the docs (this may be quite a lot of work).

I fear some of the hashes may not be doable for this reason. GPL or LGPL is
almost certain to rule algorithms out.

I am also not willing to mentor two projects (or a hashes only project), so
you will need to find someone else.


Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
+44 1539 561830  07714330204

Boost list run by bdawes at, gregod at, cpdaniel at, john at