Early std.crypto

Piotr Szturmaj bncrbme at jadamspam.pl
Tue Nov 22 08:16:21 PST 2011


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.


More information about the Digitalmars-d mailing list