> There's probably a ton of other stuff that I've forgotten and my > colleagues will remind me about.
There's BLAKE2. It already has mature and widely-used source code, including multiple independently-written portable C implementations, and Bill Cox has offered to integrate those into openssl: https://mta.openssl.org/pipermail/openssl-dev/2015-June/001791.html In light of the previous conversation and the way it ground to a halt, I would ask that we do the simple, easy thing now and don't re-raise any of the bike shed questions, so: * Don't implement the parallelized versions (BLAKE2bp and BLAKE2sp). * Don't change the names of the algorithms from "BLAKE2b" and "BLAKE2s" (they are already widely known under those names). * Don't integrate any of the optimized asm implementations, just a single portable C implementation. There. That ought to do it! The previous thread — in which I argued that BLAKE2 is worth supporting — starts here: https://mta.openssl.org/pipermail/openssl-dev/2015-June/001688.html Since I wrote that post, BLAKE2 has been promoted from Internet Draft to RFC. It doesn't have its RFC number yet but should get one any day now: https://datatracker.ietf.org/doc/draft-saarinen-blake2/ Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com — Freedom matters. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
