Hi, the reason for my request was not because I am not aware of the problems in convenience. I fully understand that a password won't make it much more secure if your system is already compromised but if I consider a general end-user...
I mean I would like to have such a feature optionally and I am willing to develop it even if it wouldn't be used by many. If I think about applications like file-sharing, cloud-services and other which could be based on requests of file paths and those aren't filtered properly before getting patched. I would like to have less pressure during development of the interfaces. For example a sandbox with only filesystem access at the moment could potentially lead to identity theft. But granting a sandbox to have access to capturing of keypresses, process management or other processes memory is less probable. It's also a problem that most users don't fully encrypt their drive. Even many distributions of Linux which do allow encryption during installation don't pick it as default and many users on Windows won't probably know their drive is fully readable. I know that's not a problem we have to solve but we should consider it. So I have a few ideas how it could be developed. My preferred choice would be built into the GNUnet API similar to GpGMe which asks in CLI or GUI for the password but the EGO key can be hold after it for a whole session in memory which makes the password-prompt as convenient as possible. (I know this would be really nasty for CLI considering current interfaces. That's just one reason to make it optional.) > However, some time ago I also thought that it would be nice to have key storage "backends" such that you could have hardware tokens (or plain USB keys) storing your identities/keys. > > That would allow you to more easily transfer and use keys across devices. The next idea would be to solve the problem of file access. The GNUnet services could be run by different uid. So the actual user wouldn't have direct access to config and keys. Pretty much like putting everything related to GNUnet in a separate virtual environment which is encrypted from outside. This would have the advantage of putting this environment on flash drive and using it accross devices. This would be also a very common usage for people using a Librem Key for example or storing GpG keys externally. >> If for some application you want to use a password for additional >> protection, I suggest to consider using the GNS trick of reading the Ego >> and then multiplying the public/private keys with the password to derive >> a new public-private key pair, and then to use that for authentication. >> That even ensures that an attacker cannot do an offline brute-force >> attack against the password. If I understand this correctly I would store a first key externally in GNS and derive a second key in every session to use the second key for authentication, right? So I would delete the file of the second key afterwards or keep it completely temporary, I guess? I would like to have more details for this kind of approach because it sounds interesting for possible key sharing between devices. The last option I can think of would be storing EGO keys for my specific application fully separate and encrypted, putting an abstracting layer around all functions of the EGO api from GNUnet and copying the unencrypted keys temporary to the required location for every use with an own password prompt and handling of en-/decryption. This would be something I would probably implement if you tell me the first options are all unnecessary for most users and you don't see another better option for this purpose. Thank you for the replies already. Jacki
signature.asc
Description: This is a digitally signed message part
