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 > * Ferguson and the Elephant Diffuser used in BitLocker, > 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 (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]. > 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] > <mailto:[email protected]>. > For more options, visit 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.
smime.p7s
Description: S/MIME Cryptographic Signature
