Boost logo

Boost :

From: Sergey (salaev_at_[hidden])
Date: 2007-03-22 18:10:18


Hi, All!
I've decided to participate in Google SoC(http://code.google.com/soc/) and try to make
basic cryptographic library good enough to be ready for review in
August.
I think that any cryptographic function (encryption/decryption,
hashes) can be represented as operation on data stream and sticked to following interface:

class crypt_something {
        void init ( <algorithm-specific initialization parameters
                 here, like encryption key> );
                 
        ~crypt_something(); //performs secure cleanup
        
        //process given data
        //return value: iterator pointing to first unaffected element
        //in output buffer.
        template<class iIt, class oIt>
        oIt process(iIt begin, iIt end, oIt out);

        //estimates amount of data to be written when calling process()
        //with given arguments.
        //return value: maximum number of *iIt elements that can be written by
        //next call to process
        template<class iIt>
        std::size_t process_outsize(iIt begin, iIt end) const;

        //flushes internal buffer
        //next call to process() will start new calculation
        //return value: iterator pointing to first unaffected element
        //in output buffer.
        template<class oIt>
        oIt flush(oIt out);

        //estimates amount of data to be written when calling flush()
        //with given arguments.
        //return value: maximum number of *oIt elements that can be written by
        //next call to flush
        template<class oIt>
        std::size_t flush_outsize() const;
};

Later any algorithm with this interface can be used as template
parameter for adapter (for example, to Boost.Iostreams - it can be
used assuming we use 'secure' allocator)
What do you think, what functionality should Boost.Crypto include?
What interfaces are fast and useful(except for iterators in code
above)?
Criticism is welcomed :)

Sergey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk