On Fri, Mar 20, 2009 at 6:49 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> 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

On Sat, Mar 21, 2009 at 3:36 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:

Giovanni Piero Deretta wrote:

...

On Fri, Mar 20, 2009 at 6:49 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:

...

...

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.

uBLAS has its own generic implementation for everything it provides. It can only call BLAS in specific cases, as you say: it's only a specialization.

You can specialize generic code, but you cannot build a generic implementation from a specialization.

Except when you can, if you can reduce all generic cases to a few specialized cases. See my previous email. The key here is that a generic crypto algorithm is only generic on the range type, not on the value type: all crypto algorithms always work on ranges of bytes (generating a range of bytes from a generic range of objects is completely orthogonal and best left to a serialization library). In fact to get decent performance, all crypto algorithm implementations I know work on contiguous chunks of bytes (you do not need the whole range to be contiguous, but at least parts of it should be). There is little or no gain in making such an implementation generic. On the other hand, writing a range generic interface on top of such a library would be useful and relatively simple. Again, look at the OpenSSL EVP layer as a good low level non-generic[*] crypto interface -- gpd