Hey there, 5. I think that some sort of authentication would be a good idea. Not sure where to start with it though. Will try and get the function pointer idea up to speed first. 6. Ok, will have a look at your new PBKDF2 interface. (Might we also look at scrypt?) 7. Would be great to specify our own cipher / mode pair. AFAIK, XTS (for example), -- which would be fantastic -- is not yet supported but at least being scalable to a future update that might support it sounds like a wise idea.
Ben. On Monday, January 12, 2015 at 4:04:07 PM UTC, Jean-Pierre Münch wrote: > > Hey Ben, > > the current state of the fork is hosted on Github > <https://github.com/DevJPM/CryptoJPM>: https://github.com/DevJPM/CryptoJPM > It will contain many new things that were too new for 5.6.2 (like > Threefish). > First: if you want to use CTR with any cipher do something like this: > > class CryptoFStream_Base > { > // some worker functions > protected: > CTR_Mode_ExternalCipher m_Instance; // construct this using GetCipher() > BlockCipher& GetCipher() =0; > }; > > template<class CIPHER> > class CryptoFStream : public CryptoFStream_Base > { > // a constructor > private: > CIPHER m_Instance; > BlockCipher& GetCipher() {return m_Instance;} > }; > > This will enable you to let the user specify the algorithm. > Another few question: > 5. Do you will support some sort of authentitication (HMAC, VMAC, ...)? / > Authentiticated mode (GCM, EAX, ...)? > 6. You may also want to take a look into the new Interface for PBKDFs I > give in the fork as it is more versatile for coming ciphers. > 7. Will it be possible to specify your very own cipher / mode pair? (like > somebody took the work to implement XTS / OCB / ... and wants to use it?) > (as long as it uses IVs)? (Using some construction like the above with > abstraction to the SymmetricCipher interface?) > > BR > > JPM > > Am Montag, 12. Januar 2015 10:30:47 UTC+1 schrieb [email protected]: >> >> 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 [email protected]: >>>>> >>>>> 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 [email protected]. 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
