We provide web redirection based integration with our partners' web apps. The flow is something like the following, and the password is generated randomly and shared with them during the onboarding process and before any interaction can take place and does not change often.:
- Partner exposes web application to end user. End user submits a request to partner server.
- Partner encrypts request using AES, and AES key generated using PBKDF2 along with a random salt and iteration count of 65536 and keylength 256
- Partner sends a web redirection, and embeds the encrypted request in the GET request along with salt
- Our server receives the request, Generates key using password and salt and decrypts request.
The encrypted request is small, not more than half a kilobyte. So encryption/decryption itself is fast.
The issue is with PBKDF2 key generation as it has to be computed every time because of salt. It is very slow because of the high iteration count, and hence takes about 100ms for each request. This is unacceptable as the number of redirections can be very high, and the server will not be able to keep up with incoming requests.
I went through this link (At what point does adding more iterations to PBKDF2 provide no extra security?) and some other similar discussions, which lead me to think that if I have a long random password, then I may be able to get away with a shorter iteration count (say 1000 or even 100).
Another thought I had was to pre-compute a 256 bit key using PBKDF2 with a high iteration count of say 65536, and then use that as password. Then for each request, compute the key using this password and the salt received in the request, pass them to the PBKDF2 with a smaller iteration count (say 1000 or 100). Would this approach be equally secure to the current implementation? or are there any issues with this?
My question may be similar to this: PBKDF2 used to generate an encryption key: long shared secret (password) vs iterations count however the answers were not very clear to me.