Hey there, as soon as you look into the code you may find the files "scrypt.h" and "scrypt.cpp" which do implement scrypt, although they don't pass test-vector-checks yet. The very interesting concern is the PHC <https://password-hashing.net/> that will enable the user to use f.ex. Argon once it's implemented (in Crypto++?).
The reason that I think blocks the introduction of XTS into Crypto++ is that it's not portable enough. It needs 128-bit blocksizes which only most ciphers supply (esp. Threefish doesn't) as it operates on GF(2^128). BR JPM Am Dienstag, 13. Januar 2015 11:15:08 UTC+1 schrieb [email protected]: > > 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.
