Hi Everyone, recently we had some issues with the release of Crypto++ 5.6.3 as you all may have noticed. As one result of this we have improved our testing systematics.
I *think* and am proposing that we should (additionally to our awesome roadmap) add a list of priorities with justification so people see why they won't get fast ECC or PQ crypto soon - there are more pressing issues. As for the placement, we'd put this onto an adequate page in the wiki. (maybe with some nicer formatting than I have below) This would mean something like the below example. BR JPM Priorities: #1 improve testing code to cover all standard operations in all primitives // need to stand until next release, we can't have it another time that we need to fix the distributed library twice #2 implement BLAKE2 // was recentely standardized, is likely to be one of the most widely used hash functions, easy to implement #3 implement Edwards / Montgomery curves (via hack = transformation to Weierstrass form) // we're late on this one and should at least support the curves so we're ready to roll EdDSA-448 when it sees widespread adaption #4 implement NIST approved DRBGs, e.g. HMAC-DRBG and AES-CTR-DRBG (is there another one I forgot which we need to do?) // our current RNGs lack approval as they are outdated as of now and we need a replacement so people can feel safe #5 implement Threefish // we need this for Skein and a large block size cipher may be very useful to many people, will make us re design the handling of block sizes for block ciphers and will force us to introduce a tweakable transformation, easy to implement #6 implement Skein (hash only) // fast versatile hash function, suited especially as XOF, rather easy to implement and provides a highly reviewed alternative to SHA-3 (if it's too slow) #7 Implement EdDSA (for all curves) // likely going to be the next big signature standard, we have some time on this, the standards aren't even finished yet, may require us to change the Integer class partly #8 Implement Fortuna // Fortuna is better than the NIST DRBGs but not approved, thus not a high priority, will likely force us to redesign the RNG interface and will likely require a lot of work if we want to harvest entropy ourselves #9 implement Edwards / Montgomery curves (properly using native laws) // will mainly bring speed improvements, not pressing as the security is already guaranteed by our Weierstrass code, may be difficult to do properly #10 Implement other fancy Skein features (MAC, KDF, Stream Cipher, ...) // nice features to have, other issues are more important and pressing, will likely be done along with the main Skein implementation, may force us to revisit the KDF interface and define a more standard one, we already have proper primitives for all the proposed jobs -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com. 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 cryptopp-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
