On Jul 3, 2015, at 6:08 , Jean-Pierre Münch <[email protected]> wrote: > Am 03.07.2015 um 03:33 schrieb Mobile Mouse: >> 1. My opinion - yes to BLAKE2 and Skein, not sure about McBits and PHC, >> abstain wrt. crypt and scrypt. > Sorry forgot two (three) on my list: > ChaCha (we already have salsa20, so shouldn't be too hard) > Poly1305 > StreamCipher + Poly1305 (AEAD cipher, with stream cipher templatizable)
Oh yes, absolutely. All of the above would be welcome additions. > McBits isn't a must-have, although it looks a lot easier to implement than > standard Niederreiter or McEliece. > Well, it would be nice to have something of that ilk… :) > I'd do Skein (+ Threefish as underlying construction), but it's inconvenient > for me at the moment, I'll go through the my CryptoJPM files and propose a > merge request on this list for the Skein+Threefish (Skein: full packet, hash, > mac, KDF). ETA: September '15, (as soon as there's a Skylake R13) > I'll get Visual Studio 2015 around the same time and will see if I can fix > the SSE related errors occurring with VS2012 (meaning I can provide scrypt + > BLAKE2 family of MAC & hash). > I think it'll also be possible to me to dive into the Salsa20 code and adapt > it for ChaCha. > Perfect! You’re the man! :) > I think as soon as PHC has winner(s) (Q3 '15?), we should implement them, > because they'll be (far) better than (even) scrypt and bcrypt and our current > only choice PBKDF2 (!). :-) Let’s wait till the winner is picked, and see what it looks like? >> 2. Yes, it is Kalyna (Ukrainian vs Russian pronunciation :). Timing attacks >> could probably be mitigated - the logic of doing so is reasonably >> well-known... Also, I personally find cache-timing attacks rather >> exaggerated, for symmetric ciphers at least. Now, AES has a distinct >> advantage here, because Intel put it in hardware - good luck timing cache >> :). Kalyna or any other software-based implementation wouldn't be so lucky, >> so more work for us, and worse performance… > Again, I certainly won't implement it. If you can implement it securely I > think we can include it as it's the libraries aim to provide as many > algorithms as possible - in a high quality manner. OK, when I have time I’ll look at both Kalyna and Grasshopper. >> On Jul 2, 2015, at 17:27, Jean-Pierre Münch <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> >>> Am 02.07.2015 um 23:21 schrieb Mobile Mouse: >>>> On Jul 1, 2015, at 20:35 , Jeffrey Walton <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> > I oppose adding Cmake support. I have it in one of my projects at work, >>>>> > and it’s nothing short of nightmare. >>>>> >>>>> OK, points taken. >>>>> >>>>> How do you feel about providing it at the Patch page >>>>> (http://www.cryptopp.com/wiki/Category:Patch >>>>> <http://www.cryptopp.com/wiki/Category:Patch>)? This way, its available >>>>> to those who want it, but it falls into the "provided, unknown quality, >>>>> and maybe not maintained" category. (This assumes we will actually get >>>>> our hands on a CmakeList.txt :). >>>> >>>> My concern is that if it is there - a bonehead is bound to pop up that >>>> would create something useful and make it dependent on cmake. >>>> >>>> Repeating myself - there are enough of useful things that are missing to >>>> inundate this project with something of adverse (IMHO) usefulness. >>> A short list ?: >>> Skein >>> BLAKE2 >>> bcrypt >>> scrypt >>> McBits <https://eprint.iacr.org/2015/610.pdf> (?) >>> PHC-winner(s) (TBA) >>>> >>>> For example, how about adding support for Kalina block cipher? >>>> https://eprint.iacr.org/2015/650.pdf >>>> <https://eprint.iacr.org/2015/650.pdf>1. It think it's "Kalyna". >>> 2. Who should implement this? I certainly couldn't. The problem with this >>> cipher is that it is AES-like meaning we (may) have to fear cache-timing >>> attacks, which have been mitigated for AES, but for Kalyna? I think we >>> could implement, but maybe we shouldn't because chances are we're getting >>> it wrong (only speaking for myself though). >>> >>> BR >>> >>> JPM >>> >>>> -- >>>> -- >>>> You received this message because you are subscribed to the "Crypto++ >>>> Users" Google Group. >>>> To unsubscribe, send an email to >>>> [email protected] >>>> <mailto:[email protected]>. >>>> More information about Crypto++ and this group is available at >>>> http://www.cryptopp.com <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] >>>> <mailto:[email protected]>. >>>> For more options, visit https://groups.google.com/d/optout >>>> <https://groups.google.com/d/optout>. >>> >>> -- >>> -- >>> You received this message because you are subscribed to the "Crypto++ >>> Users" Google Group. >>> To unsubscribe, send an email to >>> [email protected] >>> <mailto:[email protected]>. >>> More information about Crypto++ and this group is available at >>> http://www.cryptopp.com <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] >>> <mailto:[email protected]>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. > -- -- 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.
smime.p7s
Description: S/MIME cryptographic signature
