You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So we can had a level of parallelization to decrypt more quickly the encrypted text.
For each request send to the server, we can try to decipher one byte for each block we have. This way the randomness decreases regarding the number of block.
Check the screenshot bellow:
Without parallelization: ~6.5s
Chance to get one byte: 1/256
With parallelization: ~2.5s
Chance to get one byte: number_of_block/256 if the last byte of every request send to the oracle are different, then number_of_block-1/256, number_of_block-2/256 etc
Worst case: 1/256, best case number_of_block/256.
With this improvement we can decipher so much faster the encrypted text.
The text was updated successfully, but these errors were encountered:
For now, this is only working on the poc but not in the exploit. I didn't find a proper way to duplicate the data send by the client on the proxy and have a proper response from the server.
As we can read in the document of the CBC cipher mode : https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_(CBC)
So we can had a level of parallelization to decrypt more quickly the encrypted text.
For each request send to the server, we can try to decipher one byte for each block we have. This way the randomness decreases regarding the number of block.
Check the screenshot bellow:
Without parallelization: ~6.5s
Chance to get one byte:
1/256
With parallelization: ~2.5s
Chance to get one byte:
number_of_block/256
if the last byte of every request send to the oracle are different, thennumber_of_block-1/256
,number_of_block-2/256
etcWorst case:
1/256
, best casenumber_of_block/256
.With this improvement we can decipher so much faster the encrypted text.
The text was updated successfully, but these errors were encountered: