Re: Encryption of EGO keys

[Christian Grothoff]

Hi!

My first feeling for this overall is that this is likely the wrong
direction, as we really need to focus on improving usability, not add
features for power-users that even there are of marginal utility. Stuff
like running with even more UIDs or considering scenarios with attacks
involving virtualization are not going to get us any closer towards a
system that can be used by more people than its own developers. So at
least for me, the motivation to design, implement, document and debug
such features is extremely low, and I fear that doing this "right" so
that it actually works will take quite a bit of effort that could be
better spent elsewhere for a much bigger impact.

That said:

On 7/6/20 10:39 PM, TheJackiMonster wrote:
> 
> 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.

Is actually closely related to the "homework" we got from the security
audit of GNU Taler from CodeBlau: separate processes and UIDs to
minimize exposure of private key material to the rest of the system.  It
wouldn't be necessarily a virtual environment (we were more thinking of
another UID) and 'encrypted' is also questionable (for availability
reasons -- after power outage system has to boot without human
intervention). OTOH, we _do_ think about using HSMs for the private
keys, which is more like the hard-core version of the flash drive you
are thinking about.

So this _may_ happen, alas for the Taler exchange which is expected to
be operated by professional system administrators at regulated banking
institutions. So not exactly the same target audience as a GNUnet peer,
both in terms of cost-of-hardware and training of the operator.

I do intend to soon start design discussions on this (likely at
taler@gnu.org), and depending on how those go, it is not unlikely that
we'll push the functionality into libgnunetutil. While *my* objective is
not to use this for GNS, we may be able to make this dual-use with the
right design (and if it works, I would not object to having it as an
_option_ for GNS). So I would encourage you to participate in the
discussion and possibly implementation effort.

signature.asc
Description: OpenPGP digital signature