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?