On Thu, Sep 10, 2015 at 2:59 PM, Jean-Pierre Münch <
[email protected]> wrote:

> Am 10.09.2015 um 10:58 schrieb Jeffrey Walton:
>
> We have a roadmap at https://cryptopp.com/wiki/Roadmap. There's a lot of
> planned additions.
>
> We may want to add a possibility to support variable block sized block
> ciphers (like Rijndael and Threefish) requiring different code paths
> (template specializations?).
>

Yes. And we want an AES-NI option for Rijndael.

> We now need to start accumulating the implementations. I have some of
> them, like HMQV, FHMQV and the NIST_DRBG's, but I need the others. If you
> have something to contribute, then please share it.
>
> I can provide fully featured Skein (excluding Skein-PRNG and Skein-PBKDF)
> and a Threefish implementation,
>

Great!


> ...but there are issues we need to overcome first, including the following
> (already in the roadmap):
>
>    - A design of a TweakableBlockTransformation class. I can provide a
>    proposal.
>    - A design of a KDF / KBKDF class.
>
> Please do so, and let's review it.


>   (1) Copyright assigned to crypto++ project.
>
> no problem.
>

:-)


>   (2) Implementations must have test cases.
>
>


> I haven't done it yet for Threefish / Skein but I think I can adapt my VS
> Unit Test for this. There quite some testvectors for the two algorithms out
> there.
>

Ideally we want to use the existing test-vectors, and generate our own only
when there's nothing reliable/trustworthy in the field.


> Dear Jeffrey:
>
> Is there anything I could do to get BLAKE2 moved from "Planned
> Features" to "Crypto++ 6.0"? We can satisfy the administrivia and test
> vectors requirements, that's for sure. Anything else deterring you
> from adopting BLAKE2?
>
> Regards,
>
> Zooko
>
> That was me in fact. I just put it to "planned features" as we didn't have
> anyone (yet) providing the necessary code and I had no direct intentions in
> providing it as soon as 6.0 (mainly because the SSE code was broken for me
> on VS2012).
> I'll add a few sentences better explaining that anything listed as
> "planned" will be likely implemented at some point by the maintainers, but
> any secure provided implementation can be provided to let the feature make
> it into the next assemble-stage release.
>

As we have time before 6.0, there's no reason not to include BLAKE2.


> One note from me: I forgot to append "(-MAC)" to the Blake2 part. Will you
> also provide us with the MAC functionality? (to not allow Skein to be
> "better"?)
>

:-)

-- 
Regards,
Mouse

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