Sweet32: Can a single 8 byte block session ID be exploited by this vulnerability?

Question

Im currently developing a authentication scheme. The authentication scheme will use a 64 bit encryption to encrypt its session ID.

Here is how the authentication system will work:

For each session, a 32 bit static session ID (one for each user, randomized for each login), and a 32 bit per-request session ID (one for each link on website, randomized for each new request) will be concatenated. This will be encrypted with DES or 3DES for n rounds, with different keys for each round. Also, I will randomize so sometimes the static ID is put first, sometimes the per-request ID is put first.

These session IDs will also be stored in database on server-side.

The reason I need to encrypt the session, instead of just randomizing the whole session ID and just sending it verbatim, is because I want to have a ability to invalidate ALL per-request sessions tied to the static session ID, if any attempt is made to submit a session that is either expired or invalid for some reason.

Eg, even if the sessions are deleted from the database because they are expired, I want to find every session still in database that is related (having same static session ID), and be able to delete them aswell, if any attempt is to submit a expired session ID.

Now you wonder, why so short session IDs. This is because some of these session IDs will be used as one-time passwords that is manually entered. With hex, this will result in 16 characters to be entered, and having longer blocks will of course result in a tedious typing for the users.

Now to the question: Will this scheme be vulnerable by sweet32? What I understand from the sweet32 papers, ciphers relying on a single block without any CBC or something will be safe right?

Or is it something I have misunderstood from Sweet32 vulnerability?

Answer 1

What I understand from the sweet32 papers, ciphers relying on a single block without any CBC or something will be safe right?

Yes Sweet32 applies to ciphers with block sizes of 64 bits in CBC mode. The idea is to collect enough ciphertext to find a collision (which due to the birthday problem will be around $2^{32}$ blocks), in other word two ciphertext blocks that are equal.

We can write these blocks as $E_k(C_{i-1} \oplus P_i), E_k(C_{j-1} \oplus P_j)$, as in CBC mode we encrypt the XOR of the plaintext block and the previous ciphertext block. We note that since the blocks are equal it must hold that $C_{i-1} \oplus P_i = C_{j-1} \oplus P_j$. We know what the ciphertext is so if we write the equality as $C_{i-1} \oplus C_{j-1} = P_i \oplus P_j$ we know the lefthand side and recovering the plaintext blocks becomes equivalent to solving a two time pad.

Note that beside only working on 64 bit ciphers in CBC mode, this attack also requires a huge amount of data. I think in the paper the researchers observed hundreds of gigabytes of ciphertext before finding a collision. Given the amount of data needed (I doubt you have hundreds of GBs of session IDs), and the fact that you are not using CBC mode you are not at risk.