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

[David Adamson]

On Mon, Nov 21, 2016 at 4:16 AM, Werner Koch  wrote:
>
>> configure: error: No pinentry enabled.
>
> You need to install the appropriate development package for the GUI
> platform.
>
>
> Salam-Shalom,
>
>Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

Werner was GTK+-2.0 a potential option for an appropriate development
package for the GUI platform?

After installing GTK+-2.0 I was successfully able to complete the
install of pinentry, However during the --gen-key process while
generating entropy I got the following errors:

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: lookup_hashtable failed: Unknown system error
gpg: trustdb: searching trust record failed: Unknown system error
gpg: Error: The trustdb is corrupted.
gpg: You may try to re-create the trustdb using the commands:
gpg:   cd ~/.gnupg
gpg:   gpg --export-ownertrust > otrust.tmp
gpg:   rm trustdb.gpg
gpg:   gpg --import-ownertrust < otrust.tmp
gpg: If that does not work, please consult the manual


So with one issue solved now on to the next.  I'm sorry but this can't
be right. Anyone know why I am running into so many issues?

___
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]

On Mon, Nov 21, 2016 at 8:15 PM, Stephan Beck  wrote:
> Ah, I forgot one thing: you have to add the following to your ~/.bashrc
> file:
> GPG_TTY=$(tty)
> export GPG_TTY
>
> Does it work now?
>
> HTH
>
> Stephan

Stephan I updated the .bashrc file in my home directory, still got the
same error, so I restarted the system but unfortunately the error
remains.

Thanks for the assistance.

___
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]

"Robert J. Hansen"  wrote:

>> gpg is intended to run on the client, not the server. A mail service
>operator
>> should not hold the private keys of its users, never mind perform
>encryption
>> operations on their behalf. I would question the design of your
>architecture if
>> you feel this is necessary.
>
>I concur.  This post is agreement, not dissent.
>
>A user ID on a key makes an assertion: "The person named X is in control of
>this certificate."  But in this architecture the end-user *isn't* in
>control.  You remain in complete control of the private certificate.  You
>have the power to completely undermine the system.  So for that reason, it
>seems strange to me that your users would have their own private
>certificates -- what, precisely, *could* they certify?

>But if I'm on your system, and you're the one doing signatures for me, then
>what does a signature which claims to be from me really attest?
>
>Your scheme appears to deeply subvert the meaning of signatures and
>certificate ownership.  This is crazy.  Maybe it's crazy enough to be a
>breakthrough, but so far I'm not seeing it.

Hi Andrew, hi Robert,

many thanks for your replies.

But why does a person have to be in control of a signature key? Why not
a server in the name of a company resp. its employees.

Talking about mail, when transmitting messages we currently have two
encryption principles in common use. There's server-to-server security
provided usually by SSL/TLS, where nevertheless the communication
partners can't influence the all-knowing servers building the route. And
there's true end-to-end cryptography done by PGP/SMIME at the client
applications, which also leaks valid (envelope) information thinking of
message size and structure and the enormously talkative header section.

Now let there be a corporate server, which 'cleans' the header of
outgoing mail, adds some nonsense data of random size and encrypts the
result into a single PGP message block, which it finally forwards after
adding the recipients' mail addresses as the only header line. The
message block's signature only documents the identity of the sender who
logged into the server, and, btw, with --faked-system-time doesn't even
leak whether it was processed at business hours or at midnight. At the
recipient's corporate server that mail is decrypted using the
recipient's key, the original mail structure restored, a line
representing the signature status added to the header and the result
delivered to the POP3 client.

This concept of an enhanced transport security layer offers external
adversaries least possible information while it doesn't preclude the
sender from adding another inner encryption/signature layer created with
a key she herself controls.

Hope that helps to understand what I'm aiming at.

Kind regards

Caro

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

Re: How to prevent passphrase caching in 2.1

[Carola Grunwald]

Peter Lebbing  wrote:

>On 22/11/16 17:20, Carola Grunwald wrote:
>> They don't have any system account at all. These are users of a
>> messaging system, only allowed to access its POP3, SMTP and NNTP
>> service.
>
>Perhaps 1.4 is the best release for you... you'll miss out on Elliptic
>Curve, but other than that, it's still a supported release.

Sure, I like v1.4's small footprint and its reliability. But as the
--faked-system-time option, important in my application for privacy
reasons, wasn't backported to v1.4, I had to migrate to v2.1. I'm still
not very confident in EC cryptography's strength nor am I interested in
dealing with just another background service, which freezes every now
and then and actively has to be stopped with my application to keep it
portable.

>
>> They don't have direct access to any key. Nevertheless by using someone
>> else's cached passphrase with 2.1 and its all-embracing keyring they may
>> succeed in decoding data not meant for them.
>
>Perhaps you should implement access control in your frontend, instead of
>asking the agent to perform access control, for which it was not
>intended, AFAIK.

There's server access control through a username/password combination,
access to the corresponding PGP key is given by a usually unique base64
encoded 256-bit random number dedicated to the account.

But if for decryption a cloud of unpredictable valid passphrases is used
...

> It sounds like you just want the ability to work with
>OpenPGP material, rather than the user-centric model the agent seems to
>correspond to. When GnuPG gives you a square peg, you'll have to build
>your own adapter before it fits in a round hole ;).

Well, I didn't know that GnuPG follows a single-user strategy. Now I do.

>
>By the way, I'm not recommending anything (this in response to your "do
>you seriously recommend..."). I know nothing about your application or
>what you demand of it. I'm merely trying to give you directions to look
>in, while you search for the correct architecture of your application.

I'm truly sorry, no harm intended.

Kind regards

Caro

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

Re: How to prevent passphrase caching in 2.1

[Daniel Kahn Gillmor]

On Tue 2016-11-22 11:20:26 -0500, Carola Grunwald wrote:
> They don't have direct access to any key. Nevertheless by using someone
> else's cached passphrase with 2.1 and its all-embracing keyring they may
> succeed in decoding data not meant for them.

fwiw, the same concerns hold for a shared gpg-agent passphrase-cache
from pre-2.1 versions of gpg as well, right?

your model sounds like it needs to use a separate agent per user,
regardless of which version of the agent you're using.

   --dkg

___
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

[Robert J. Hansen]

> gpg is intended to run on the client, not the server. A mail service
operator
> should not hold the private keys of its users, never mind perform
encryption
> operations on their behalf. I would question the design of your
architecture if
> you feel this is necessary.

I concur.  This post is agreement, not dissent.

A user ID on a key makes an assertion: "The person named X is in control of
this certificate."  But in this architecture the end-user *isn't* in
control.  You remain in complete control of the private certificate.  You
have the power to completely undermine the system.  So for that reason, it
seems strange to me that your users would have their own private
certificates -- what, precisely, *could* they certify?

Likewise, a signature on a message makes an assertion: "This message went
through the hands of the person who controlled this certificate, and has not
been altered since then."  (Signatures do not prove authorship: that's a
common misconception.  If Alice sends Bob a signed message saying "I love
you", and Bob strips off the signature, places his own on it, and sends it
on to Charlene, Charlene will have a message Alice authored but which Bob
signed.  Charlene can prove the message went through Bob's hands, but she
cannot prove who wrote it.)

But if I'm on your system, and you're the one doing signatures for me, then
what does a signature which claims to be from me really attest?

Your scheme appears to deeply subvert the meaning of signatures and
certificate ownership.  This is crazy.  Maybe it's crazy enough to be a
breakthrough, but so far I'm not seeing it.



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

Re: How to prevent passphrase caching in 2.1

[Peter Lebbing]

On 22/11/16 17:20, Carola Grunwald wrote:
> They don't have any system account at all. These are users of a
> messaging system, only allowed to access its POP3, SMTP and NNTP
> service.

Perhaps 1.4 is the best release for you... you'll miss out on Elliptic
Curve, but other than that, it's still a supported release.

> They don't have direct access to any key. Nevertheless by using someone
> else's cached passphrase with 2.1 and its all-embracing keyring they may
> succeed in decoding data not meant for them.

Perhaps you should implement access control in your frontend, instead of
asking the agent to perform access control, for which it was not
intended, AFAIK. It sounds like you just want the ability to work with
OpenPGP material, rather than the user-centric model the agent seems to
correspond to. When GnuPG gives you a square peg, you'll have to build
your own adapter before it fits in a round hole ;).

By the way, I'm not recommending anything (this in response to your "do
you seriously recommend..."). I know nothing about your application or
what you demand of it. I'm merely trying to give you directions to look
in, while you search for the correct architecture of your application.

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: Implications of a common private keys directory in 2.1

[Andrew Gallagher]

On 22/11/16 18:17, Carola Grunwald wrote:
> You seriously recommend to run a dedicated gpg-agent instance for each
> of dozens if not hundreds of mail service users?

gpg is intended to run on the client, not the server. A mail service
operator should not hold the private keys of its users, never mind
perform encryption operations on their behalf. I would question the
design of your architecture if you feel this is necessary.

A




signature.asc
Description: OpenPGP digital 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]

Peter Lebbing  wrote:

>On 22/11/16 02:54, Carola Grunwald wrote:
>> - In a multi-user environment the key owning recipient has to be granted
>> access to the private key with some sender being restricted to only use
>> the public key no matter whether there's any chance s/he guesses the
>> correct passphrase.
>
>That's what filesystem permissions are for? Like I just said in the
>other mail, if each user has their own system account, they can't access
>the files containing the encrypted private keys of other users.

You seriously recommend to run a dedicated gpg-agent instance for each
of dozens if not hundreds of mail service users? You have to consider
that these gpg-agent services are meant to persistent beyond the initial
data processing call. Compared with my current single-agent approach
with task-queuing not really resource-efficient, is 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 22/11/16 02:54, Carola Grunwald wrote:
> - In a multi-user environment the key owning recipient has to be granted
> access to the private key with some sender being restricted to only use
> the public key no matter whether there's any chance s/he guesses the
> correct passphrase.

That's what filesystem permissions are for? Like I just said in the
other mail, if each user has their own system account, they can't access
the files containing the encrypted private keys of other users.

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: GPGSM detached signature without auth attributes

[Jernej Kos]

Hello!

On 22. 11. 2016 08:06, Werner Koch wrote:
> That is unfortunate because all modern implementations use the
> indirect signing method (using the attribute 1.2.840.113549.1.9.4).
> GPGSM is able to verify the old direct signing method but it can't
> create such an old signature.

This explains why my quick hack with just removing the signed attributes
didn't work (I could remove everything but the messageDigest). The
indirect method uses the messageDigest that is part of the signed
attributes, right? I've also looked into how OpenSSL does it and noticed
that the signing part is done differently when the CMS_NOATTR flag is
passed.

I've quickly looked at the CMS RFCs, but they seem quite heavy. I would
be grateful for any quick pointers you might have.

> Instead of doing that I would suggest to extend Linux and implement
> verification of the indirect signature.  An update to gpgsm would then
> be simple by adding an option to not emit any of the other signed
> attributes,

Yes, that would probably be the best option and I am not sure why they
didn't do it this way. I also don't like that the default way to sign
things in the Linux kernel assumes that the private key is available in
a local file, as this is way less secure than storing it in a HSM. Had
they used gpgsm from the start, they would also find the need to support
indirect signatures.

Unfortunately I need this in a current system, so I might just look
around libksba when I find some more time.

Thanks for making things more clear!


Jernej



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

Re: GPGSM detached signature without auth attributes

[Stephan Beck]

Hi,

Jernej Kos:
> Hello!
> 
> Not sure about what you mean with the OpenPGP card not supporting
> signing? I have set gpgsm to use the signing key on the OpenPGP card (in
> key slot 1) for generating X509 certificates and CMS (S/MIME) signatures
> by doing:
> 
>   gpgsm --learn-card
>   gpgsm --gen-key
> 
> And selecting an existing key on the OpenPGP card in the key slot for
> signing. This is using GnuPG 2.1.15.
> 
[...]

sorry, I obviously got this wrong. I'll have to take a deeper look into
gpgsm and its use with smart cards.

Thanks for your answer.

Stephan


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: GPGSM detached signature without auth attributes

[Jernej Kos]

Hello!

Not sure about what you mean with the OpenPGP card not supporting
signing? I have set gpgsm to use the signing key on the OpenPGP card (in
key slot 1) for generating X509 certificates and CMS (S/MIME) signatures
by doing:

  gpgsm --learn-card
  gpgsm --gen-key

And selecting an existing key on the OpenPGP card in the key slot for
signing. This is using GnuPG 2.1.15.

I can successfully use gpgsm to sign an arbitrary file in detached mode
and can validate the signature using "openssl cms -verify". So the
signing part seems to work.

The only problem is that such a signature is rejected by the kernel due
to containing signedAttrs (the CMS structure can be inspected by running
"openssl cms -cmsout -inform DER -print -in signature.der").

I've tried removing the signed attributes from the CMS by hacking the
source of libksba and the resulting file doesn't have signedAttrs, but
for some reason the signature is then wrong. So I have to look into this
more.

Thanks!


Jernej

On 22. 11. 2016 01:58, Stephan Beck wrote:
> Hi Jerney,
> 
> Jernej Kos:
>> Hello!
>>
>> I would like to use GPGSM to sign a Linux kernel module with a private
>> key stored on an OpenPGP smartcard.
> 
> As to the OpenPGP card 2.1 [1] specification, you can store the private
> key of an X.509 certificate on card (Data Object Cardholder Certificate,
> TAG 7F21) ONLY for using it for authentication purposes in a
> client/server environment, not for signing.
> In version 3.0 of the OpenPGP card specification the decipher and sign
> capabilities for use with an PKIX/X.509 certificate have been
> introduced. Unfortunately I don't know of any existing OpenPGP smart
> card that implements version 3.0 [2].
> So, I guess, without even discussing the possibility (and further
> details) of using a "smartcard-based" X.509 certificate's private key
> with gpgsm for digitally signing a file skipping/overriding/ignoring
> CMS's auth attributes for signing a kernel module, it is not (yet)
> feasible (in practice).
> 
> My 2 cent
> 
> Stephan
> 



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