bcs wrote:
On 11/20/2011 08:10 AM, Piotr Szturmaj wrote:
bcs wrote:
On 11/04/2011 04:27 AM, Piotr Szturmaj wrote:
bcs wrote:
Are you re-implementing the function kernels your self or are you
using
an existing implementation? Given what I've heard about things like
side-channel attacks using processing times to recover keys, I'd
rather
not see Phobos use anything written by less than the best expert
available.
Until now, I implemented some hash functions. There are no branching
instructions in their transform() routines, so theoretically processing
time is independent of the function input.
From my very incomplete memory I found the source I was looking for (I
googled for "aes interperative dance") here
http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html
Look for "Foot-Shooting Prevention Agreement" in one of the images
~20-25% of the way down.
tl;dr; It mentions "cache-based, timing, and other side channel
attacks". Unless you can explain to me what those are, in painful
detail, I don't think we should trust you to avoid them. Get a good
vetted C implementation and wrap it with a nice D API and call it a day.
>
Sorry for late answer.
Np, but I still have a number of concerns:
What is the advantage to implementing the kernels of any of these
functions in D? Will the code be faster? Smaller? More secure? More
maintainable? (On the other hand, the value of doing the API code in D
goes with no debate.)
The first advantage is that Phobos will be independent of any crypto
libraries. The second one is that there will be no licensing issues. All
crypto code will be under Boost license like the rest of Phobos.
How many people in the D community have the experience and know-how to
review the security of an implementation? If there are less than 2 or 3
people who can do that, can we afford to include native kernels? We
can't have just one and if we have only two and one leaves for some
reason the code becomes un-maintainable for lack of a reviewer. *I*
wouldn't be comfortable with less than about 4-5.
I know Regan Heath who wrote some crypto code for Tango. Also, I suspect
that D _will_ gain more (crypto) contributors, especially after joining GCC.
Minimum number of contributors/reviewers requirement in open-source
project is at least unfortunate in my opinion. Nevertheless, I respect
your thoughts. But imagine what could happen if Walter waited for
contributors instead of starting D project on his own?
Please realize that we do not implement every possible crypto algorithm
at once. We need to start with something like hashing, then add
encryption and other cryptographic primitives.
