Re: Encryption of EGO keys

[TheJackiMonster]

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