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
Sadly, OMEMO doesn't hide the filename from the server, despite this meta datum can already contain sensitive information.
The URL contains a random value to prevent listing existing files via brute force, so it has high entropy.
Every request of the file via an XMPP client is done via the URL. So, instead of storing the file in the filesystem by its name, a hash of the URL can be used as name. This prevents the admin (or attackers getting read access to the filesystem) to get potentially sensitive meta data.
As encoding for the hash, I propose base32(hex) without padding to keep it short and safe even for systems with case-insensitive filesystems.
This could be even extended to use hkdf to derive 2 keys: one for obfuscating the filename and a second one to encrypt the content of the file - in case the uploader didn't use something like OMEMO.
It would be best if OMEMO would not only encrypt the file's content but also hides the file name and the content type. But as it's not the case, this can add an additional layer of protection. It, however, cannot protect against malicious admins as the admin could (a) read the process memory at the time of a file up-/download or (b) could just disable it or use a different software.
The text was updated successfully, but these errors were encountered:
Sadly, OMEMO doesn't hide the filename from the server, despite this meta datum can already contain sensitive information.
The URL contains a random value to prevent listing existing files via brute force, so it has high entropy.
Every request of the file via an XMPP client is done via the URL. So, instead of storing the file in the filesystem by its name, a hash of the URL can be used as name. This prevents the admin (or attackers getting read access to the filesystem) to get potentially sensitive meta data.
As encoding for the hash, I propose base32(hex) without padding to keep it short and safe even for systems with case-insensitive filesystems.
Instead of the full URL, only the path or even just the path info (see
PATH_INFO
at https://www.php.net/reserved.variables.server).This could be even extended to use hkdf to derive 2 keys: one for obfuscating the filename and a second one to encrypt the content of the file - in case the uploader didn't use something like OMEMO.
It would be best if OMEMO would not only encrypt the file's content but also hides the file name and the content type. But as it's not the case, this can add an additional layer of protection. It, however, cannot protect against malicious admins as the admin could (a) read the process memory at the time of a file up-/download or (b) could just disable it or use a different software.
The text was updated successfully, but these errors were encountered: