|
Boost : |
Subject: Re: [boost] [GSoC] Checks and hashes proposal
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2011-04-08 14:05:34
On Fri, Apr 8, 2011 at 07:19, Pierre Talbot
<pierre.talbot.6114_at_[hidden]> wrote:
>
> I wrote my proposal and posted it on the GSoC website, any feedbacks or
> comments are welcomed.
>
You mix four distinct things in one: ISBN/EAN/VISA/etc, for catching
human-entry errors; hash functions as in hash tables, which only care
about distribution; checksums like CRC32, for catching data
transmission errors; and cryptographic hash functions, the only ones
useful against malicious adversaries.
The summer is short, and the boost process is long. I'd encourage you
to look only at the first category. As you mention, it's the one with
the fewest alternative libraries, so you won't have to prove
competitive performance and such, and there are no real security
issues to deal with.
Also, I'd like to see some sketches of interfaces. What do you expect
user code to look like?
A few specifics:
"This kind of drama situation can be avoided by storing encrypted passwords."
Encrypted means cyphers, not hashes. You want digests or MACs of
passwords, not something reversible.
"Write, test and document the hash functions MD5 and SHA-1 256 bits."
There's no such thing as 256-bit SHA-1. Do you mean SHA-256, from "SHA-2"?
Also, MD5, SHA-1, and SHA-2 are implemented in my hash library:
<http://svn.boost.org/svn/boost/sandbox/hash/boost/hash/md5.hpp>
<http://svn.boost.org/svn/boost/sandbox/hash/boost/hash/sha1.hpp>
<http://svn.boost.org/svn/boost/sandbox/hash/boost/hash/sha2.hpp>
~ Scott
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk