> I've already posted this one in the 6.0 implementation request thread 
>> and pose it here for further discussion. It shows how I've solved the 
>> issue of tweakable block ciphers so far. 
>>
>> You know, we have a patch page available to stage these things :) See 
> https://cryptopp.com/wiki/Category:Patch.
>
> I'll pair this patch with Threefish and Skein. (-> you don't get and need 
> tweakable block cipher without Threefish), so I'm asking if anyone is 
> objecting the design path I've chosen.
>
I can't comment on the design because I don't have enough experience with 
them.

I think there's a few things we need to get a firm grasp on before we move 
forward with a design change to avoid additional design changes. Remember, 
we are trying to minimize the major design changes because they require us 
to perform a major version bump. 

Here's some of what I think needs to be considered:

* Wagner, Rivest and Liskov. Tweakable Block Ciphers, 
http://www.cs.berkeley.edu/~daw/papers/tweak-crypto02.pdf
* Ferguson and the Elephant Diffuser used in BitLocker, 
https://css.csail.mit.edu/6.858/2012/readings/bitlocker.pdf
* Crypto++'s existing implementation of DESX
* Large block tweaks used in modes of operations, like XTS mode

Functionality like the PEM Pack will likely always be there because its 
> probably never going to be up-taken by the library.
>
> Crypto algorithms and crypto systems are a different story because they 
> are primary goals of Crypto++.
>
> I think the tweakable blockcipher class(es) are required for proper 
> integration of Threefish to reflect its unique properties and to allow easy 
> replacement of Threefish within UBI (Skein's mode for using Threefish)
>

Wagner, Rivest and Liskov's paper provides two logical design choices for 
tweakable block ciphers.

Crypto++ already implements an early tweakable block cipher in DESX (a.k.a. 
DES-XEX3), but I have not looked at it in detail.

So anything we decide on needs to be taken modulo (1) Wagner (et al) 
recommendations, (2) exiting implementations, and (3) future considerations.

Any objections or comments or comments regarding the design of the 
> tweakable block cipher class(es) and its helper classes as documented in 
> the first post of this thread?
>
> If not I'll start migrating Threefish and Skein around this design at 
> Sept. 20th (one week from now). From there on redesigns can still take 
> place, but will strongly upset me.
>

Maybe you should hold off for the time being.

Jeff

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