[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 the Boost community in the context of GSoC, and if it's possible I hope much more. 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 address 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 of hashing functions. Some hashes are quicker, lighter or more resistant to collision. Others are better for the micro-controllers, and some systems use other hashes than SHA-1 or MD5. Why split one project into two distinct ones? Because I think that in the GSoC 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 think that the hashes should be limited to the SHA-1/2 and MD5 algorithms (because there are the most widespread). Furthermore, the documentation of the hash project should be even more complete if we want to provide details about the 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 details about the server configuration (processor, amount of RAM, ...). They also need to know the precise time of each algorithm's instruction in the processor. So this attack needs to be carried out in a "local context" and not on the internet. (Considering that packets have a variable latency). 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 ? Thank you very much for reading me. Pierre Talbot.

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Pierre Talbot Sent: Saturday, April 02, 2011 10:08 AM To: boost@lists.boost.org 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 more. 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,
and the hashes are different in many ways. Indeed I though we could address 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 of hashing functions. Some hashes are quicker, lighter or more resistant to collision. Others are better for the micro-controllers, and some systems use other hashes than SHA-1 or MD5.
Why split one project into two distinct ones? Because I think that in the GSoC context, these two projects are too much work for a single person to
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 (because 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
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
the the checks provide a think the place, I details the
processor. So this attack needs to be carried out in a "local context" and not on the internet. (Considering that packets have a variable latency). 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 --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
participants (2)
-
Paul A. Bristow
-
Pierre Talbot