Hey, thanks for your reply, 1. is completely do-able I think. Updating the code. 2. Not sure what you mean by 'every single algorithm'. AFAIK, some of the algorithms don't support the required encryption mode (CTR) so don't know how feasible this will be. Also, how do I get your Threefish code :-) 3. The RNG interface is simply there to initialize the IV but isn't core to the code base. As it stands the user can choose to use 'any' RNG for generating 64 bit numbers. 4. Should be do-able
Ben. On Friday, January 9, 2015 at 4:59:50 PM UTC, Jean-Pierre Münch wrote: > > I forgot to mention this: > You might also be interested in the concept of sinks > <http://www.cryptopp.com/wiki/FileSink>, already implemented in Crypto++. > > BR > > JPM > > Am Freitag, 9. Januar 2015 17:57:28 UTC+1 schrieb Jean-Pierre Münch: >> >> Hey, >> >> the whole concept is really interesting and I would be willing to include >> it in my Crypto++ fork <https://github.com/DevJPM/CryptoJPM> (with some >> luck it will be part of the next official release afterwards), if some >> conditions are met. >> 1. It needs to be a complete drop-in replacement for std::fstream family >> of classes. >> 2. It needs to support every single algorithm Crypto++ has or will have >> (f.ex. you don't support my Threefish implementation), you may want to go >> away from constants for each cipher and replace it by function pointers >> (look at Crypto++'s HMAC class as an example) >> 3. You've got a RNG-interface. If you want this to be incorporated into >> Crypto++ directly the usual procedure is, that every function that needs >> random number receives a reference to a RNG of user's choice, so he could >> use his own, use X917C, use Fortuna (will be coming I hope) or use >> RandomPool. >> 4. All files must be put in the public domain. An "As is" disclaimer is >> ok (i guess) but any other restrictions (especially those who force users >> to reproduce something) are a no-go. >> >> If all these requirements are met it's very well possible that it can be >> put into (un)official releases. >> If you don't want it to be included, I recommend you to at least fulfill >> points one to three as otherwise onece you don't add algorithms any longer >> it may come the day where people decide they won't use it because it >> doesn't support their super-new implementation of the latest cipher. >> >> BR >> >> JPM >> >> Am Freitag, 9. Januar 2015 15:14:02 UTC+1 schrieb bhj.re...@gmail.com: >>> >>> Hi everyone, >>> >>> I am developing these wrappers <https://github.com/benhj/CryptoStreamPP> >>> around >>> Crypto++ for easy file stream creation. My hope is for them to be drop-in >>> replacements of std::fstream (although not quite, since stream operators >>> like '<<' are not yet supported). >>> >>> Perhaps somebody might find them useful. >>> >>> Cheers, >>> Ben. >>> >> -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
