Let me explain the task from what these questions have arisen. I'm interested in
encryption of local storage for long-living content. But existing tools (like TrueCrypt)
store encryption keys somewhere locally (in the case of TrueCrypt - in the header of
encrypted partition), where an adversary can easily obtain them. Hashing the keys with
user-typed password doesn't provide sufficient security, because any password of
reasonable complexity can easily be fitted by "brutal force" method.
My idea consists in storing encryption key remotely - in such a way, that
nobody knows actually where it is. Rightful owner of the key can type password,
that will be hashed with his login and peer id, then this hash can be used as
id of the file with encryption key. It's useless for an adversary trying to fit
the password, because of delay from network request to download.
For instance, originally generated AES-256 encryption password can be written
on RAM disk in the file AES256.key. Then it can be published by something like
this:
# gnunet-publish -D -n -V ramdisk/AES256.key
We read URI of the keyfile from the output of gnunet-publish, then extract from it all
data, that identify the keyfile. Then we prompt user for password and make hash from peer
id + user login + password. Then we make bitwise xor of the hash with the keyfile id and
store the result locally as "hashed keyfile id". From now onwards, when
AES256.key becomes unnecessary, it should be wiped from RAM disk.
When authentic user asks to start services using encrypted local content, he will be
prompted for password. Peer id + user login + password will be hashed, then bitwise xor
of the hash with "hashed keyfile id" will be made. From the result URI of the
keyfile will be reconstructed. Then the keyfile should be downloaded by something like
this:
# gnunet-download -o ramdisk/AES256.key URI
If the download is successful, the key from the file AES256.key can be used to
decrypt/encrypt content of the corresponding local storage.
But:
A. It would be surprise, if after half year of inactivity user could not retrieve
AES256.key, because it's "expired".
B. It would be not very good, if an adversary could find encrypted local copy of
AES256.key and fit password to it by "brutal force" method.
So, afore-mentioned two questions have arisen.