Protecting encryption server

[Ángel]

On 2020-07-28 at 18:22 -0700, Ayoub Misherghi via Gnupg-users wrote:
> Before that happens. I am coding a prototype right now that is not going 
> to be inadequate; but all this will help me arrive at a better 
> understanding, help demonstrate basic ideas and hopefully prepare me and 
> others for the production of a better specifications, better action and 
> better product.

Please do not take offense at this, but I think you are way off-track
with how you are exploring solutions. I suspect a good solution should
go through a different venue.

This includes the diode proposal in the thread. It works for limited use
cases such as the voting system, but I don't think it could serve well
for «Client programs access server(s) for real-time encryption or
decryption».

However, at this point I think the real problem has not been specified
properly, and so we lack enough information to properly think what you
might need.

And I think you are way earlier than a prototype phase. In fact, it can
be detrimental in that it can be leading the proposing solutions on one
way, while there could be a better one (plus the cost of preparing a
useless prototype). You should have at least a rough idea on what the
design will involve before preparing a prototype.*


* Actually, on a system you will find *several* designs. It's fine to
code a prototype of the UI with little knowledge on how the backend will
be designed, it might be enough to know the basic that there will be a
username and password, and code from that to start exploring how to
integrate it with the rest of $ENVIRONMENT.
OTOH, if that small premise happens to be wrong (let's say there are no
user and password fields, it's all passwordless authentication based on
SAML single-sign-on at a different portal, to whom the users
authenticate using FIDO keys) that prototype would be of no use.


Regards