Trait for tweakable block ciphers

[newpavlov]

Threefish is an example of tweakable block cipher, thus ideally we need an appropriate trait for it.

One option is to use something like this:

pub trait TweakableBlockCipher {
    type BlockSize: ArrayLength<u8>;
    type TweakSize: ArrayLength<u8>;

    fn encrypt(&self, b: &mut Block<Self::BlockSize>,  t: &Block<Self::TweakSize>);

    fn decrypt(&self, b: &mut Block<Self::BlockSize>, t: &Block<Self::TweakSize>);
}

Additional context can be found in the previous issue.

[tarcieri]

There was some discussion on RustCrypto/block-ciphers#459 about whether to model a tweak as an additional input to the block cipher encryption/decryption operation, or having a separate method that can mutate the block cipher state prior to performing an encrypt/decrypt operation.

I thought I'd just note here that in the traditional definition of a tweakable block cipher, it's definitely modeled as a separate parameter, and is specifically described as a "new (second) input":

https://people.eecs.berkeley.edu/~daw/papers/tweak-crypto02.pdf

I was expecting the trait to look something along the lines of option (c) above.

In all applications of tweakable block ciphers I'm familiar with, the tweak changes between invocations of the block cipher, so having it be a mutable part of the state seems like it's inviting accidental "tweak reuse".

[newpavlov]

Unfortunately, there are several unresolved issues with this design. How many of the block cipher trait methods we want to duplicate in new tweak traits? Should tweakable block cipher implement both BlockCipherEnc/Dec and TweakBlockCipherEnc/Dec? Or should the latter have a blanket impl for the former? Having blankets impls can cause conflicts with other blanket impls.

[tarcieri]

It would impact encrypt and decrypt methods.

I don't think we should use blanket impls for these traits. I'm not even sure how they would work. To me they're just completely separate interfaces.

[newpavlov]

It would impact encrypt and decrypt methods.

I meant whether the tweakble traits should have methods like encrypt_with_backend and encrypt_padded.

I don't think we should use blanket impls for these traits. I'm not even sure how they would work.

They could work by passing a zero tweak to the tweakable methods. IIUC tweakable block ciphers are soemtimes used as simple block ciphers.

[tarcieri]

I meant whether the tweakble traits should have methods like encrypt_with_backend and encrypt_padded.

I think they should have a shape similar to BlockEncrypt / BlockDecrypt, such that a cipher can always require a tweak without having to impl BlockEncrypt / BlockDecrypt (i.e. we should support block ciphers that are only tweaked)

They could work by passing a zero tweak to the tweakable methods. IIUC tweakable block ciphers are soemtimes used as simple block ciphers.

For a blanket impl to make sense, that MUST be true 100% of the time, and I know of no such definition of tweakable block cipher that says that must always be the case.

I can think of the following scenarios involving the relationship between tweaked and untweaked constructions, and while I don't have concrete examples, I don't think we can rule any of them out:

1. the block cipher is internally domain separated such that the tweaked and untweaked permutations are completely unrelated such that one cannot be composed in terms of the other
2. the untweaked mode is composed in terms of the tweaked mode but uses a "default" tweak other than zero
3. the tweaked mode is composed in terms of the untweaked mode. PMAC (and IIUC OCB as well) constructs a tweaked block cipher from an untweaked block cipher in such a manner

[newpavlov]

Maybe we could introduce a wrapper over tweakable block ciphers, something like struct FixedTweak<C, const TWEAK: Tweak<C> = ZeroTweak>? Unfortunately, because adt_const_params is still unstable, we will have to use a type-based workaround for TWEAK.

[tarcieri]

Another option is to do something similar to what I was suggesting for the aead crate and gate the blanket impls on an additional marker trait, which could also be named something like FixedTweak.

Such a trait could carry the value of the tweak as an associated constant.

[newpavlov]

But IIUC such trait would mean that tweak is fixed for a tweakable block cipher, meaning that we will not be able to easily use tweaks for domain separation.

Instead of the const wrapper a better option could be a wrapper with tweak set at runtime:

struct RtTweak<C: TweakSizeUser> {
    cipher: C,
    tweak: Tweak<C>,
}

impl<C: TweakSizeUser> From<C> for RtTweak<C> {
    fn from(cipher: C) -> Self {
        Self { cipher, tweak: Default::default() }
    }
}

impl<C: TweakSizeUser> RtTweak<C> {
    fn set_tweak(&mut self, tweak: Tweak<C>) {
        self.tweak = tweak;
    }
}

// Blanket impls of BlockCipherEnc/Dec for RtTweak<C>

Or we could do both similarly to Rt/CtVariableCoreWrapper in the digest crate.

[newpavlov]

BTW do you know tweakable block ciphers with tweak size bigger than 128 bits? Maybe we could use u128 with LE order as a workaround for the FixedTweak wrapper (let's rename it CtTweak for clarity)?

UPD: QARMAv2 supports 256 bit tweaks.

[tarcieri]

A FixedTweak or thereabouts only makes sense for one hyper specific use case: when a specific tweakable block cipher specifically defines that its untweaked version is defined as the tweaked version with a fixed input as the tweak, like you were referring to earlier:

They could work by passing a zero tweak to the tweakable methods. IIUC tweakable block ciphers are soemtimes used as simple block ciphers.

Such an approach doesn't need customization: it's more of the opposite, it's codifying something specific about a particular algorithm.

Allowing customization (which you've already described as not being possible without adt_const_params) would allow users to create nonstandard untweaked variants of tweakable block ciphers. Those are the sorts of choices I think we should deliberately eliminate.

Otherwise, "tweak reuse" is an antipattern in true usages of tweakable block ciphers, IMO, similar to nonce reuse.

--

Backing up: before we go down the path of even trying to support some automatic way to use tweakable block ciphers via the untweaked BlockEncrypt/BlockDecrypt interfaces, it would probably be good to catalogue and enumerate how much this pattern actually exists in real-world tweakable block ciphers. Otherwise, it feels like a premature optimization.