Required gnupg installation steps and pre reqest

[Rajesh Gaddam]

Hi team,

Could you please send me the  gnupg-2.1.21 installation steps by using
librarys   solaris10 and rhel6&7 I am not able access gnupg http from Unix
server because of proxy so downloaded all libs and gnupg pkg ,
Rajesh
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Operation not supported by device

[Stefan Claas]

On Thu, 27 Jul 2017 17:35:55 +0200, Kristian Fiskerstrand wrote:

> A bit more verbosely, if no scdaemon exists you will get an error
> value that was not suppressed for a few versions, you can safely
> ignore the warning and it is fixed in alter versions again, or you can
> install/build gnupg with scdaemon even if not using a smartcard and it
> will get the necessary info and be silent.
> 

Thanks again, however i do have scdaemon installed in
/usr/local/gnupg-2.1/libexec/scdaemon. But no problem.

I was just curious about that gpg message output.

Regards
Stefan



pgppm83IwLhAy.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Operation not supported by device

[Kristian Fiskerstrand]

On 07/27/2017 05:29 PM, Stefan Claas wrote:
> On Wed, 26 Jul 2017 23:41:23 +0200, Kristian Fiskerstrand wrote:
>> On 07/24/2017 04:27 PM, Stefan Claas wrote:
>>> The file is signed and can be verified. Just wondering (after
>>> googling) what this means, because i have no card reader etc. for
>>> GnuPG.  
>>
>> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=a8dd96826f8484c0ae93c954035b95c2a75c80f2
>>
> Thanks for the Info.

A bit more verbosely, if no scdaemon exists you will get an error value
that was not suppressed for a few versions, you can safely ignore the
warning and it is fixed in alter versions again, or you can
install/build gnupg with scdaemon even if not using a smartcard and it
will get the necessary info and be silent.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"By three methods we may learn wisdom: First, by reflection, which is
noblest; Second, by imitation, which is easiest; and third by
experience, which is the bitterest."
(Confucius)



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

Re: Operation not supported by device

[Stefan Claas]

On Wed, 26 Jul 2017 23:41:23 +0200, Kristian Fiskerstrand wrote:
> On 07/24/2017 04:27 PM, Stefan Claas wrote:
> > The file is signed and can be verified. Just wondering (after
> > googling) what this means, because i have no card reader etc. for
> > GnuPG.  
> 
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=a8dd96826f8484c0ae93c954035b95c2a75c80f2
> 
Thanks for the Info.

Regards
Stefan


pgpPMdq8G21Ti.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Invalid Crypto Error

[SHARMA Sandhya (MORPHO)]

Hello All,

I have to use GPG for windows.For that i have installed GPG4Win in my system 
and try to use it through C++ code using DLL libgpgme-glib-11.
Getting "Invalid crytpto Engine" while calling "gpgme_engine_check_version".

Plz find the code snippet::
void _stdcall LoadGPG()
{
gpgme_error_t error;
char* p;
gpgme_key_t recipients[2] = {NULL, NULL};
gpgme_data_t clear_text, encrypted_text;
gpgme_encrypt_result_t result;
gpgme_engine_info_t info;
gpgme_keylist_mode_t keymode;
gpgme_protocol_t proto;

/* Initialize the locale environment. */
setlocale(LC_ALL, "");
int n =gpgme_set_global_flag("disable-gpgconf","1");

n = gpgme_set_global_flag("bindir","C://Program Files (x86)GNUGnuPG");

p = (char *) gpgme_check_version (NULL);//to initialize gpg



gpgme_set_locale (NULL, LC_CTYPE, setlocale (LC_CTYPE, NULL));
#ifdef LC_MESSAGES
gpgme_set_locale (NULL, LC_MESSAGES, setlocale (LC_MESSAGES, NULL));
#endif
gpgme_ctx_t *context = (gpgme_ctx_t *)malloc(sizeof *context);
error = gpgme_new(context);
error = gpgme_set_protocol (*context, GPGME_PROTOCOL_OpenPGP);

keymode = gpgme_get_keylist_mode(*context);
info = gpgme_ctx_get_engine_info(*context);

/* Setting the output type must be done at the beginning */
gpgme_set_armor(*context, 1);

error = gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP);
pEngineinfoerror1 = gpgme_strerror(error) ;
gpgme_data_t data;
gpgme_data_t cipher;

gpgme_error_t e = gpgme_data_new();

e = gpgme_data_new();

gpgme_data_set_file_name(data, "C:\\Logs\\test.txt");
error= gpgme_op_encrypt(*context,0,(gpgme_encrypt_flags_t)0,data,cipher);
pEngineinfoerror1 = gpgme_strerror(error) ;

}
Please let me know the solution for it ASAP.


Thanks & Regards
Sandhya Sharma

#
" This e-mail and any attached documents may contain confidential or 
proprietary information. If you are not the intended recipient, you are 
notified that any dissemination, copying of this e-mail and any attachments 
thereto or use of their contents by any means whatsoever is strictly 
prohibited. If you have received this e-mail in error, please advise the sender 
immediately and delete this e-mail and all attached documents from your 
computer system."
#
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: gpg-agent cache keygrip

[Mario Figueiredo]

On Thu, 27 Jul 2017 14:23:44 +0200
Peter Lebbing  wrote:

> Now let's get on to a passphrase manager and GnuPG specifically. A
> different way to look at it is this: would you use GnuPG to protect
> your passphrase manager? This is actually a feature request I've seen
> multiple times: please provide a way to use my OpenPGP key to unlock
> my passphrase manager. In that way, the security of the passphrase
> manager is utterly dependent on the security of GnuPG. Crack GnuPG,
> and the passphrase manager falls immediately as well.

This is precisely what 'pass' (1) does. I never looked back since I
started using it.

Of note also the fact pass is not a a compiled program, but instead a
shell script smartly wrapping GnuPG functionality into the shape of a
password manager. For this reason, I don't know if anyone ever ported
the idea to Windows, but from what little I remember of Powershell, it
would be perfectly doable.

I use pass with rofi-pass to facilitate the integration with browsers
and applications, allowing me to quickly enter passwords without typing
them into any type of program that accepts keyboard input from the
clipboard. And without *any* need for plugins of any sort on those
pesky browsers.


> and those who would store their GnuPG passphrases in a
> passphrase manager.

This indeed is not so bad if is also GnuPG that is handling your
password manager. Although, I'd agree that is one thing to discover the
GnuPG passphrase for a password manager and it is another thing to also
discover that you now have the victim passwords for the remainder GnuPG
keys accessible to you.

But there are other considerations. Who am I? What I do in life? Who
are my enemies? Depending on how good we are answering these questions
in a rational way, I find that a large part of the general population
has little to no reason to fear storing sensitive GnuPG specific data
in their personal entirely-offline password store. 

As an FYI, I do not store the actual passphrases, but I do store the
0-type revocation certificates with 'pass'. I don't feel that
threatening and it tremendously facilitates things for someone without
any access to reliable and secure physical storage. There is no reason
why I couldn't store the passphrases also. I will eventually, the day I
start fearing my brain.

-- 
Sinceramente / Best regards,

Mário J.G.P. Figueiredo
Luanda, Angola
(email) mar...@gmx.com (alt) kru...@openmailbox.org
(phone) +244 934 535 121


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

Re: gpg-agent cache keygrip

[Mario Figueiredo]

On Thu, 27 Jul 2017 11:46:33 +0200
Peter Lebbing  wrote:

[...]
> shared the passphrase. If you can't remember which is 1 and which is
> 2, use something you can recognise. For instance, if the pinentry
> asks you "Please unlock key 0x6228A8BC", you could append a C, the
> very last digit of the identifier.

Excellent idea in fact!
Thank you.

-- 
Sinceramente / Best regards,

Mário J.G.P. Figueiredo
Luanda, Angola
(email) mar...@gmx.com (alt) kru...@openmailbox.org
(phone) +244 934 535 121


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

Re: gpg-agent cache keygrip

[Mario Figueiredo]

On Thu, 27 Jul 2017 12:27:30 +0100
MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> wrote:

> 
> The single point of failure stops being a passphrase used across
> multiple keys; it becomes the password required to open the password
> manager that protects the multiple passphrases.

I already use a password manager. I use 'pass'. Most my keys are
generated with `pwgen -s` (for some reason I prefer it to pass own
generator). All told, I have 83 password file entries
in .password-store/.

But these are non essential passwords. Forums, internet services, etc.
You must understand, I use old systems that I maintain for 10 years or
more. Despite backups there is always the fear that I might one day
lose this central password storage. So essential passwords are created
differently; GnuPG keys, my 2 main email addresses, system boot,
banking, taxes website, CC pin,... this world is not an easy place to
live in.

They do too have their entries on the password store, of course. But
they must be committed to memory too. As such, for these type of
passwords, you understand that a password manager acts simply as an
unreliable backup store and not and not as a management tool. 

-- 
Sinceramente / Best regards,

Mário J.G.P. Figueiredo
Luanda, Angola
(email) mar...@gmx.com (alt) kru...@openmailbox.org
(phone) +244 934 535 121


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

Re: gpg-agent cache keygrip

[Peter Lebbing]

On 27/07/17 13:27, MFPA wrote:
> I guess I should have trimmed my quote less severely. Using a password
> manager would enable somebody who says they cannot remember multiple
> decent-quality unique passwords to not share passwords between
> different keys.

Ah yes :-). I agree.

> The single point of failure stops being a passphrase used across
> multiple keys; it becomes the password required to open the password
> manager that protects the multiple passphrases.

Let's look at multiple cases of passphrase reuse:

1) Using the same passphrase for multiple remote systems

If one of the remote systems is compromised, all your accounts with the
same passphrase are compromised. Sounds to me like a bad idea. There are
many different actors and implementations. All it takes is one bad apple.

2) Using the same passphrase in multiple different programs on your own
computer.

When an attacker can compromise one of the programs, but only that, the
attacker still gains access to the encrypted data held in multiple
programs, even if the others are safe by themselves. Possible ways of
compromise that spring to mind are some way to access a running program
remotely, such as by feeding it crafted data exploiting a vulnerability
in the program, or by the fact that data at rest is not well encrypted,
using a file from a backup the attacker gained access to.

3) Using the same passphrase for multiple instances of data in the same
program.

If an attacker is able to compromise one instance, why couldn't they do
another? You might be lucky if it is an attack that requires a running
computer and the attacker only manages to entice the program once. If it
is an attack at data at rest, at poor encryption of the file, then the
workload increases a mere factor two. If they need five days to crack
the encryption of one instance, they only need yet another five days to
crack the other even if the passphrases were different.

For case 3), I'd say it is sheer luck if an attacker only learns one
passphrase rather than the multiple passphrases you use with the same
program. It's not a significant increase in security.

This way of reasoning gets you quite far. It's not completely
conclusive; for one, it depends on all instances being treated the same
way, i.e., all secret keys are stored on the same system /and/ in the
same backups. And suppose some form of key derivation can be cracked
quicker if there are multiple derivations of the same data and salting
is somehow compromised. Then it would be a bad idea to reuse a
passphrase for multiple instances, but I'd say that key derivation or
the random number generator involved is bad anyway and shouldn't be used
at all, even when you don't reuse passphrases. And there are probably a
few different scenarios where you might make yourself weaker.

But personally, without further details convincing me otherwise, I would
not be overly worried about using the same key for multiple instances in
the same program on the same system.

Furthermore, I'd say that the way GnuPG uses a passphrase is safe and an
encrypted private key file doesn't help an attacker to gain access to
the same passphrase in a different program.

Now let's get on to a passphrase manager and GnuPG specifically. A
different way to look at it is this: would you use GnuPG to protect your
passphrase manager? This is actually a feature request I've seen
multiple times: please provide a way to use my OpenPGP key to unlock my
passphrase manager. In that way, the security of the passphrase manager
is utterly dependent on the security of GnuPG. Crack GnuPG, and the
passphrase manager falls immediately as well.

Now there is one avenue left: would we mind if the security of GnuPG is
utterly dependent on the security of the passphrase manager? If you
propose to store the GnuPG passphrases in the passphrase manager,
apparently you're okay with that as well. Crack the passphrase manager,
and GnuPG has no further protections.

Okay, so let's say we don't mind if the security of GnuPG utterly
depends on the security of the passphrase manager, *or* vice versa.
Furthermore, I state pretty confidently that the way GnuPG uses
passphrases does not cause an interaction with other data being
encrypted with the same passphrase in a different program; there is no
way to crack some other piece of data, say your passphrase manager
database, quicker because you have access to the *encrypted* private
keys of GnuPG. Conversely, there is no way to crack an encrypted private
key in GnuPG quicker because some other key derivation function is used
with the same passphrase (other than to crack that other key derivation
by itself).

Then why don't you just use the same passphrase for your passphrase
manager as for your private keys in GnuPG? Again, this only goes if you
belong to both user groups touched upon: those who would consider it a
good thing if the passphrase manager unlocks with their OpenPGP private
key, and those who would store their GnuPG 

Re: gpg-agent cache keygrip

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Thursday 27 July 2017 at 10:46:33 AM, in
, Peter
Lebbing wrote:-


> On 27/07/17 11:24, MFPA wrote:
>> Have you considered using a password manager to
>> remember them?

> What would be the purpose?

I guess I should have trimmed my quote less severely. Using a password
manager would enable somebody who says they cannot remember multiple
decent-quality unique passwords to not share passwords between
different keys.



> Adding a passphrase manager only introduces another
> layer of indirection
> plus extra steps for the user to unlock their key,

Extra steps to open the password manager. Once open there are no extra
steps for subsequent unlocking of the user's GnuPG key; it may even
speed things up in the event that the password manager types
passphrases quicker than the user can type them.


> but it seems to solve
> no actual problem. It just moves the item that is of
> interest to the
> attacker.

The single point of failure stops being a passphrase used across
multiple keys; it becomes the password required to open the password
manager that protects the multiple passphrases.


- --
Best regards

MFPA  

COMMITTEE: A body that keeps minutes and wastes hours.
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWXnOJ18UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5AZ3AQCaNMl2oJ3kDWTPScP4OvPcVmsyWa7C7+ZF/aBd9m8hSAD+KuwBpBMkbpp+
y5gn1fXIMZ5NLR8OXKIWF8nR32oNvASJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWXnOMl8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8Hl8B/4xUCdIUueGMVTrU0bSd79ityjN
oJQWk15Hz5tX/3BnVnn8xJMECTquow1Nf1XmwxKyaqME9pDtXPbFBHp+WzV04glT
FD/4SgE0BPTtyadGbDHYaE0rHHPL1bzFg4f3F8uRz9otSHC6KeTLAhBJxBYQaK++
qYe2npD+IAUUU1sPluWGhrPWnu99c2Tw8REq/BH0T2sk4zwIkYTedGX1eExzH7Hw
Kjdh9uMuBa1rWfaaYfsOnDrzvkdW3kmiu8ngdE4BCVEVtzqSvmDBP8+dxgZKzESK
Bc5+HY2/pyB+0tWJ+Yaa8ilFeD9LDIbokrr/Iiyw0Frv3sVhXgrLhPYW2YYW
=2vsb
-END PGP SIGNATURE-


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

Re: gpg-agent cache keygrip

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Wednesday 26 July 2017 at 8:08:28 PM, in
, Mario Figueiredo wrote:-


> The sharing of passwords between different keys
> becomes inevitable
> after a certain threshold. And I suspect for
> everyone, not just old
> people.


Have you considered using a password manager to remember them?


- --
Best regards

MFPA  

Can you imagine a world with no hypothetical situations?
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWXmxZV8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5DonAQD5cRWxsdnp2NklcT07FSE4RC+jLKPeywbvZhTbu30lRAEAsoHz30Invp8t
kr3qhXAM1zNp7NQGO46/QYSMB2HFQQWJAZIEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWXmxcF8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8NF4B/jayHrd1Ah+0EIhT5KVu7IkQ97Z
TmFSyofuGkSQg9aweww+/iM860r6GbEaTK2mJPDnDwNhhoi+kzyISUDpcEMVHaPk
eLkgBZtD/fcneFZ2Ky3SY2Y6A9caZqz0OoNnR7yo/qWh84ApuytutSBVD/k1k714
SBBADgUNDn6GiezcEZ1kJdYEEpSwfws6DTP8YPDpiZ7T8+OO03kKSMHlp0ReSeKF
J1yKmX4ydLnv01hQewnKP2DbbX2OgQccHAhDVJ1g5AkufYdUR7LVH8C5DLLDaLgF
MNgWqCXVv+RVh8iAiwU3bD5XrzKqcxfzBcRTkMG+KyexCYAlSxgtzAPXVhg=
=lZs0
-END PGP SIGNATURE-


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