Mailing List Archive

On Jul 27 11:34 Ayoub Misherghi via Gnupg-users <gnupg-users@gnupg.org> 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 paranoid.)

A question maybe beyond the scope of GnuPG and the list. But I suggest you implement the appropriate security controls in your IT-infrastructure.
You can for example check out the NIST Cybersecurity Framework for guidance.

// Marcus

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> 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 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 treachery.

Kim Philby, Aldrich Ames, John Walker, Robert Hanssen, Reality Winner,
Chelsea Manning, Ed Snowden...

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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 responsibilities,
so nobody has full administrator authorization. However, if you think that
the administrators may collaborate with each other, then there is nothing
you can do.

Are you worried that somebody steals the server private key ?

If you are only concerned by the theft of the secret key, then you can
externalize the signature process to a Secure Signature Creation Device (
https://www.cryptomathic.com/products/authentication-signing/digital-signatures-faqs/what-is-a-secure-signature-creation-device
).

Regards,

Denis

Le mar. 28 juil. 2020 à 12:19, Ayoub Misherghi via Gnupg-users <
gnupg-users@gnupg.org> a écrit :

> 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
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

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 treachery.

Recent real world examples: Encrochat, Ironchat, Enetcomm. In some cases
the operators became traitors, and I doubt that legal actions are very
high on their treat list considering the kind of customers they served.
Some of them will probably die suddenly of lead poisoning.

--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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 need to be protected. The
servers are in a hierarchy communicating with each other securely as
needed. Horrible environment to protect.


Server design may need to be specialized with immunity to tampering and
abuse. Operator and admin may need to be on constant
monitoring/surveillance with biometric ID. Equipment may need to be
identifiable and be under constant monitoring and surveillance.


Grateful for all suggestions. Keep them coming. I have a lot to learn.


Ayoub


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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 geographic
> locations. Each server would need keys that need to be protected. The
> servers are in a hierarchy communicating with each other securely as
> needed. Horrible environment to protect.
>
>
> Server design may need to be specialized with immunity to tampering and
> abuse.

Maybe each individual runs a Bitmessage client on the Bitmessage Network.

No need for operators controlling the network and it is secure and gives
people anonymity, while each user has a key pair for an address in the
network.

https://wiki.bitmessage.org//

Regards
Stefan


--
my 'hidden' service gopherhole:
gopher://iria2xobffovwr6h.onion

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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
<https://owlcyberdefense.com/blog/what-is-data-diode-technology-how-does-it-work/>
.

Data diodes are unhackable because it relies on the law of physics : IT is
hackable. The laws of physics, on the other hand, are not. You cannot get
around the laws of physics, regardless of the amount of resources you are
ready to spend.

So, you may use a data diode to make use that nobody can infiltrate your
signing server from the Internet.

However, this solution is 100% bulletproof on the condition of your signing
server "only sends data," that is if it does not need to respond to
requests from the Internet. In this situation, your server does not expose
any network entry point. It only exposes an "unhackable one way only" exit
point.

If your signing server needs to respond to requests from the Internet, then
you can implement "air gap isolation" with another data diode. An (unsafe)
server receives a request. It extracts the data from the request, and send
it to the (secure) signing server through a one way only exit point (a data
diode).

Therefore, your secure signing server has two data diodes : one for the
reception of requests and the other for the emission of signed documents.

This solution is not 100% bulletproof since a carefully crafted request may
be used to hack the secure server (you use the technique known as "buffer
overflow" to inject malicious code). However, without direct feedback (the
data diode forbids feedback) and without knowledge of the server software
environment, doing so is really difficult. I doubt that it is practically
doable, although it theoretically is.

Thus, you could create a "practically" (as opposed as "theoretically")
unhackable (from the Internet) signing server.

Now, the question is : what can you do about the administrators ?

The response maybe : create a server that does not need to be administered
and protect it physically (place it in a safe, for example).

If your server only needs to sign documents, then it can be very "rustic
and cheap." A Raspbery Pi should be more than enough. You install a minimal
Linux distribution with only the bare requirements for your application. It
should not need to be administered. And if a problem occurs, don't bother
to fix it... just replace the server with a new one (ready to be used).

Denis




Le mar. 28 juil. 2020 à 17:39, Ayoub Misherghi <ayoubhm@gmail.com> a écrit :

> 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 need to be protected. The
> servers are in a hierarchy communicating with each other securely as
> needed. Horrible environment to protect.
>
>
> Server design may need to be specialized with immunity to tampering and
> abuse. Operator and admin may need to be on constant
> monitoring/surveillance with biometric ID. Equipment may need to be
> identifiable and be under constant monitoring and surveillance.
>
>
> Grateful for all suggestions. Keep them coming. I have a lot to learn.
>
>
> Ayoub
>
>

> Have you heard about data diodes ? If not, then you can read this
> document
> <https://owlcyberdefense.com/blog/what-is-data-diode-technology-how-does-it-work/>.

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 team that
invented the first cheap optical data diode. We packaged it up into an
Altoids tin. Total materials cost was under $100, and most of that was
spent on the custom PCB.

> Data diodes are unhackable because it relies on the law of physics...

Oh, quite the contrary. It just forces the attacker to get clever.

Our paper from 2006:

https://www.usenix.org/legacy/event/evt06/tech/full_papers/jones/jones_html/index.html


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> 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 the server. How can you hack a server if you have absolutely no way to
access it from the outside ? It seems just impossible.

Now if you also use an "incoming data diode" to receive data, then you have
no direct feedback. The only feedback you get is through the "outgoing data
diode." It will be very difficult to get information about the server
internals in this condition. Imagine : you have a black box and you try to
model it from indirect feedback. Although it is theoretically possible, it
would be very difficult. All depends on the resources you are intended to
spend... Is the game worth the candle?

To make this task even harder, you can make the feedback very difficult to
analyze. For example, you can voluntarily introduce randomness. GNUNET does
it, for example. When you send a message to a node, you also send "fake"
messages to many other nodes (chosen at random). A spy (man in the middle)
could not distinguish between "fake" and "real" messages... You can
although randomly delay the responses : measuring duration between
responses won't give any usable information. These are just examples. You
can think of many ways to make life harder to a "malicious man in the
middle" that tries to reverse engineer your system by collecting and
analyzing data collected by observing your black box.

Denis

Le mar. 28 juil. 2020 à 21:59, Robert J. Hansen <rjh@sixdemonbag.org> a
écrit :

> > Have you heard about data diodes ? If not, then you can read this
> > document
> > <
> https://owlcyberdefense.com/blog/what-is-data-diode-technology-how-does-it-work/
> >.
>
> 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 team that
> invented the first cheap optical data diode. We packaged it up into an
> Altoids tin. Total materials cost was under $100, and most of that was
> spent on the custom PCB.
>
> > Data diodes are unhackable because it relies on the law of physics...
>
> Oh, quite the contrary. It just forces the attacker to get clever.
>
> Our paper from 2006:
>
>
> https://www.usenix.org/legacy/event/evt06/tech/full_papers/jones/jones_html/index.html
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

>> 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 the server. How can you hack a server if you have
> absolutely no way to access it from the outside ? It seems just impossible.

The data diode is a one-way link, yes. But there are so many ways to
gain access to machines that putting too much faith in a data diode to
protect your systems is deeply foolish. A data diode can make *one
particular link* a one-way data link. That's genuinely useful in the
context of a complete security solution that looks holistically at the
threat.

But no, they don't make a system unhackable.

Lateral movement through networks is a thing. Look into it. :)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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 these two data diodes.
- Introduce randomness in the "data diode isolated" secure servers :
make it hard for a "malicious man in the middle" to "reverse engineer" your
black box by the analysis of data collected from the observation of your
"black box".
- Design a distributed system : make your "data diode isolated" secure
server exchange data with "dumb nodes." The "dumb nodes" do nothing except
relay the responses (they act as proxies). When the secure server sends a
response, it sends messages to many "dumb nodes" chosen randomly. Among all
these messages, there is only one "real" message. Other messages are fake
ones, but are indiscernible from the point of view of a "malicious man in
the middle"). Thus, in order to "spy" your system (to collect data), you
have to "spy" the entire "galaxy" of "dumb nodes"- and not only one server.
This makes things much more difficult for "a malicious man in the middle,"
especially if your "dumb nodes" are located in different countries which
intelligence agencies are not known to collaborate easily (because cracking
such a system would require a lot of resources). "dumb nodes" do not need
to be particularly secured. An attacker could disrupt your system (by
hacking the "dumb nodes"), but it cannot alter the signed document - unless
it has a way to crack RSA - or whatever algorithm you use (but, in this
case, just forget your project...).

Tell me what you think.

Regards.



Le mar. 28 juil. 2020 à 12:19, Ayoub Misherghi via Gnupg-users <
gnupg-users@gnupg.org> a écrit :

> 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
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, Jul 28, 2020 at 08:39:28AM -0700, Ayoub Misherghi via Gnupg-users <gnupg-users@gnupg.org> 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 geographic locations.
> Each server would need keys that need to be protected. The servers are in a
> hierarchy communicating with each other securely as needed. Horrible
> environment to protect.
>
>
> Server design may need to be specialized with immunity to tampering and
> abuse. Operator and admin may need to be on constant monitoring/surveillance
> with biometric ID. Equipment may need to be identifiable and be under
> constant monitoring and surveillance.
>
> Grateful for all suggestions. Keep them coming. I have a lot to learn.
>
> Ayoub

You might be asking in the wrong place. We can suggest
helpful things like vetting staff, hardware security
modules (HSM), separation of duties, privileged access
management, ISO27001 etc. but this is just a gnupg
mailing list, not a security architecture mailing list.

You should consider engaging the services of security
architects who can analyse your environment in detail
and provide something as close to a solution as you can
afford. As rjh said, an actual solution is impossible
but you do what you can and what you can afford (and
log everything for evidenciary purposes).

cheers,
raf


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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 good measure, definitely.




These are strategies to protect or mitigate risk coming from external unfriendliness. There exits probably worse risk coming from inside; the operators and admins; that is probably a bigger risk that is harder to aleviate.





I am learning from all the responses, even though it may seem otherwise. I am listening and you people are doing than talking. I am grateful.





Thanks everybody; keep it coming.





Ayoub





On 7/28/2020 2:45 PM, Denis BEURIVE wrote:

I think of another way to make things harder for a hacker.

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 appreciate that. That is a mark of a good character you have.


Although it has not been my intention to advertise, I got a few good
responses off list as a side effect. I will engage people formally as
you suggest when the time comes for it.


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.


I apologize if I am encroaching.


Thanks,


Ayoub


On 7/28/2020 5:17 PM, raf via Gnupg-users wrote:
> You might be asking in the wrong place. We can suggest
> helpful things like vetting staff, hardware security
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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 SSH, no
> ping, no HTTP... nothing). There is no way you can establish a connection
> to the server. How can you hack a server if you have absolutely no way to
> access it from the outside ? It seems just impossible.

Quick question: how do you send data out? It cannot be via TCP
connections, since those require a handshake and acknowledgements
flowing both ways. It cannot be via any kind of TLS-based protocol for
the exact same reason. In theory you might be able to devise some
one-way protocol based on e.g. UDP or your own datalink layer and add
some kind of signing into it, but that would require a security audit in
its own right, and then there is the issue of dropped packets. 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.

Also, hm, here's a possibly stupid question: how do you keep the system
time synchronized between the sender and the receiver? You cannot use
any kind of time synchronization similar to NTP or even SNTP, since that
would require incoming data and programs that process that incoming data
and possible avenues of attack via (possibly still undiscovered)
problems in those programs. So at some point, time drift will start to
cause problems in the verification of the cryptographic signatures of
the data the server sends.

I am not saying that any of those problems is unsolvable, but it seems
to me that devising robust solutions to all of them (and to all of
the others that will come up along the way) will make the system much,
much, *much* more complicated than "just a single one-way comm device".
At some point the question would arise whether all these complications
and all these newly-devised communication protocols are indeed worth it.
Once again, not saying that the answer is always "no", but, well...

G'luck,
Peter

--
Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

> 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
the University of Iowa. The particular use case we had was, "how do you
communicate realtime election results to a public webserver in a way
that even if attackers compromise the webserver they cannot access the
tallying system?"

And for that, the tickertape model works pretty well. We had a proof of
concept running in Python at a very low baud rate: it was transmitting
at a speed slightly slower than an old Telex teleprinter. This had the
additional side effect of making it easier to audit (you could
physically see the LED flip on and off), easier to sync, and more
resistant to transmission errors.

For election results, Telex speeds are just fine. If you need more
bandwidth than that, the next best bet is to just burn a DVD and
hand-deliver that.

> I am not saying that any of those problems is unsolvable, but it
> seems to me that devising robust solutions to all of them (and to all
> of the others that will come up along the way) will make the system
> much, much, *much* more complicated than "just a single one-way comm
> device".

... which, not to put too fine a point on it, is where the potential to
exploit the system comes from.

*> 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 electronics required to send data over
the Internet using the TCP/IP stack.

You can create a data diode with 2 Raspberry Pi (connected through the GPIO
ports). The receiving Raspberry Pi receives data from its GPIO ports... and
nothing prevents it from sending the data over the Internet using its
Internet connection. It does so by using the TCP/IP stack. Therefore, it
knows if the receiving server receives the data or not (since the TCP/IP
stack allows bidirectional exchanges).
[image: rpi.gif]

You can hack the RPI connected to the Internet. But you have no way to hack
the second one since it is not connected to the Internet and since the data
diode is a one way only transmission.

*> Also, hm, here's a possibly stupid question: how do you keep the system
time synchronized between the sender and the receiver?*

That's a good question. However, there is a second question : do you need
to keep the system time synchronized ? If not, then there is no need to
worry about it.

However, if you need to get a very precise time, you can synchronize your
server using a radio-controlled clock (RCC). You can get the necessary
component for a Raspberry Pi, for example.


Below a suggested architecture for a signing server :
[image: server.gif]

Denis




Le mer. 29 juil. 2020 à 09:51, Peter Pentchev <roam@ringlet.net> a écrit :

> 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 SSH,
> no
> > ping, no HTTP... nothing). There is no way you can establish a connection
> > to the server. How can you hack a server if you have absolutely no way to
> > access it from the outside ? It seems just impossible.
>
> Quick question: how do you send data out? It cannot be via TCP
> connections, since those require a handshake and acknowledgements
> flowing both ways. It cannot be via any kind of TLS-based protocol for
> the exact same reason. In theory you might be able to devise some
> one-way protocol based on e.g. UDP or your own datalink layer and add
> some kind of signing into it, but that would require a security audit in
> its own right, and then there is the issue of dropped packets. 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.
>
> Also, hm, here's a possibly stupid question: how do you keep the system
> time synchronized between the sender and the receiver? You cannot use
> any kind of time synchronization similar to NTP or even SNTP, since that
> would require incoming data and programs that process that incoming data
> and possible avenues of attack via (possibly still undiscovered)
> problems in those programs. So at some point, time drift will start to
> cause problems in the verification of the cryptographic signatures of
> the data the server sends.
>
> I am not saying that any of those problems is unsolvable, but it seems
> to me that devising robust solutions to all of them (and to all of
> the others that will come up along the way) will make the system much,
> much, *much* more complicated than "just a single one-way comm device".
> At some point the question would arise whether all these complications
> and all these newly-devised communication protocols are indeed worth it.
> Once again, not saying that the answer is always "no", but, well...
>
> G'luck,
> Peter
>
> --
> Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com
> PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
> Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
>

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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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 though I have stated on the list that internal threat is probably
greater

than external threat, most of the responses seem to me to address external

threat.


I will find a way of giving you more information, preserving confidentiality

where necessazry.


Ayoub


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users