Communication / statement of priorities for library development

[Jean-Pierre Münch]

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

[Jeffrey Walton]

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

Good observation; I agree 100%.

What do you suggest we do? Where are the gaps, and how can they be closed?

Jeff