Being way too busy now, I cannot comment more on the proposed design yet - need more time. My only comment now is: as tweakable cipher construct is (or at least can be) based on a “normal” (regular) block cipher, it would not be proper to make it related to any one specific cipher.
P.S. We probably have more pressing needs to address before adding tweakable ciphers, so this issue should be able to wait a little. On Sep 13, 2015, at 10:19 , Jean-Pierre Münch <[email protected]> wrote: > Am 13.09.2015 um 15:30 schrieb Jeffrey Walton: >> >>> 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 >>> <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 >> <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 >> <https://css.csail.mit.edu/6.858/2012/readings/bitlocker.pdf> > If I'm reading things right with the Elephant diffuser they "only" use two > keys and the sector index. We could define this index as a tweak and then > apply the rest of the function. To me the diffuser looks more like a > tweakable mode (having to maintain the current position inside the sector and > such things) rather than a tweakable block cipher which would mean it > wouldn't be affected by this design decision. However the tweak main class > could be used to construct a tweakable stream cipher class suitable for > providing the diffused CBC. >> * Crypto++'s existing implementation of DESX >> * Large block tweaks used in modes of operations, like XTS mode > There's indeed a problem with XTS. XTS requires *two* tweaks whereas my class > only provides one. Of course we could define tweak:=tweak1||tweak2 and > decompose this internally. Or we could extend the proposed approach to deal > with 2 tweaks. I don't know how to extend it to work with arbitrary many > tweaks and I think we should prefer to stick with one. >> >>> 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. > The following can also be read in the introduction of the Wagner paper (more > or less equally): > > Intuitively a tweakable block cipher is a standard block cipher which also > accepts a third value upon en- and decryption: the tweak. The tweak may not > be needed to be kept secure and knowledge of the tweak may not suffice to > reconstruct the key. The cipher instantiates a different family of PRPs for > each value of the tweak. The tweak *must* be easy / fast to change to provide > any advantages over re-keying. > > The design route I chose was highly oriented at how the key comes to the > block cipher. We'd take a block cipher and add a second class to it, which is > highly similar to the class constructing the key interfaces. This class would > provide management functions for the tweak (max length, default length, min > length,...). Additionally ProcessAndXorBlock() would be made a special case > of ProcessAndXorBlockWithTweak() with the tweak being a member variable with > the value 0. ProcessAndXorBlockWithTweak() would be MTI by > TweakableBlockCipher. The tweak went into this function to ensure the > property of allowing easy switching and assuming that the user may want to > use a different tweak on each function call thereby rendering external > solutions (own functions) too complicated. > > Additionally helper classes would be defined to enable quick definition of > the tweak's behavior as is done for the key (FixedTweakLength<size> and > VariableTweakLength<Default,Minimal,Maximal,StepSize>). There are analogons > for keys. > > And finally there's the TweakableBlockCipherDocumentation class, which is > also available for authenticated encryption, block ciphers and stream ciphers > and such clearly defining that CipherName::Encryption or ::Decryption should > provide the respective functionalities. > > The fact that TweakableBlockCipher is a derived class from BlockCipher also > enables those specialized ciphers to be used with standard primitives > (CTR_Mode,...). >> >> Crypto++ already implements an early tweakable block cipher in DESX (a.k.a. >> DES-XEX3), but I have not looked at it in detail. > It's fairly simple according to > http://www.weidai.com/scan-mirror/cs.html#DESX > <http://www.weidai.com/scan-mirror/cs.html#DESX> (which is referenced in the > source). You input 24 bytes and it'll use the last 16 for whitening. You > input 16 bytes and it'll use some defined derivation function for getting the > whitening values. > > I'd prefer not to follow this approach to avoid requiring the user to re-key > when he wants to change the tweak. There's no "faster" or more direct API or > new API defined in the source for manipulating *only* the tweak. >> >> So anything we decide on needs to be taken modulo (1) Wagner (et al) >> recommendations, (2) exiting implementations, and (3) future considerations. > (1) I think my design reflects their intents pretty good. > (2) our existing DESX is simply another cipher with longer key length. (with > the key going into the tweak) requiring a full rekey for each tweak change, > degrading performance. > (3) This is designed to be as much as possible a natural expansion of > Crypto++ staying to established conventions which worked out for the time the > blockcipher class existed. >> >> 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. > Of course, I'll wait roughly (at least) a week after the design feels settled. > > BR > > JPM >> >> Jeff >> >> -- >> -- >> You received this message because you are subscribed to the "Crypto++ Users" >> Google Group. >> To unsubscribe, send an email to [email protected] >> <mailto:[email protected]>. >> More information about Crypto++ and this group is available at >> <http://www.cryptopp.com/>http://www.cryptopp.com <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] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > -- > 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 <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- -- 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.
