Early std.crypto

[Regan Heath]

On Tue, 22 Nov 2011 16:16:21 -0000, Piotr Szturmaj <bncrbme at jadamspam.pl>
wrote:
> 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.

Ultimately I think it comes down to the question of whether we want/expect  
to have native D implementations of things, or whether certain  
projects/libraries will always be too large to maintain in D.  The answer  
to that, comes down to whether we think D will gain a sufficient user base  
to include enough people able to produce and maintain those libraries, or  
.. whether D will gain sufficient importance that existing developers in  
those libraries produce D bindings themselves.

Under the assumption that D will gain sufficient traction it makes sense  
to start implementing what we can in D, now.  At the same time, in order  
to gain that traction D needs bindings to existing libraries.  The latter  
is probably a slightly higher priority at present, but it's not a reason  
not to develop native D implementations at the same time.

If we're lucky having initially incomplete native D implementations will  
actually encourage people with those skills to contribute to D, as there  
is a certain sort of satisfaction in doing so.

>> 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.

I wrote those as a crypto novice and haven't had any cause to advance
since then.  There are some obvious things to watch out for, for example
the hashing routines should not make copies of the input data, or if they
do they should 'scrub' that memory clean afterwards.  But, that's the
limit of my knowledge, there are bound to be more advanced problems and
solutions that I'm simply not aware of.

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/