Re: How to send a signed git patch

2023-11-10 Thread Michael Richardson

Daniel Cerqueira via Gnupg-users  wrote:
> I want to send my po translation of GnuPG.

> Werner told me to send a signed git patch to a list.

> So, I signed my git commit with my GnuPG key. And when I do `git
> format-patch master` the created patch does not have this signature.

I think: include that patch in an email (not an attachment), and sign it.
A signed git commit does not get transfered by email, alas.
You'd have to use git:// or https:// or.. to transfer the git signature.

> How can I create a git patch with a GnuPG signature?



signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Pinentry problem with different home dir

2023-10-25 Thread Michael Richardson

Werner Koch via Gnupg-users  wrote:
> On Wed, 25 Oct 2023 13:01, Falko Strenzke said:

>> Can anyone give me an advice what I can try to get the GnuPG Agent
>> pinentry working with different home directory specified via
>> GNUPGHOME?

> Run it this way:

> mkdir /foo/bar cd /foo/bar GNUPGHOME=`pwd` gpg-agent --daemon
> ~/bin/gnupg-setup-tests

The gpg-agent dependancy that came a few years ago has really been a PITA.

I would really like some way to tell GPG that it really needs to ignore all
of *my* (personal) setup, because I'm wearing a different personality now.
[like code signing]

> In case you have a special setup you may put a gpg-agent.conf into
> $GNUPGHOME and use the pinentry-program option.  "gpg -v" shou.d show
> which pinetry is launched, in case of problems, the gpg-agent.conf
> should show/log an error.

I guess I'd really like that to just happen with some 
--I-really-want-isolated-gnupg
option.

--
]   Never tell me the odds!     | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: YubiKey/OpenPGP card connection issues for non-root user

2023-08-03 Thread Michael Richardson

Felix E. Klee  wrote:
> system (running in VMware under Windows), it sometimes takes minutes to

> [felix@felix-arch ~]$ ls /dev/bus/usb/002/011 /dev/bus/usb/002/011

I think you need to make sure that it's not VMware that's failing to plug the
device through in a timely manner.

dmesg -w

Would confirm that it's getting there.  You say that you can get it working
as root.  How does --card-status know which USB device to use?  Does it
perhaps scan through all devices? I wonder if it is getting stuck on some
other device that it hasn't got permission?

> How do I fix that?

> I am happy to substitute the udev rules with a timer, or to call some
> command to give permissions every time I want to use the YubiKey or the
> OpenPGP card. I just would like the whole process to be more reliable.
> Currently, it’s extremely frustrating.

!-indeed.



--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: "gpg --card-edit" with multiple card readers (Yubikey)

2023-07-19 Thread Michael Richardson

Andrew Gallagher  wrote:
> The yubikey performs cryptography on the device, but does have a small
> amount of flash memory to store the private key material. The yubikey
> does not provide any method to copy the private key material back off
> that storage, it can only be overwritten or used by the yubikey’s own
> processor.

So I can generate the key on laptop, copy it to multiple yubikey, and do the
crypto on the device, and the yubikey won't let the private key out again.
Once I destroy the copy on my laptop, them I'm good.





signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: "gpg --card-edit" with multiple card readers (Yubikey)

2023-07-17 Thread Michael Richardson

Andrew Gallagher  wrote:
>> Juanjo via Gnupg-users  wrote:
>>
>>> This may be a good starting point:
>>> https://github.com/drduh/YubiKey-Guide
>>
>> "Keys stored on YubiKey are non-exportable (as opposed to file-based
>> keys that are stored on disk) and are convenient for everyday use. "
>>
>> In my case, I want the same key on multiple devices, which 3 to 5 core
>> members of an open source project will hold.  (I am also considering
>> if we want a higher security key which would be secret split across
>> those keys, but we aren't building a CA here, but..)
>>
>> Is that possible with these devices?
>>
>> In some cases keys can be transfered in an encrypted form for another
>> device, but not recovered by outsiders.

> This is not possible with a Yubikey. If you want the same (sub)keys on
> multiple devices you must generate them on your laptop and copy them to
> each device in turn, remembering not to delete until you’re done.

okay, so in this case we are using the Yubikey only as a storage, equivalent
essentially to a USB storage?  Or does it still do crypto on the device?

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: "gpg --card-edit" with multiple card readers (Yubikey)

2023-07-17 Thread Michael Richardson

Juanjo via Gnupg-users  wrote:
>> should eventually describe the environment.
>> >
>> > Yes please.  > Could it go into a wiki page or something that people
>> can comment on and/or > amend?
>>
>> feel free to open a page with the info that Werner has already given
>> on https://wiki.gnupg.org

> This may be a good starting point:
> https://github.com/drduh/YubiKey-Guide

"Keys stored on YubiKey are non-exportable (as opposed to file-based keys
that are stored on disk) and are convenient for everyday use. "

In my case, I want the same key on multiple devices, which 3 to 5 core
members of an open source project will hold.
(I am also considering if we want a higher security key which would be secret
split across those keys, but we aren't building a CA here, but..)

Is that possible with these devices?

In some cases keys can be transfered in an encrypted form for another device,
but not recovered by outsiders.



signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: "gpg --card-edit" with multiple card readers (Yubikey)

2023-07-07 Thread Michael Richardson

Werner Koch via Gnupg-users  wrote:
> On Fri, 7 Jul 2023 14:22, Juanjo said:

>> This works fine with a single Yubikey, but we wanted to have more than
>> one connected at the same time in order to batch-configure them and
>> even to try to use multiple SSH key authentication in specific target

> Most of the time I am using several Yubikeys and other smardcards.
> Some even remotely.  For example I use an SSH connection with socket
> forwarding to out build server.  Over that connection I provide access
> to an Authenticode token, my release key and ssh keys on tokens.

> I should eventually describe the environment.

Yes please.
Could it go into a wiki page or something that people can comment on and/or 
amend?

The need for more secure, and more reproduceable code-signing environments is
becoming critical.  Today, tcpdump.org, for instance, has a rather old
code-signing key, and we want to replace it with some hardware token, but we
really don't know what exactly to use,and don't want to be on the bleeding
edge here.

> As a starter:
> "no-autostart" in common.conf on the build box, gpg-card with "verify"
> to unlock keys on the desktop for remote use by the build process
> (Authenticode), and some keywords in the private key files
> (Use-for-p11, Use-for-ssh).

> To create keys, use gpg-card which can easily be scripted.  Examples:

>$ gpg-card list D27600012401000615493283 \ -- yubikey
> disable nfc all \ -- yubikey disable usb otp u2f piv oath fido2 \ --
> yubikey list OTP no no U2F no no OPGP yes no PIV no no OATH no no FIDO2
> no no

>$ gpg-card [...]  gpg/card> help generate GENERATE [--force]
> [--algo=ALGO{+ALGO2}] KEYREF

>Create a new key on a card.  Use --force to overwrite an existing
> key.  Use "help" for ALGO to get a list of known algorithms.  For
> OpenPGP cards several algos may be given.  Note that the OpenPGP key
> generation is done interactively unless a single ALGO or KEYREF are
> given.  [Supported by: OpenPGP, PIV]

Thank you.
Which model of Yubikey are you using?



signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: ADK's

2023-05-02 Thread Michael Richardson

Andrew Gallagher  wrote:
> The only way that a company would end up archiving a password reset
> email encrypted to an ADK would be if an employee was using their work
> email address for password resets. If using their work email for this
> purpose is inadvisable, then it is inadvisable regardless of ADKs.

Like you mean, an employee was using a work email for a work thing, maybe?

> ADK introduces no new considerations that are not also an issue for key
> escrow, which happens anyway, and has several advantages over escrow,

I agree.

> If you don’t trust your correspondent’s employer, then the only
> effective course of action is to not use their employer’s email
> address. Technical measures cannot protect you from opsec problems.

I'm asking to be informed so that I can make the decision to do
something else.





signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: ADK's

2023-05-01 Thread Michael Richardson

Jacob Bachmeyer  wrote:
>> I'm unclear if this is a new feature (I think so), and if so what 
happens if
>> the sender hasn't upgraded yet?
>>

> My understanding:  ADKs are new and do not work without support on the
> sender's side.  The ADK is a request to also encrypt any message to the
> subkey to the ADK.  If the sender's software does not understand that
> request, it does not happen.  If the sender rejects that request, either
> by setting an option or by patching their software to ignore the request, 
it
> does not happen.

Does it still (by default) encrypt to the main key?

> My primary reason for arguing to support some way to suppress the use of 
an
> ADK when encrypting is that, as Johan noted, this is an issue where 
feelings
> are strong enough to provoke forks, which are likely to simply rip out ADK
> support entirely, thus making its legitimate uses (group inboxes, multiple
> tokens, business-related) unreliable.

I agree with this view.

>> > I would also note that, for a work email system in an environment 
where there
>> > is a legal or quasi-legal requirement (not uncommon in finance) to 
archive
>> > messages, simply dropping any incoming message not decryptable with the
>> > archive ADK as spam would be reasonable.  Since the primary concern
>> > motivating message archival in this example is deterring insider 
trading,
>> > simply not allowing unreadable messages to be delivered accomplishes 
the same
>> > objective.
>>
>> Yes, reasonable.
>> OTH, the emails investigating the insider trading by the HR people might 
need
>> to avoid the ADK.

> If we are talking about investigating HR malfeasance, those messages would
> not be going to the traders' regular inboxes in the first place.  You are
> right that an HR ADK could be a very bad idea in this example, since it 
could
> allow HR to front-run their own employer.  The expected solution would be 
to
> give the trading archives only to the audit or legal departments, and only
> after some period of time has passed.  That still leaves potential 
auditor or
> lawyer malfeasance, but that is an existing risk such businesses already
> handle.

It's the initial investigation of an irregularity where there could be a 
problem.
There is also an issue with 2FA and password reset emails: it's something
that may be a vulnerability to archive.  Okay, few are encrypted today, but
we can hope.   Many companies with forced proxis are starting to realize that
they become liable when they store banking login cookies.

Anyway, I think senders need to be made mildly aware that it's occuring, and
I think they should be allowed to pick a specific ADK or suppress them all in
certain circumstances best decided by them.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[




signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: ADK's

2023-04-30 Thread Michael Richardson

Jacob Bachmeyer via Gnupg-users  wrote:
> ADKs seem particularly valuable to me as a solution to the "group inbox"
> problem that avoids actually sharing private key material:  simply
> attach encryption subkeys for all recipients to the "group inbox"
> certificate.  This requires publishing new certificates when the
> recipient list changes and discloses the recipient list to some extent, 
but
> that is the trade-off for end-to-end security in this context.  Could a
> "--notify-ADK-encrypt" option that could be placed in the configuration 
file
> be appropriate to address user concerns about possible improper 
proliferation
> of ADKs?  Should a notification that an ADK was used actually be default?
> After all, there are legitimate uses for ADKs, but an ADK turning up where
> not expected could be a strong hint that you have a bogus certificate.

That would be really useful for secur...@example.com

I'm unclear if this is a new feature (I think so), and if so what happens if
the sender hasn't upgraded yet?

> I would also note that, for a work email system in an environment where 
there
> is a legal or quasi-legal requirement (not uncommon in finance) to archive
> messages, simply dropping any incoming message not decryptable with the
> archive ADK as spam would be reasonable.  Since the primary concern
> motivating message archival in this example is deterring insider trading,
> simply not allowing unreadable messages to be delivered accomplishes the 
same
> objective.

Yes, reasonable.
OTH, the emails investigating the insider trading by the HR people might need
to avoid the ADK.




signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Management of background services with systemd

2023-03-01 Thread Michael Richardson

David Joaquín Shourabi Porcel  wrote:
> I am researching GnuPG for my employer. We will stick with the old
> release series 2.2 at first, because few Linux distributions package
> 2.3 or 2.4 yet. However, I'm studying newer versions and recent
> developments to ease our future upgrades. In doing so, a question has
> arisen: should background services like the agent not be managed with
> systemd?

Please no.

It's bad enough as it is when you have multiple personalities you are trying
to support (signing as me, vs signing code with an offline key)... having
systemd (the userland one) popping off new copies would be horrible.

Combined with SSH access to the machine, and the passphrase/pin popup shows
up in the wrong place.

(And many of us do not trust systemd and do not run it on important machines)



signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Mastodon account, good server?

2022-12-03 Thread Michael Richardson

It's not the technical work or the system resources that are really the
challenge (I think that there is plenty of technical volunteers).
It's the promises about moderation and other softer human resources that seem
to really be the limit for running Mastodon instances.

Maybe FSF.org will do something.



signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Does the PGP public key at https://www.washingtonpost.com/anonymous-news-tips/

2022-08-06 Thread Michael Richardson

Michael Richardson  wrote:
> Yeah, the marketing department screwed it up, and should have put 
> on it.  It suggests that it has never really been used.

I sent an encrypted email to the newspaper, pointing them at this thread, and
the problems they have.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Does the PGP public key at https://www.washingtonpost.com/anonymous-news-tips/

2022-08-05 Thread Michael Richardson
Francesco Ariis  wrote:
> Hello Jay,

> Il 05 agosto 2022 alle 17:28 Jay Sulzberger via Gnupg-users ha scritto:
>> Does the PGP public key at
>> https://www.washingtonpost.com/anonymous-news-tips/ work?

> It gets copied in a weird way (i.e. some characters that should be
> newlines are instead spaces); I am not able to import it.

Yeah, the marketing department screwed it up, and should have put  on it.
It suggests that it has never really been used.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Does the PGP public key at https://www.washingtonpost.com/anonymous-news-tips/

2022-08-05 Thread Michael Richardson
The key on that page is line wrapped.
If I replace the right spaces with newlines, then it seems to work import okay.

-BEGIN PGP PUBLIC KEY BLOCK-
Version: Mailvelope v4.6.0
Comment: https://www.mailvelope.com

xsDNBGLr60kBDAC7/dyy27fxfbaE1Ss13QI9li93YePYFNjLW1JonvNcsmN+
ncuA5u8HZJQFo9ICtytfMIzEwW6JwcTVFY5TvZcjDi/8FtNzpCCFmnzkCZP1
TVXo5xGLV7HC3rzpJSP8n3vcHO7xCPbBsBdzVrzA6QQZCDTniCITBYHdFZYb
7qT9NGD34mPb+gmhzBNxZf8YfJ3jj7H+Bq3dz2laDl/lHg7+TnfvOGwHJuA4
uMMPxWTXhZFZv2toYpuYPgj+pfwG0m4fTQEEjc8BK2xpCl3o0sgg+IhHKtpy
J2GF43ee8iBBFMIcZNSKxGo7676QYM8bp9TuBB6qGiNeML08EIB5OLYYFnII
AWxHyx5DbSdSYFGEAnaJnH3KWrvPI5/YvlVsa8uiYK3gcyLIJI3VW3PBHvU7
lsH/o0rI6fprTERuaBfkd5xgJlvFFG+VLBOZnTnQ4ap7wXVY5Omje4BACBqW
zKuyVtuCyKdP3j3fYaMymdrwomFIAbhlq5LcZATSTdApSSsAEQEAAc0iVFdQ
IExvY2tib3ggPGxvY2tib3hAd2FzaHBvc3QuY29tPsLBKwQTAQgAPhYhBOxs
KQXw+TwDc5RsoQZCQnpf94C+BQJi6+tJAhsDBQkDw7o3BQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAACEJEAZCQnpf94C+FiEE7GwpBfD5PANzlGyhBkJCel/3
gL5TgQv+P3OalnPOiYz2sTLVninPd8s9guhBKvoR1b2k0oA4iS2g/sONY109
CC4SWlUJVxqaVLFhDi3x5g/tgWOzv51pKGuKZuzlmS456Z0ofIvwbJuHHc9B
ypTA7GNqFEp7ylTL3H1BTeYXcWqzTIqAwYrvkDzbfjiRd4nDgfoJffHiHDEw
Oun/UFaUK6TpBS5HSzSrthxQxRQ2Gq05pIvA9QWmaN7U1et9eZoy2q76bv6T
Ij2yAse/VN6BE4txcbPmFBF9ZLWhDs+gtzpMWeaLqK11tiyGvWZ1j64ncVs3
K7O/NYfnaaYijuKIpF+fvzriiS8yoe8FX3AFOSWYe6hk13GFgceF7AbhiAlD
yRSJSsVQyY4yrtuTisSP8m5bQi71VvX1Mw7n9eEwc5XeZ77ndbVOFDBz3Oes
OXd7e/RcGBLzfuiIdKJVuMW8T78X34ide60w2/6rik41tebQMaCgcK4dEOu1
JIG4fChEZh09usLcnLxn6PGUqDcAZlrlBWonb2H5zsDNBGLr60kBDACnlsLK
mY1Hu15iEWcfU0ieArFf4saw/gTBYcne2uKQRFflmq7i6W7l3aiEqCaezkUZ
F3sokng6h1PqE7DW+9uzOWr9rpfiF2+PakFaTLUCbcIYdh/mxItXeAjadAkV
tcGVJK0Eb5OtvS0pK39dFIsnhm63t7/G/aFiCiAWRmmvMzsXeKdH+GVXF4Nb
KH+q6d9hPuxIBP92wYOeo/630jJTXlqJ0muqM2BYyodb9RqXKYOZcgkTm0Xu
XUoHseIPhlrReWzoZtsa16zL1aCgoz5BeqGwrBoE9EatsexexpAJP7Jt7VzZ
OJyF4tGXQRkmfkWCwOxnTQWAave1xvdwk3VYB6cHNkN4WaF4TD4Wx+xBadMA
OnKV2vOZbNNPMHYsUsLKNy1Lv15FK5nAYN+o26u0AiFFo3lMNBwl9QqLTeRh
gvwxMelO9UdrV+bxziGlFMDkyrd62b6qw4evTLI6QzT9f9/51vNfmTpW1E44
IChMQB64hrDJ7TWstSV+4JDje+EAEQEAAcLBEwQYAQgAJhYhBOxsKQXw+TwD
c5RsoQZCQnpf94C+BQJi6+tJAhsMBQkDw7o3ACEJEAZCQnpf94C+FiEE7Gwp
BfD5PANzlGyhBkJCel/3gL7uXwwAhxceVQGfug5U7ZmKlzBjgCcF4VhlTaFt
iGMKP1WJO7jPXkX9qReYWARKpcW2u16crg8fndAeKHgu0t1KRnCJaTnxWUHM
qX+zuOX6l4GSdxIvrkv3arqVz48doxNW2ph1u7dV46j3MFTqujjZnkl77rUf
aoCnb20YU0dR+1LAPLqf4U9fdndWd0DjwoK6pulALFZfHix1PqDGa05gRcBP
NaCPiGhjl3Uv8xlykJuNhnGWVLUb8qDfAnHnbhFqnX9KaucjI/RrXiI42cPA
QpL31cVRKNq60qZMQYY/5aYHoXao4+n2Y7D2rEi1XmTmMlpMgW3Sw51eUXKi
mRGas2kFtslkDmRsHo+DYLWUZxzBCfKanuf1VLCNftb10zb0jgWjRAVNEOjQ
KmrvwxI0qNJGv85oalHXE+P99ao85hByEJbA5YlfQr7Kv65ULG7pOsMdNXWQ
U3UuJ/9XuI2Oc2S0TIA4T43Ur2HX1lRkaRMjTSBXRQSppFctaiwe/t+oL01j
=53IM
-END PGP PUBLIC KEY BLOCK-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: GnuPG 2.2.36 released

2022-07-13 Thread Michael Richardson

Todd Zullinger via Gnupg-users  wrote:
> It's frustrating that the releases are signed with a cipher that cannot
> be verified on a reasonably popular distro.

At least, multiple signatures could be made.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: [Announce] GnuPG 2.1.0 modern released

2014-11-06 Thread Michael Richardson

Werner Koch w...@gnupg.org wrote:
   - All support for PGP-2 keys has been removed for security reasons.

Does this mean that documents signed decades ago with PGP2 can no longer
be verified?

If so, I guess this is a reason to keep GPG classic around for verification
purposes only.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



pgpWBpGjrKqLy.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: [Announce] GnuPG 2.1.0 modern released

2014-11-06 Thread Michael Richardson

Werner Koch w...@gnupg.org wrote:
 Werner Koch w...@gnupg.org wrote:  - All support for PGP-2 keys has
 been removed for security reasons.
 
 Does this mean that documents signed decades ago with PGP2 can no
 longer be verified?

 Right.  It is anyway useless because you have to assume that such
 signatures are broken.  If you want to decrypt you should have 1.4

I agree that one's confidence in that content should be suspect, but the
value is not zero.  I am happy that you have removed the support,
btw. Simpler code is important.

   There is one use case where PGP-2 keys may still be required: For
 existing encrypted data.  We suggest to keep a version of GnuPG 1.4
 around which still has support for these keys (it might be required to
 use the `--allow-weak-digest-algos' option).  A better solution is to
 re-encrypt the data using a modern key.

Yes, that was idea too -- just use 1.4.
And one can't re-encrypt data signed by another.

In many cases, in my archives, I have email that is clear signed, which was
then encrypted, and stored that way.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 




pgpxyAsFJlM_e.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users