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
Many checks after decryption use strcmp and strncmp to verify that a documentId , a role or other resource matches a resource request with the corresponding organization key.
Common implementations of these functions compare one-by-one characters of both strings until a difference is found, until a \0 is found or, in the case of strncmp, until the maximum size is reached. This means that a no or few matches will take less time to execute than an exact match (especially in a long string).
It is unclear in CaumeDSE's implementation if this poses a significant risk since we don't store or compare keys, but rather decrypt all records and then match against those decrypted successfully. However, since in our case incorrect decryption results in empty strings, it may be possible to estimate the number of records that decrypt correctly to a certain key with a timing attack.
So it seems a good idea to replace these functions with another that keeps comparing (e.g. against the last character of the shortest string) until the end of the largest string and just flag the mismatch. See PyCrypto 2.4 for an example of a solution to a similar problem: https://www.dlitz.net/blog/2011/10/pycrypto-2-4-released/ .
The text was updated successfully, but these errors were encountered:
Many checks after decryption use strcmp and strncmp to verify that a documentId , a role or other resource matches a resource request with the corresponding organization key.
Common implementations of these functions compare one-by-one characters of both strings until a difference is found, until a \0 is found or, in the case of strncmp, until the maximum size is reached. This means that a no or few matches will take less time to execute than an exact match (especially in a long string).
It is unclear in CaumeDSE's implementation if this poses a significant risk since we don't store or compare keys, but rather decrypt all records and then match against those decrypted successfully. However, since in our case incorrect decryption results in empty strings, it may be possible to estimate the number of records that decrypt correctly to a certain key with a timing attack.
So it seems a good idea to replace these functions with another that keeps comparing (e.g. against the last character of the shortest string) until the end of the largest string and just flag the mismatch. See PyCrypto 2.4 for an example of a solution to a similar problem: https://www.dlitz.net/blog/2011/10/pycrypto-2-4-released/ .
The text was updated successfully, but these errors were encountered: