Re: Implications of a common private keys directory in 2.1

[Carola Grunwald]

Peter Lebbing  wrote:

>On 24/11/16 14:16, Carola Grunwald wrote:
>> WME combined with nym server usage for example requires an individual
>> WME key for each account, as otherwise at least the recipient, who may
>> communicate with different aliases is able to link them based on their
>> common signature key-ID.
>
>I don't understand this. Could you give an example or something, to help
>me understand?

Let's just say I hold two nym accounts at different nym servers

https://en.wikipedia.org/wiki/Pseudononymous_remailer#Contemporary_nym_servers

and send WME encapsulated mail through both of them to a single
recipient making him believe he talks to two different persons.

In this case the From: address of the message sent by my mail client
tells the proxy that it's nym mail. In addition to that the From: and
the To: address can be found in the WME participants list with 'Sign'
activated for the From: entry.

That's why the proxy clears the message header section, WME encrypts the
whole message for the recipient signing it with its individual WME key
(which can be the nym server account key), encrypts it for the nym
server signed with the nym server account's key and sends the result
through the remailer network to the nym server, which removes the nym
server encoding layer checking the account signature and sends the
resulting WME message to the recipient.

If now both of your nym accounts al...@nymserva.net and b...@nymservb.org
sign with the same WME key the recipient, to whom that similarity
becomes apparent, may wonder whether the obviously single author of
these messages suffers from dissociative identity disorder.

>
>AFAICS, the recipient needs a way to send mail back to the sender, and
>hence, a domain name for the sender. Having the signature tell them
>which domain name the sender used, tells them nothing. Unless of course
>you don't want pseudonymous, but anonymous mail. In the latter case, a
>signature is meaningless and should just be omitted altogether.
>
>> Concerning faked timestamps you have to imagine that an adversary may
>> observe your Tor connections. When he sees high activity shortly after
>> the signature's timestamp you may have transmitted the respective
>> message.
>
>And how will the adversary see this timestamp? It's encrypted to the
>recipient! Surely, if he has the timestamp, he has the plaintext of the
>mail and the timestamp is probably the least of your problems. I'm
>really not getting this concern! Huh?!

Simple answer: You never know who your opponents are. How can you be
sure the recipient of your mail isn't one of them? Or his network
infiltrated and his computer compromised?

Footnote:
A pinch of paranoia helps develop solid anonymity software.
Act as if there's no one out there you can trust.

Kind regards

Caro

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

Re: Is --export-ssh-key functionality possible with GnuPG 2.0?

[Peter Lebbing]

On 24/11/16 20:56, Peter Lebbing wrote:
> This is not true if you are on an NFS share, though!

I mean: if you're on an NFS share, or an a disk partition from which
things are shared over NFS. So if you're sharing /srv/export and you're
on /srv/somewhere/else, it's still not safe.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: Is --export-ssh-key functionality possible with GnuPG 2.0?

[Peter Lebbing]

Stephan, thanks for helping out! I think I can improve a bit on one part
of it, though.

On 24/11/16 17:51, Stephan Beck wrote:
> A2) Export the secret subkey you'd like to use for ssh authentication
> purposes and pipe it through openpgp2ssh
> gpg2 --export-secret-subkeys \
>   --export-options export-reset-subkey-passwd [keyID!] | \
>   openpgp2ssh [keyID] > gpg-auth-keyfile
> 
> A3) Set correct permissions
> 
> chmod 0600 gpg-auth-keyfile

This leaves open a window where the file with your private key might be
world-readable.

The thing I usually do is this:

$ mkdir safe
$ chmod 700 safe
$ cd safe
$ [... do your stuff ...]
$ cd ..
$ rm -rf safe

The directory permissions prevent anyone from getting a handle for your
file. Even if the file is world-readable, nobody can get towards the
file. This is not true if you are on an NFS share, though!

The thing I would expect to actually be in the textbooks is a variation of:

$ OLD_UMASK=$(umask)
$ umask 0077
$ [... do your stuff ...]
$ umask $OLD_UMASK

The umask 0077 will create any new files with all access rights cleared
for group and world. This is your A2 and A3 folded into one, safely,
without a gap.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: Is --export-ssh-key functionality possible with GnuPG 2.0?

[Peter Lebbing]

On 2016-11-24 18:36, Peter Lebbing wrote:

keyinfo --list


No, that's wrong, scratch that. That will not work for OpenPGP keys 
because those aren't handled by the agent in 2.0. Silly me.


I'm not sure you can add an OpenPGP auth subkey to the agent's SSH 
support without resorting to external tools, i.e., follow the method 
Stephan gave.


Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: Is --export-ssh-key functionality possible with GnuPG 2.0?

[Peter Lebbing]

On 2016-11-24 16:59, Teemu Likonen wrote:

I believe that file ~/.gnupg/sshcontrol should contain
key's keygrip but how do I get the keygrip when there's no
--with-keygrip option in 2.0?


I think the following:

$ gpg-connect-agent

help keyinfo

# KEYINFO [--[ssh-]list] [--data] [--ssh-fpr] [--with-ssh] 
#
# Return information about the key specified by the KEYGRIP.  If the
# key is not available GPG_ERR_NOT_FOUND is returned.  If the option
# --list is given the keygrip is ignored and information about all
# available keys are returned.  If --ssh-list is given information
# about all keys listed in the sshcontrol are returned.  With --with-ssh
# information from sshcontrol is always added to the info. Unless --data
# is given, the information is returned as a status line using the 
format:

#
#   KEYINFO - -   
#
# KEYGRIP is the keygrip.
#
# TYPE describes the type of the key:
# 'D' - Regular key stored on disk,
# 'T' - Key is stored on a smartcard (token),
# 'X' - Unknown type,
# '-' - Key is missing.
#
# SERIALNO is an ASCII string with the serial number of the
#  smartcard.  If the serial number is not known a single
#  dash '-' is used instead.
#
# IDSTR is the IDSTR used to distinguish keys on a smartcard.  If it
#   is not known a dash is used instead.
#
# FPR returns the formatted ssh-style fingerprint of the key.  It is 
only
# printed if the option --ssh-fpr has been used.  It defaults to 
'-'.

#
# TTL is the TTL in seconds for that key or '-' if n/a.
#
# FLAGS is a word consisting of one-letter flags:
#   'D' - The key has been disabled,
#   'S' - The key is listed in sshcontrol (requires --with-ssh),
#   'c' - Use of the key needs to be confirmed,
#   '-' - No flags given.
#
# More information may be added in the future.
OK

keyinfo --list

[...]

I just can't think of how to pick out the right key now... What little 
detail is eluding me?


HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: Is --export-ssh-key functionality possible with GnuPG 2.0?

[Stephan Beck]

Hi Teemu,

Teemu Likonen:
> Keys with authentication capability can be used with ssh, and GnuPG
> 2.1's command --export-ssh-key will export the ssh public key. Right?

Yes, --export-ssh-key has been introduced in gpg with release of version
2.1.11.
To set the whole thing up, a few more steps are necessary
(--enable-ssh-support in gpg.conf still is necessary AFAIK, but this is
the "new" export command.
> 
> Unfortunately I have GnuPG 2.0.26 (as packaged in Debian 8). Can it be
> told to export ssh public keys?

Yes, but it's a bit more laborious in comparison to gpg >= 2.1.11

A) You do not use a smart card --> B) you use a smart card
A1) Install the monkeysphere package (1) that includes openpgp2ssh tool
A2) Export the secret subkey you'd like to use for ssh authentication
purposes and pipe it through openpgp2ssh
gpg2 --export-secret-subkeys \
  --export-options export-reset-subkey-passwd [keyID!] | \
  openpgp2ssh [keyID] > gpg-auth-keyfile

A3) Set correct permissions

chmod 0600 gpg-auth-keyfile

A4) Add the key to the agent
ssh-add gpg-auth-key-file

A4) Check that the key effectively is loaded

ssh-add -l

A5) Extract the *public* key for use in the ~/.ssh/authorized_keys file

ssh-add -L

OR

gpgkey2ssh [keyID]


B) You use a smart card and have it inserted

Transfer your secret authentication subkey to the smart card by typing first

B1) gpg2 --edit-key [keyID]

Toggle and select the correct subkey

B2) gpg> toggle

B3) key [N]
N depends on the number of subkeys and describes the position of the key
in the listing

B4) Transfer the authentication subkey to the card

gpg> keytocard

Select the correct slot of the card for the auth subkey to be stored
Usually, it's "3"

B5) Enter passphrase

B6) Enter your card ADMIN PIN

B7) gpg> save


Cheers

Stephan


List member Damien Goute-Gattat has an excellent write-up to be found at:
https://incenp.org/notes/2014/index.html


0x4218732B.asc
Description: application/pgp-keys


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

Re: Is --export-ssh-key functionality possible with GnuPG 2.0?

[Teemu Likonen]

Peter Lebbing [2016-11-24 16:04:42+01] wrote:

> On 24/11/16 15:27, Teemu Likonen wrote:
>> Unfortunately I have GnuPG 2.0.26 (as packaged in Debian 8). Can it be
>> told to export ssh public keys?
>
> I think 2.0 also supported:
>
> $ ssh-add -L
>
> to list all SSH keys known to the agent. ssh-add is part of the
> openssh-client package.

That works if the key is already known to the gpg-agent but it seems
that gpg 2.0 has also a problem in making A-capable keys known to ssh
agent protocol. I believe that file ~/.gnupg/sshcontrol should contain
key's keygrip but how do I get the keygrip when there's no
--with-keygrip option in 2.0?

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


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

Re: Is --export-ssh-key functionality possible with GnuPG 2.0?

[Peter Lebbing]

On 24/11/16 15:27, Teemu Likonen wrote:
> Unfortunately I have GnuPG 2.0.26 (as packaged in Debian 8). Can it be
> told to export ssh public keys?

I think 2.0 also supported:

$ ssh-add -L

to list all SSH keys known to the agent. ssh-add is part of the
openssh-client package.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Is --export-ssh-key functionality possible with GnuPG 2.0?

[Teemu Likonen]

Keys with authentication capability can be used with ssh, and GnuPG
2.1's command --export-ssh-key will export the ssh public key. Right?

Unfortunately I have GnuPG 2.0.26 (as packaged in Debian 8). Can it be
told to export ssh public keys?

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


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

Re: Implications of a common private keys directory in 2.1

[Carola Grunwald]

MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> wrote:

>Have you looked at all at Mike Ingle's "Confidant Mail" (CM)
>? Maybe your signing/encryption servers
>at each end could incorporate a CM-to-SMTP gateway; CM could be
>awesome it were possible to compose and read messages on an ordinary
>mail client.

No, I wasn't aware of Confidant Mail.

I have a different approach to transmit bulk data anonymously.

Sending a larger mail message through the remailer network is a lengthy
process, as it is transferred in uniform 4 kB mail packets, from which
the exit remailer reconstructs the original message. But as my system
incorporates Tor, it offers another solution to that problem.

Apart from hidden services, which allow to contact the integrated POP3,
SMTP and NNTP proxy from all over the world without having to deal with
DDNS services you can also set up HTTP hidden services to allow others
to download files anonymously. Send the recipient anonymously the .onion
address of the file you offer and after installing a Tor Browser he's
able to download it through the Tor network. You yourself remain
anonymous, which is why that's a tool whistleblowers can use to forward
larger documents.

Compared with standard Tor communication a custom made protocol may
stand out and be easily detectable by an adversary.

So I'm not sure how CM can help to improve my system. But I'm always
open to suggestions.

Kind regards

Caro

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

Re: Implications of a common private keys directory in 2.1

[Peter Lebbing]

On 24/11/16 14:16, Carola Grunwald wrote:
> WME combined with nym server usage for example requires an individual
> WME key for each account, as otherwise at least the recipient, who may
> communicate with different aliases is able to link them based on their
> common signature key-ID.

I don't understand this. Could you give an example or something, to help
me understand?

AFAICS, the recipient needs a way to send mail back to the sender, and
hence, a domain name for the sender. Having the signature tell them
which domain name the sender used, tells them nothing. Unless of course
you don't want pseudonymous, but anonymous mail. In the latter case, a
signature is meaningless and should just be omitted altogether.

> Concerning faked timestamps you have to imagine that an adversary may
> observe your Tor connections. When he sees high activity shortly after
> the signature's timestamp you may have transmitted the respective
> message.

And how will the adversary see this timestamp? It's encrypted to the
recipient! Surely, if he has the timestamp, he has the plaintext of the
mail and the timestamp is probably the least of your problems. I'm
really not getting this concern! Huh?!

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: Implications of a common private keys directory in 2.1

[Carola Grunwald]

Peter Lebbing  wrote:

>On 24/11/16 00:09, Carola Grunwald wrote:
>> When you deal with pseudonymity you have to avoid similarities of
>> your aliases. So the WME keys they use to secure their messages have
>> to be different.
>
>I still don't see why you need per-user keys.
>
>OpenPGP, or at least as produced by GnuPG, is Sign-Then-Encrypt. If each
>Message Submission Agent and each post office (POP3, IMAP) server had
>their own key (you could use --throw-keyids or --hidden-recipient), it
>could be as follows:
>
>User sends from . Intended recipient is
>.
>
>Message Submission Agent for example.org adds a header indicating it was
>alice who succesfully authenticated, and other interesting stuff. MSA
>then signs and encrypts the whole message. Encryption recipient is the
>nowhere-special.org post office server (but --throw-keyids). MSA creates
>a new shell RFC822 e-mail message with everything removed but the SMTP
>recipient  (this is a special address I'm
>inventing for the protocol).
>
>We now have a message that only leaks the fact that nowhere-special.org
>is the receiving domain. The OpenPGP thingy itself leaks nothing. The
>signature has a correct, normal timestamp, but this data is encrypted.
>The recipient of the encryption is unknown (but can be inferred to be
>nowhere-special.org, so it's not that useful to use --throw-keyids
>perhaps). It's just an encrypted blob.
>
>This goes through all the remailers, is beamed into space, buried for
>some time on the dark side of the moon, etcetera.
>
>Once it reaches nowhere-special.org, the process listening on
> decrypts the message using its own private
>key. It checks the signature is indeed from its established peer server
>at example.org. It knows when example.org signed the message. Then
>again, in your proposed scheme, the receiving server also has all data
>like when alice wrote it, and what she wrote. The timestamp from the
>signature adds nothing substantial. The post office server then delivers
>the message in the recipient mailbox, with some status headers.
>
>
>
>As I said, I don't see what different keys for different accounts add
>here. And I don't see why the intended recipient can't know of the
>signature timestamp, so you don't need --faked-system-time. You could
>use GnuPG 1.4, or you could use 2.1 with a gpg-agent daemon holding just
>the private key for the server doing the crypto.

WME combined with nym server usage for example requires an individual
WME key for each account, as otherwise at least the recipient, who may
communicate with different aliases is able to link them based on their
common signature key-ID.

Concerning faked timestamps you have to imagine that an adversary may
observe your Tor connections. When he sees high activity shortly after
the signature's timestamp you may have transmitted the respective
message. And with each positive correlation on follow up messages the
connection between you and the anonymous sender becomes more and more
certain. That's just one example.

>
>Oh, by the way, in reply to a bit from another mail:
>
>On 24/11/16 00:25, Carola Grunwald wrote:
>> Peter Lebbing  wrote:
>>> If you sign the data just before the interaction, the signature
>>> time and the time noted in the Received:-header are virtually
>>> identical, so the signature time doesn't leak data.
>> 
>> No, that isn't correct. Dependent on the length of the remailer
>> chain and the individual latency of the involved hops there may be
>> hours, even days between the signing process at the sender and the
>> final message transfer from the exit remailer to the recipient's
>> MTA.
>
>It's not really that relevant, but anyway: as I said in the next
>paragraph, this was all assuming you were using a regular mail
>transport, not remailers.

I know, but unfortunately this thread became more and more a discussion
about my project, which I didn't intend, and not the problem why I
started it.

Kind regards

Caro

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

Re: Implications of a common private keys directory in 2.1

[Peter Lebbing]

On 24/11/16 00:09, Carola Grunwald wrote:
> When you deal with pseudonymity you have to avoid similarities of
> your aliases. So the WME keys they use to secure their messages have
> to be different.

I still don't see why you need per-user keys.

OpenPGP, or at least as produced by GnuPG, is Sign-Then-Encrypt. If each
Message Submission Agent and each post office (POP3, IMAP) server had
their own key (you could use --throw-keyids or --hidden-recipient), it
could be as follows:

User sends from . Intended recipient is
.

Message Submission Agent for example.org adds a header indicating it was
alice who succesfully authenticated, and other interesting stuff. MSA
then signs and encrypts the whole message. Encryption recipient is the
nowhere-special.org post office server (but --throw-keyids). MSA creates
a new shell RFC822 e-mail message with everything removed but the SMTP
recipient  (this is a special address I'm
inventing for the protocol).

We now have a message that only leaks the fact that nowhere-special.org
is the receiving domain. The OpenPGP thingy itself leaks nothing. The
signature has a correct, normal timestamp, but this data is encrypted.
The recipient of the encryption is unknown (but can be inferred to be
nowhere-special.org, so it's not that useful to use --throw-keyids
perhaps). It's just an encrypted blob.

This goes through all the remailers, is beamed into space, buried for
some time on the dark side of the moon, etcetera.

Once it reaches nowhere-special.org, the process listening on
 decrypts the message using its own private
key. It checks the signature is indeed from its established peer server
at example.org. It knows when example.org signed the message. Then
again, in your proposed scheme, the receiving server also has all data
like when alice wrote it, and what she wrote. The timestamp from the
signature adds nothing substantial. The post office server then delivers
the message in the recipient mailbox, with some status headers.



As I said, I don't see what different keys for different accounts add
here. And I don't see why the intended recipient can't know of the
signature timestamp, so you don't need --faked-system-time. You could
use GnuPG 1.4, or you could use 2.1 with a gpg-agent daemon holding just
the private key for the server doing the crypto.

Oh, by the way, in reply to a bit from another mail:

On 24/11/16 00:25, Carola Grunwald wrote:
> Peter Lebbing  wrote:
>> If you sign the data just before the interaction, the signature
>> time and the time noted in the Received:-header are virtually
>> identical, so the signature time doesn't leak data.
> 
> No, that isn't correct. Dependent on the length of the remailer
> chain and the individual latency of the involved hops there may be
> hours, even days between the signing process at the sender and the
> final message transfer from the exit remailer to the recipient's
> MTA.

It's not really that relevant, but anyway: as I said in the next
paragraph, this was all assuming you were using a regular mail
transport, not remailers.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: configure warnings and errors upon ./configure for Pinentry v0.9.7

[David Adamson]

I wasn't exactly methodical in my approach to resolve the issue but I
"think" what resolved my issue preventing me from generating keys was
following Stephan's suggestion of adding to .bashrc, which I had done
and was still getting the issue but tonight I added the lines to
.bashrc of root.

Or it could have been Peter's suggestion of rm trustdb.gpg.

Anyhow I have successfully generated pub and secret key.  I am getting
a gui pop up requesting I enter a passphrase when generating a key
which was not my initial goal but I'm glad to have something working
than nothing.

I have a feeling I'm not out of the woods quite yet but that's ok.  I
appreciate you guys helping me work through this gpg software.  I
still have lots of questions about what kind of questions I should
have but that will come.


David

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