3DES inner CBC: Biham has shown that inner chaining weakens 3DES.

The OpenSSL implementation of triple DES in CBC mode appears to use
inner chaining. This is from cbc3_enc.c:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
/* HAS BUGS? DON'T USE - this is only present for use in des.c */
void des_3cbc_encrypt(des_cblock *input, des_cblock *output, long length,
des_key_schedule ks1, des_key_schedule ks2, des_cblock *iv1,
des_cblock *iv2, int enc)
{
    int off=((int)length-1)/8;
    long l8=((length+7)/8)*8;
    des_cblock niv1,niv2;
   
    if (enc == DES_ENCRYPT)
    {
        des_cbc_encrypt(input,output,length,ks1,iv1,enc);
        if (length >= sizeof(des_cblock))
            memcpy(niv1,output[off],sizeof(des_cblock));
        des_cbc_encrypt(output,output,l8,ks2,iv1,!enc);
        des_cbc_encrypt(output,output,l8,ks1,iv2, enc);
        if (length >= sizeof(des_cblock))
            memcpy(niv2,output[off],sizeof(des_cblock));
    }
    else
    {
        if (length >= sizeof(des_cblock))
            memcpy(niv2,input[off],sizeof(des_cblock));
        des_cbc_encrypt(input,output,l8,ks1,iv2,enc);
        des_cbc_encrypt(output,output,l8,ks2,iv1,!enc);
        if (length >= sizeof(des_cblock))
            memcpy(niv1,output[off],sizeof(des_cblock));
        des_cbc_encrypt(output,output,length,ks1,iv1, enc);
    }
    memcpy(*iv1,niv1,sizeof(des_cblock));
    memcpy(*iv2,niv2,sizeof(des_cblock));
}

Note that there is no looping at this level; the entire message is CBC
encrypted, decrypted, and encrypted again.

Biham has shown that inner chaining weakens 3DES. Outer chaining is
generally preferred. SSL uses outer chaining. How can OpenSSL be
compatible if it is doing inner chaining? Is the code above not used?

——————————–
Handbook of Applied Cryptography, Chapter 7 Block Ciphers

7.40 Fact: If t known plaintext-ciphertext pairs are available, an attack on two-key triple-DES requires O(t) space and 2^(120-lgt) operations.

(iii) Multiple-encryption modes of operation
In contrast to the single modes of operation in Figure 7.1, multiple modes are variants of multiple encyption. multiple encryption constructed by concatenating selected single modes. For example, the combination of three single-mode CBC operations provides triple-inner-CBC; an alternative is triple-outer-CBC, the composite operation of triple encryption (per Definition 7.32) with one outer ciphertext feedback after the sequential application of three single-ECB operations. With replicated hardware, multiple modes such as triple-inner-CBC may be pipelined allowing performance comparable to single encryption, offering an advantage over triple-outer-CBC. Unfortunately (Note 7.41), they are often less secure.

7.41 Note: (security of triple-inner-CBC) Many multiple modes of operation are weaker than the corresponding multiple-ECB mode (i.e., multiple encryption operating as a black box with only outer feedbacks), and in some cases multiple modes (e.g., ECB-CBC-CBC) are not significantly stronger than single encryption. In particular, under some attacks triple-inner-CBC is significantly weaker than triple-outer-CBC; against other attacks based on the block size (e.g., Note 7.8), it appears stronger.

(iv) Cascade ciphers
Counter-intuitively, it is possible to devise examples whereby cascading of ciphers (Definition 7.29) actually reduces security. However, Fact 7.42 holds under a wide variety of attack models and meaningful definitions of “breaking”.

7.42 Fact: A cascade of n (independently keyed) ciphers is at least as difficult to break as the first component cipher. Corollary: for stage ciphers which commute (e.g., additive stream ciphers), a cascade is at least as strong as the strongest component cipher.

Fact 7.42 does not apply to product ciphers consisting of component ciphers which may have dependent keys (e.g., two-key triple-encryption); indeed, keying dependencies across stages may compromise security entirely, as illustrated by a two-stage cascade wherein the components are two binary additive stream ciphers using an identical keystream — in this case, the cascade output is the original plaintext.

Fact 7.42 may suggest the following practical design strategy: cascade a set of keystream generators each of which relies on one or more different design principles. It is not clear, however, if this is preferable to one large keystream generator which relies on a single principle. The cascade may turn out to be less secure for a fixed set of parameters (number of key bits, block size), since ciphers built piecewise may often be attacked piecewise.

HMAC-SHA1-96 is just a weakened HMAC-SHA1

HMAC-SHA1-96 truncates the 160 bits digest of HMAC-SHA1 to 96 bits:

RFC2202(not only HMAC-SHA1-96, but also HMAC-MD5-96):

HMAC-MD5
key = 0x0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c
key_len = 16
data = “Test With Truncation”
data_len = 20
digest = 0x56461ef2342edc00f9bab995690efd4c
digest-96 0x56461ef2342edc00f9bab995

HMAC-SHA-1
key = 0x0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c
key_len = 20
data = “Test With Truncation”
data_len = 20
digest = 0x4c1a03424b55e07fe7f27be1d58bb9324a9a5a04
digest-96 = 0x4c1a03424b55e07fe7f27be1

HMAC-SHA-1
key = 0xaa repeated 80 times
key_len = 80
data = “Test Using Larger Than Block-Size Key and Larger Than One Block-Size Data”
data_len = 73
digest = 0xe8e99d0f45237d786d6bbaa7965c7808bbff1a91
data_len = 20
digest = 0x4c1a03424b55e07fe7f27be1d58bb9324a9a5a04
digest-96 = 0x4c1a03424b55e07fe7f27be1