Re: [boost] [gsoc][student] Proposal

Subject: Re: [boost] [gsoc][student] Proposal
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2009-03-20 14:38:08

On Fri, Mar 20, 2009 at 6:49 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> Kasra wrote:
>>
>> Hi,
>>
>>> Why the C-like interface?
>>> Why not work with iterator, or better, ranges?
>>
>> The reason for that is there are multiple layers of encapsulation in the
>> library.
>> block_cipher_type is the core algorithm, which is part of the lowest-level
>> of the API.
>> However, there is a block_cipher wrapper "block_cipher" that provides C++
>> semantics (iterators, ranges, specialised "crypto_buffers" and etc).
>
> You cannot express the iterator version in terms of the pointer version.
> Genericity doesn't work that way.
>

Well, actually you can: to implement a secure[1]  and efficient crypto
library, you want to write the algorithm in assembler or some very low
level C (think compiler intrinsics), which pretty much means you have
to deal with buffers of bytes.

On the other hand it doesn't means that the hole buffer to be
encrypted/decrypted must be provided at the same time: any decent
crypto library will allow chaining of non consecutive buffers as if
they were a contiguous buffer. See for example the EVP layer of
OpenSSL.

On top of such an interface you can layer a generic library: if a
trait that tells you if a range represents a continuous buffer, you
can directly pass it to the byte level layer, otherwise you copy a
chunk of the range in a temporary buffer, encrypt it, then get to next
chunk untill the end of the range (using a small fixed buffer means
you do not have to do any dynamic allocation and it stays in cache).

Even with the copy I think it will still be much faster than a fully
generic algorithm (modulo heroic compiler optimizations).

You can optimize it further if you know if a subset of the input range
is contiguous (for example in a deque), using segmented iterators.
Handling both input and output segmented iterators eficiently is not
trivial but doable.

[1]: you really want to have a good idea of the instructions your
library compiles to, to prevent side channel attacks.

> You write the algorithm generically, then you can have specific cases.
> You don't build genericity on top of specific cases.
>

Hum, there are many highly generic linear algebra c++ libraries that
do exactly that calling BLAS and friends for specific cases.

-- 
gpd