> What about go the whole hog and call it crypto++14 I get what you are saying, but I think it would confuse users. I think its best to avoid the confusion.
I was thinking Crypto++ NG but I struck it because it has a propensity to confuse users. And leaving the name with Wei seems like the right thing to do. The guy was good enough to give the source code away under a very permissive license. Don't try and take his name, too. (Plus, someone else already hijacked the name. See the related links page at http://www.cryptopp.com/wiki/Related_Links). Jeff On Friday, January 2, 2015 8:44:38 AM UTC-5, David Irvine wrote: > > What about go the whole hog and call it crypto++14 and modernise the > library completely to handle rvalue moves generic lambdas (to improve > readability of the vast template system) etc. where speed increases and > further safety would be included. Its a larger proposition but would > differentiate it enough? > crypto++14-XX where XX is the version etc. > > On Fri, Jan 2, 2015 at 1:39 PM, Jeffrey Walton <[email protected] > <javascript:>> wrote: > >> > Now to the naming: >> > I propose: Crypto++ 5.7.0 beta 1 (for current release) >> >> You might want to reconsider this. You should probably leave the Crypto++ >> name with Wei and come up with something new for your fork. At minimum, it >> will avoid confusing users. Changing the name also seems to be customary. >> For example, the recent fork of LibreSSL from OpenSSL. >> >> I can just imagine it now: a user says "I'm using Crypto++ 5.7" when the >> library is officially at 5.6.2 or 5.6.3. They won't understand the library >> was forked and the name was borrowed. >> >> Jeff >> >> >> On Thursday, January 1, 2015 5:11:09 AM UTC-5, Jean-Pierre Münch wrote: >>> >>> Hey everyone, >>> >>> Happy New Year. (2015) >>> >>> First of all: >>> I've got some things finished. >>> The current state of the library is zipped and appended. >>> Please also read the changelog (the other appended file). >>> Highlights of this version of Crypto++ (we'll discuss shorty about the >>> naming): >>> -Inclusion of the patch for HMAC, HMAC now works for SHA-3 and Ciphers >>> without BlockSize / BLOCKSIZE-constant >>> -Changed ECIES, you can now use other hash-functions than SHA-1 for >>> keystream generation. >>> -Added framework for Tweakable Block Ciphers, they're a specialization >>> of Block Ciphers with tweakable properties >>> -Implemented Threefish with all three key sizes as tweak able block >>> ciphers >>> -Implemented Skein on top of Threefish >>> >>> Known Issues: >>> -Variable block sizes are not supported by Crypto++ and if you use them >>> you can't use ayn of the "good" modes (CTR & co) -> no generic Threefish, >>> only Threefish_256,.. >>> >>> Now to the naming: >>> I propose: Crypto++ 5.7.0 beta 1 (for current release) >>> and incrementing the value after beta to reflect number of releases >>> already done >>> >>> @jeffrey: >>> I'm not sure if I will incorporate the Cross-Compile patches. >>> I will look into them and decide afterwards. >>> Concerning the license of FHMQV: please place the implementation in the >>> public domain. All files in Crypto++ are placed in the public domain. >>> I think I will incorporate the PEM-Pack, maybe even the ECIES >>> Bouncy-Castle-Pack. >>> >>> @Mouse: >>> I've already patched the cpu.h file but somehow I get errors as I try to >>> patch the GNUMakefile. Could you please post the 5.6.2 makefile with your >>> changes applied? >>> Concerning PQ-Crypto: This is one of the last things I will include. But >>> if I include McEliece, I'll use Kobara-Imai's GAMMA-Conversion ( >>> http://www.e-reading.link/bookreader.php/135832/Post_ >>> Quantum_Cryptography.pdf, page 142) with a nice decoding method I found >>> in another paper, they use it for HyMES (http://www.cayrel.net/IMG/ >>> pdf/hymes_cw_buescher_meub.pdf). >>> >>> Current roadmap looks like this: >>> - Redesign PBKDF interface for long-term compability with PHC winners >>> - apply various patches to Crypto++ (PEM, ...) >>> - implement BLAKE2 family >>> >>> So there are some questions open I need to ask you: >>> - Do you want Skein-MAC? >>> - Do you want BLAKE and BLAKE2 or just BLAKE2 ? >>> >>> And I've got some work (sorry for that) for you: >>> Please test the implementation of Threefish and Skein for Correctness on >>> Big-Endian-Platforms as I don't have access to any of them. >>> Test vector check routines are appended. >>> Please also test my PKCS 1 v2 RSA signature scheme implementation for >>> correctness. >>> >> -- -- 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.
