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