Re: Protecting encryption server

You are absolutely right. I am naive; but I am learning. A time will come when I will involve experts formally, and what I am learning here will help me talk and plan more intelligently. You are also right on another account. I have not defined the problem for you sufficiently. Even

Re: Protecting encryption server

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

Re: Protecting encryption server

*> Quick question: how do you send data out? * This is not a problem. You connect the output of your data diode to a computer that will send the data over the Internet using whatever required protocol. Some commercially available "data diodes" include a "bare data diode" and the necessary

Re: Protecting encryption server

It has its merits; the drawback with this is the added network traffic, the additional crunch power and the numerous servers. (I know, nothing comes for free, everything comes at a price.) Adding unpredictable randomness at different levels is a

Re: Protecting encryption server

> So, as described in Rob's paper, the sending server has to > continuously send the data over and over again, with no idea whether > the receiving server has received any of it, parts of it, or the > whole of it. Correct. Our research was done as part of an electronic voting security group at

Re: Protecting encryption server

On Tue, Jul 28, 2020 at 10:33:42PM +0200, Denis BEURIVE via Gnupg-users wrote: > > Oh, quite the contrary. It just forces the attacker to get clever. > > If your server only sends data through an "outgoing data diode", then it > does not expose any entry point (you just disable all services : no

Re: Protecting encryption server

I understand. I do not expect to to solve these problems over here, but I am getting useful suggestions and yours is one of them. It may seem a little to you but I find the responses enlightening. You are probably concerned that I may not get adequate returns for the time I spend here: I

Re: Protecting encryption server

On Tue, Jul 28, 2020 at 08:39:28AM -0700, Ayoub Misherghi via Gnupg-users wrote: > A human environment went insane and uncontrollable. The system is intended > to bring sanity back and maintain it. > > > Client programs access server(s) for real-time encryption or decryption. > Network of

Re: Protecting encryption server

I think of another way to make things harder for a hacker. - Use "data diode isolated" secure servers : one "incoming data diode" for requests reception and one "outgoing data diode" for document emissions. Make sure that each secure server is only connected to the exterior world by

Re: Protecting encryption server

>> Oh, quite the contrary.  It just forces the attacker to get clever. > > If your server only sends data through an "outgoing data diode", then it > does not expose any entry point (you just disable all services : no SSH, > no ping, no HTTP... nothing). There is no way you can establish a >

Re: Protecting encryption server

> Oh, quite the contrary. It just forces the attacker to get clever. If your server only sends data through an "outgoing data diode", then it does not expose any entry point (you just disable all services : no SSH, no ping, no HTTP... nothing). There is no way you can establish a connection to

Re: Protecting encryption server

> Have you heard about data diodes ? If not, then you can read this > document > . Strange but true: although I can't claim to have been on the research team that invented the data diode, I *was* on the research

Re: Protecting encryption server

It all depends on what you want to do. Very secured technical solutions exist. But these solutions may not be applicable to any situations. Have you heard about data diodes ? If not, then you can read this document

Re: Protecting encryption server

Ayoub Misherghi via Gnupg-users wrote: > A human environment went insane and uncontrollable. The system is > intended to bring sanity back and maintain it. > > > Client programs access server(s) for real-time encryption or decryption. > Network of servers that may be located at different

Re: Protecting encryption server

A human environment went insane and uncontrollable. The system is intended to bring sanity back and maintain it. Client programs access server(s) for real-time encryption or decryption. Network of servers that may be located at different geographic locations. Each server would need keys that

Re: Protecting encryption server

On 28-07-2020 14:12, Robert J. Hansen wrote: > You can't. There is little to no defense possible against a trusted > insider that's gone rogue. The best you can do is to vet your people > carefully and, in the event of treachery, to use whatever legal means > are available to dissuade future

Re: Protecting encryption server

Hello, What is the risk ? Are you worried that somebody uses the server to sign inappropriate documents ? If you cannot trust the guy that administers the server, then I guess that there is not much you can do to prevent him from signing inappropriate documents. You may choose to dispatch the

Re: Protecting encryption server

> I am going to have a server machine doing encryption. How do you > protect against server operator or admin tampering. This is a > scenario where internal threat or hostility is high; you cannot trust > your own guys. (Real situation; not paranoid.) You can't. There is little to no defense

Re: Protecting encryption server

On Jul 27 11:34 Ayoub Misherghi via Gnupg-users wrote: I am going to have a server machine doing encryption. How do you protect against server operator or admin tampering. This is a scenario where internal threat or hostility is high; you cannot trust your own guys. (Real situation; not

Protecting encryption server

I am going to have a server machine doing encryption. How do you protect against server operator or admin tampering. This is a scenario where internal threat or hostility is high; you cannot trust your own guys. (Real situation; not paranoid.) Thanks, Ayoub