1. My opinion - yes to BLAKE2 and Skein, not sure about McBits and PHC, abstain 
wrt. crypt and scrypt.

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...

Sent from my iPad

> On Jul 2, 2015, at 17:27, Jean-Pierre Münch <[email protected]> wrote:
> 
> 
> 
>> Am 02.07.2015 um 23:21 schrieb Mobile Mouse:
>>> On Jul 1, 2015, at 20:35 , Jeffrey Walton <[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 (?)
> 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].
>> 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.

-- 
-- 
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.

Reply via email to