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) McBits isn't a must-have, although it looks a lot easier to implement than standard Niederreiter or McEliece. 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. 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 (!). > > 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. BR JPM > Sent from my iPad > > 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)? 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 >> 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]. >>> 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] >>> <mailto:[email protected]>. >>> For more options, visit 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. >> --- >> 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. -- -- 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
