Re: gpg - difference --encrypt-to and --recipient

2019-01-02 Thread vedaal via Gnupg-users 


On 1/2/2019 at 3:59 PM, "justina colmena via Gnupg-users"  wrote:
>My opinion is that should be the case. However, most MUAs I've used
>include the BCC recipients' keys in the encryption along with the To
>and CC recipients' keys, so any email addresses in the user-IDs of
>these keys are visible to all recipients.

>As an exception, one MAU I used with an OpenPGP add-on would instead
>send an individual copy of the message to each BCC recipient,
>encrypted only to their key.

>This seems like better practice. Also I would want to encrypt the
transmitted email message only to the intended recipient, >and the
copy stored in my "Sent" folder only to myself.
>With hidden-recipient or hidden-encrypt-to or throw-keyids, it is
>clear how many keys were encrypted to, but the key IDs and user-IDs
>are not present.
I am not terribly comfortable with this situation. It almost seems
rather creepy to me to receive an encrypted message that is also
encrypted for the benefit or verification of one or more unknown and
unidentified third parties. I start suspecting things like a foreign
government mandated key escrow or secret government backdoor on behalf
of some foreign spy or law enforcement agency.

=
 you have 3 tedious options, 1 more tedious than the other  8^)   :

[1]  use default-recipient-self, and explain in an n.b. in your
plaintext that you want to have a record of what you sent, but don't
want to leave it in plaintext,  and you will have an encrypted copy in
your sent box openable by you  
(this is very common).

[2] encrypt only to the sender, but also encrypt the plaintext only to
you, and store the encrypted file in your sent or other convenient
folder, with the date and the recipient.

[3] only for the overly paranoid who revel in tedious work-arounds 
8^) :

(a)  Encrypt to both yourself and the recipient
(b)  Remove your own id packet from the ciphertext, 
(c)  Re-calculate  the crc of the ciphertext
(d)  Send the 'hacked' ciphertext along to the original recipient
(e)  Store the first ciphertext from (a) along with the one from (d),
in your sent folder
(f)   now you will always be able to decrypt and retrieve the original
plaintext

btw,

I don't recommend this, 
but it is *possible* to add a (not yet done, but not terribly
complicated either) patch to gnupg to 'display' the session key in the
terminal window, 
(while you are encrypting only to one recipient),
and then you can encrypt that session key to your key, and store it,

or

a (also not yet done, but not terribly complicated either) patch,
 to allow gnupg to use a session key supplied by the user as an entry
in the command line(i.e.  --use-session-key  (64 character string from
step (a) above)

That session key is as random as any done by gnupg, and isn't really
being 're-used', 
it's just being stored in the encrypted file from step (a) and is
being sent with the same message encrypted to the same recipient as in
step (a)

This is just to point out, that if someone wants to think paranoidly
about 'who else knows' what is encrypted in your encrypted e-mail that
was encrypted only to you, it 'can' be done,
(extremely tedious, and afaik , has not been implemented by any
open-pgp variant program out there   8^)  )
vedaal
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg - difference --encrypt-to and --recipient

2019-01-02 Thread Stefan Claas 
On Wed, 02 Jan 2019 11:56:27 -0900, justina colmena via Gnupg-users wrote:
> On January 1, 2019 4:13:43 PM AKST, MFPA 
> <2017-r3sgs86x8e-lists-gro...@riseup.net> wrote:

> >With hidden-recipient or hidden-encrypt-to or throw-keyids, it is
> >clear how many keys were encrypted to, but the key IDs and user-IDs
> >are not present.  
> I am not terribly comfortable with this situation. It almost seems rather 
> creepy to me to receive an encrypted
> message that is also encrypted for the benefit or verification of one or more 
> unknown and unidentified third parties.
> I start suspecting things like a foreign government mandated key escrow or 
> secret government backdoor on behalf of
> some foreign spy or law enforcement agency.

When you receive a message which is also encrypted to hidden recipients you 
will see that
in GnuPG, when decrypting the message. It shows additional info of how many 
keys the
message was encrypted to, with key ids showing in the form of ID 
.

So nothing to worry! This very good feature was probably implemented many moons 
ago
for users of Mixmaster.

Regards
Stefan

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

Re: gpg - difference --encrypt-to and --recipient

2019-01-02 Thread justina colmena via Gnupg-users 
On January 1, 2019 4:13:43 PM AKST, MFPA 
<2017-r3sgs86x8e-lists-gro...@riseup.net> wrote:
>Hi
>
>
>On Monday 31 December 2018 at 9:06:39 PM, in
>, justina
>colmena via Gnupg-users wrote:-
>
>
>> Shouldn't an email message (for example) be encrypted
>> separately to
>> each BCC recipient,
>
>My opinion is that should be the case. However, most MUAs I've used
>include the BCC recipients' keys in the encryption along with the To
>and CC recipients' keys, so any email addresses in the user-IDs of
>these keys are visible to all recipients.
>
>As an exception, one MAU I used with an OpenPGP add-on would instead
>send an individual copy of the message to each BCC recipient,
>encrypted only to their key.

This seems like better practice. Also I would want to encrypt the transmitted 
email message only to the intended recipient, and the copy stored in my "Sent" 
folder only to myself.

>> or is this an intended all-in-one
>> multiple-recipient encryption which cannot conceal
>> from the
>> cryptanalyst the fact that the same message,
>> encrypted only once, is
>> being sent to more than one receiving party?
>
>With hidden-recipient or hidden-encrypt-to or throw-keyids, it is
>clear how many keys were encrypted to, but the key IDs and user-IDs
>are not present.
I am not terribly comfortable with this situation. It almost seems rather 
creepy to me to receive an encrypted message that is also encrypted for the 
benefit or verification of one or more unknown and unidentified third parties. 
I start suspecting things like a foreign government mandated key escrow or 
secret government backdoor on behalf of some foreign spy or law enforcement 
agency.
>
>--
>Best regards
>
>MFPA  
>
>Never trust a dog with orange eyebrows


-- 
A well regulated Militia, being necessary to the security of a free State, the 
right of the people to keep and bear Arms, shall not be infringed.

https://www.colmena.biz/~justina/

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

Re: OpenPGP card: how to lock the card again so that PIN is required

2019-01-02 Thread Matthias Apitz 
El día miércoles, enero 02, 2019 a las 11:36:54a. m. +0100, Werner Koch 
escribió:

> On Tue,  1 Jan 2019 08:36, g...@unixarea.de said:
> 
> > with the OpenPGP card (HID Global OMNIKEY 6121 Smart Card Reader) after
> 
> Take care: Usual Omnikey problems with creating and using large keys
> apply.

Thanks. But I'm using this card and reader for a long time. And the same 
problem is
with the uTrust reader.

> > How can I meanwhile 'reset' the OpenPGP card so that on next request for
> > the secrets (decrypt, signing, ssh) the PIN is requested?
> 
>   gpgconf --reload scdaemon
> 
> is the easiest way.  You can also use --kill as it is the same for
> scdaemon.

THANKS!!! This works and I now at least can disable the card when I go a
way from the laptop.

BTW: The CCID and the readers have no manuals how, i.e. in which
directions, one has to insert the CCID. Yesterday I took pictures to
have this clear now :-)

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, 
Druschba
instead of Nazis, to live instead of to survive.


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

Re: A question about WKD

2019-01-02 Thread Stefan Claas 
On Wed, 2 Jan 2019 11:18:25 +0100, Wiktor Kwapisiewicz wrote:

Hi Wiktor,

> Revoke your current key locally and generate a new one, now export both binary
> keys (that includes revocation) to a file. Place it in 
> .well-known/openpgpkey/hu
> overwriting the old file.
> 
> Now, when GnuPG does --locate-key it will fetch both keys, revoke your old one
> and add the new one.

Thank you very much, i did not know that it can be done this way.
 
> If someone already has your old key GnuPG will do the fetch automatically when
> the old key expires (you didn't use expiry as far as I can see so it won't
> happen automatically).
> 
> One can still "force" the WKD refresh using:
> 
> $ gpg --auto-key-locate clear,wkd,nodefault --locate-key s...@300baud.de
> 
> I just tested this all with some dummy key on my end and it worked just 
> fine...
> hope it works on your end too.

I hope so too and i will see once i have the new key.

> As for signing, if you specify signing key using "e-mail notation" GnuPG will
> embed Signer's UID packet and when the recipient uses --auto-key-retrieve it
> will grab your key using WKD instead of keyservers. But I didn't test what 
> would
> happen if the old key is already present in the keyring that doesn't match the
> signature, probably nothing.

That's interesting and i must admit i did not know this either, so thanks again!

> (You can inspect this file with pgpdump if you want to see the packet:
> $ curl https://metacode.biz/.well-known/security.txt | pgpdump
> )

O.k. 

> Happy New Year!

Happy New Year!

Best regards
Stefan

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

Re: OpenPGP card: how to lock the card again so that PIN is required

2019-01-02 Thread Alexander Paetzelt | Nitrokey 
Hi,

On 01.01.19 08:36, Matthias Apitz wrote:
> How can I meanwhile 'reset' the OpenPGP card so that on next request for
> the secrets (decrypt, signing, ssh) the PIN is requested?

for key slots 1 and 2 there probably is no way to do this other than
unplugging und replugging the device. See also the discussion here [1].

Kind regards
Alex

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

Re: OpenPGP card: how to lock the card again so that PIN is required

2019-01-02 Thread Werner Koch 
On Tue,  1 Jan 2019 08:36, g...@unixarea.de said:

> with the OpenPGP card (HID Global OMNIKEY 6121 Smart Card Reader) after

Take care: Usual Omnikey problems with creating and using large keys
apply.

> How can I meanwhile 'reset' the OpenPGP card so that on next request for
> the secrets (decrypt, signing, ssh) the PIN is requested?

  gpgconf --reload scdaemon

is the easiest way.  You can also use --kill as it is the same for
scdaemon.



Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
gpg-connect-agegpg-connect-agen


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

Re: A question about WKD

2019-01-02 Thread Wiktor Kwapisiewicz via Gnupg-users 
On 01.01.2019 13:19, Stefan Claas wrote:
> Hi Wiktor and all,
> 
> since my current WKD key is a temporary key i would like to know
> for best practice the following:
> 
> In a couple of days i will receive my Kanguru Defender 3000 USB stick
> and then i will create a new key pair and put it on the stick, along
> with other things. This key will then also be signed by Governikus.
> 
> Because WKD currently does not cover revocation certs i would like
> to know how to continue. Should i upload then my revoked temp
> key to SKS or should i simply replace the keys. If possible i would
> like to avoid SKS usage in the future.
> 
> Does GnuPG detects when i use a new WKD pub key, once i signed
> a new message?

Stefan,

Revoke your current key locally and generate a new one, now export both binary
keys (that includes revocation) to a file. Place it in .well-known/openpgpkey/hu
overwriting the old file.

Now, when GnuPG does --locate-key it will fetch both keys, revoke your old one
and add the new one.

If someone already has your old key GnuPG will do the fetch automatically when
the old key expires (you didn't use expiry as far as I can see so it won't
happen automatically).

One can still "force" the WKD refresh using:

$ gpg --auto-key-locate clear,wkd,nodefault --locate-key s...@300baud.de

I just tested this all with some dummy key on my end and it worked just fine...
hope it works on your end too.

As for signing, if you specify signing key using "e-mail notation" GnuPG will
embed Signer's UID packet and when the recipient uses --auto-key-retrieve it
will grab your key using WKD instead of keyservers. But I didn't test what would
happen if the old key is already present in the keyring that doesn't match the
signature, probably nothing.

(You can inspect this file with pgpdump if you want to see the packet:
$ curl https://metacode.biz/.well-known/security.txt | pgpdump
)

Happy New Year!

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor

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

Re: NIST 800-57 compatible unattended encryption?

2019-01-02 Thread Wiktor Kwapisiewicz via Gnupg-users 
Hello,

> On Wed, Jan 02, 2019 at 04:02:03PM +1100, gn...@raf.org wrote:
>> For some dumb reason I think I was hoping that the RSA
>> algorithm wasn't really used to encrypt all the data. I
>> thought it was probably used to encrypt a per-file
>> randomly-generated symmetric key which was then used to
>> encrypt the file (and was encrypted along with the
>> file) because it could be faster. But I think I'm
>> confusing it with network protocols like TLS.
>>
>> Is that what happens with RSA in gpg? [Probably not]
> 
> Actually yes, that’s exactly what happens. The data (in your
> case, the contents of your file) is symmetrically encrypted using
> a randomly generated “session key”, and *that* key is
> asymmetrically encrypted using the RSA public key.

Yep, to see this behind-the-scenes thing in action check out
"--show-session-key" and "--override-session-key" options. Described here:

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor

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

Re: NIST 800-57 compatible unattended encryption?

2019-01-02 Thread Damien Goutte-Gattat via Gnupg-users 
Hi,

On Wed, Jan 02, 2019 at 04:02:03PM +1100, gn...@raf.org wrote:
> For some dumb reason I think I was hoping that the RSA
> algorithm wasn't really used to encrypt all the data. I
> thought it was probably used to encrypt a per-file
> randomly-generated symmetric key which was then used to
> encrypt the file (and was encrypted along with the
> file) because it could be faster. But I think I'm
> confusing it with network protocols like TLS.
> 
> Is that what happens with RSA in gpg? [Probably not]

Actually yes, that’s exactly what happens. The data (in your
case, the contents of your file) is symmetrically encrypted using
a randomly generated “session key”, and *that* key is
asymmetrically encrypted using the RSA public key.

Cheers,

- Damien


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