error in GPA

2017-01-26 Thread Reid Vail 
Hello GNuPG team -

was trying to create a key pair in GPA and got the following error 

"The GPGME library returned and unexpected error at gpagenkeyadvop.c199. The 
error
was:  General Error"

"This is either an installation problem or a bug in GPA. GPA will now try to 
recover
from this error. "


Can you help.

Reid

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

Re: I'm confused about GPG, and it's confused about me

2017-01-26 Thread Reid Vail 
Hello Vedaal -

Sorry if top-posting is bad 'Net manners.

Thank for your reply.  Trying to follow your instructions, really. And not 
trying to
be too slow to follow.  Below are the steps I took, and the results.

Your suggestions were very straight forward but I couldn't get them to work.  
When I
used Seahorse and tried to create a new keypair it never seemed to complete. I 
know
wants random input and keystrokes to help create the keys.  Tried it several 
times
but it never succeeded.  I also tried GPA and ran it with the same intent, 
executed
all kinds of activity to generate random data.  The progress bar in the 
Generating
Key box completed but I never saw a message that said it completed 
successfully, and
the new key (if it ever did complete) never showed in the Key Manager screen.

Next I  ran GnuPG manually at the command-line and that did succeed.  I figured 
I
could manually use that new key to sign the public key was trying send to, 
which is
the goal.

I executed the following to show the public key I was trying to sign:

rsv2@rsv2-Serval-Pro ~ $ gpg --with-fingerprint rsv869@runbox.com_public.asc
pub  2048R/26F66FEB 2016-11-09 Reid Vail 
  Key fingerprint = 3A74 A1DB 2C79 6657 D14B  A6B8 3EDE 6A32 26F6 6FEB
sub  2048R/14C2E935 2016-11-09
pub  2048R/A780EFF6 2017-01-17 Reid Vail (runbox) 
  Key fingerprint = 1F35 6DC3 3182 016A 8E59  E509 9A72 F153 A780 EFF6
sub  2048R/1ED8FE07 2017-01-17

The one I want to sign is A780EFF6.
--
rsv2@rsv2-Serval-Pro ~ $ gpg --sign-key rsv...@runbox.com

pub  2048R/A780EFF6  created: 2017-01-17  expires: never   usage: SC  
 trust: ultimate  validity: ultimate
sub  2048R/1ED8FE07  created: 2017-01-17  expires: never   usage: E   
[ultimate] (1). Reid Vail (runbox) 

gpg: no default secret key: secret key not available

Key not changed so no update needed.


Next I tried to define it the default key... not happening  !!

rsv2@rsv2-Serval-Pro ~ $ gpg --default-key A780EFF6 --clearsign REIDgpg

You need a passphrase to unlock the secret key for
user: "Reid Vail (runbox) "
2048-bit RSA key, ID A780EFF6, created 2017-01-17

gpg: can't open `REIDgpg': No such file or directory
-

That last is obviously my misunderstanding the command structure, but the man 
pages
are just a little too opaque for me 

Any suggestions are welcome.  

RSV869


On Mon, 23 Jan 2017 15:36:18 -0500
ved...@nym.hush.com wrote:

> 
> 
> On 1/23/2017 at 1:00 PM, "reid vail"  wrote:Hi vedaal -
> 
> thanks for your response.  I'll follow those instructions.  
> 
> when you say that's the 'default' key I believe you mean it's the
> default key fore that that specific GnuPG correspondent, right?  And
> by extension, when I import any other public keys I need to sign them
> as trusted (in this case, by Seahorse), as you instructed below.  
> That's the process, I think :->
> 
> =
> 
> yes.
> 
> also, should you ever need to upgrade to a newer linux system, and
> want to import your keys,
> 
> you would need to first make a keypair in the GnuPg Seahorse or GPA or
> whatever gui you use, in the new system, and then import your keys and
> sign them the the new key
> vedaal

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

Re: Smartcard working completely with GPG2 and incompletely with GPG1.4

2017-01-26 Thread NIIBE Yutaka 
Hello,

chris.p...@gmx.de wrote:
> With GnuPG 2, signing, encrypting and decrypting a file works without
> any problems. With 1.4, I can encrypt and sign a file, but I can't
> decrypt it. It's failing with the message:
[...]
>
> gpg: public key decryption failed: general error
> gpg: decryption failed: secret key not available
[...]
> sec#  rsa4096/E728903D  created: 2014-04-12  expires: never 
> ssb>  rsa4096/3A07266F  created: 2014-04-12  expires: never 
> card-no: 0005 5031
> ssb>  rsa4096/43F27C98  created: 2017-01-24  expires: never 
> card-no: 0005 5031

I located the cause of this issue.  It is not the issue of scdaemon
incompatibility of GnuPG 2.1, which I addressed yesterday.

With GnuPG 1.4 for smartcard can't work well for RSA 4096-bit keys.  (I
think that it can also occur with the combination of GnuPG 1.4 and GnuPG
2.0.)

In the code of g10/cardglue.c, the buffer length is 1002-byte by the
definition of ASSUAN_LINELENGTH [0], but this length is not enough for
the checking at [1].  (To represent encrypted value of 4096-bit itself,
it requires 1024-byte by hex string.)

[0] 
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=include/assuan.h;h=1170f959df353f33373565c729981891dcd0100c;hb=refs/heads/STABLE-BRANCH-1-4#l91
[1] 
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/cardglue.c;h=809b315e564831aac8727d3c905e53016749f76e;hb=refs/heads/STABLE-BRANCH-1-4#l1395
-- 

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

RE: gnupg website

2017-01-26 Thread Robert J. Hansen 
> For example OpenSSH does a rekeying not later than 4 GiByte even for 128
> bit block length ciphers.

The 256GiB limitation (2**32 blocks of 2**6 bytes = 2**38 bytes; 2**30 is a
gibibyte, 2**8 is 256, hence, 256 GiB) is so well-known that it appears
multiple times in the GnuPG FAQ, even.  All the 64-bit-block ciphers have
notations of "don't encrypt more than about 4GiB of data".

(If people are wondering why we advise 4GiB when the birthday bound is
256GiB, it's because we want a large safety margin.)
 


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

Re: gnupg website

2017-01-26 Thread Glenn Rempe 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Werner, you (or anyone setting up a web server themselves really)
might also find this config generator from Mozilla helpful as a
shortcut in creating what is considered a modern web server config for
TLS.

https://mozilla.github.io/server-side-tls/ssl-config-generator/

https://wiki.mozilla.org/Security/Server_Side_TLS

This config may not apply to gnupg.org directly since its not clear
what web server you are running. In any case it will tell you which
suites you are recommended to support for modern(ish) browsers.

I would also note that there is room for improvement regarding the
security headers the gnupg.org sends with its content.

https://securityheaders.io/?q=gnupg.org=on

You are using HSTS, which is generally very good, but in this case it
forcibly breaks users experience since it requires me to connect with
TLS but that is not possible since you are not advertising a TLS suite
that shares common ground with my browser (or millions of other
potential visitors).

Cheers.

On 1/26/17 3:49 AM, Andrew Gallagher wrote:
> On 26/01/17 00:16, Andrew Gallagher wrote:
>> 
>> gnupg.org *does* keep 3DES at the end of the supported suites,
>> so surely it should not be affected. I'm tempted to write this
>> off as a mistake by ssllabs.
> 
> I've spoken to ssllabs and it appears that this was an ambiguity
> in the wording of their blog post. That means the downgrade to C
> next month is legit - not because 3DES is present, but because 3DES
> is present *and* GCM is absent.
> 
> What both this and Glenn's Apple issue have in common is the lack 
> of ECDHE+GCM suites in the cipher list. I generally use the 
> following config in Apache:
> 
> SSLCipherSuite \ "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
> EECDH+ECDSA+SHA384 \ EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
> EECDH+aRSA+SHA256 \ EECDH EDH+AESGCM EDH+aRSA +3DES 3DES \ !aNULL 
> !eNULL !LOW !EXP !MD5 !KRB5 !PSK !SRP !DSS !SEED !RC4"
> 
> This uses all HIGH suites in a sensible order but still falls back 
> to 3DES for XP compatibility. When retiring 3DES this simplifies 
> to:
> 
> SSLCipherSuite \ "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM 
> EECDH+ECDSA+SHA384 \ EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 
> EECDH+aRSA+SHA256 \ EECDH EDH+AESGCM EDH+aRSA !MEDIUM !LOW !aNULL 
> !eNULL !PSK"
> 
> Andrew.
> 
> 
> 
> ___ Gnupg-users
> mailing list Gnupg-users@gnupg.org 
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEHYo11lajUTmaOI4vCiVDbdRDnGwFAliKRHYACgkQCiVDbdRD
nGz5xg/7BITjIZlPTQ3dmTmbFx5/griGFF0gRD7oDelH7Diytqc2moQLJU0DfynZ
JBDlOkLIidzhSYQMR6ce/wzq/McV/fEuHhKsDTxDtSgU0tGe02xwg4MXCopP3OB9
6iO0zw8VwysDz+H4TDvx+/8CqwUeOBk+oRDZybZgH3xgBDVc8YsuWSCQVZJZdDEG
JEnolJeWz+fS28FFkqN+hEcmqOT0Cxo1fRXClM1hOBRCl4BxPrE5WeFYag3YT6/a
Y33GXA6+v+5lcC2il5vQY4Y1Obdn3kYK9E/aRs2gRSmEVX7rQ8lbuPRpz3WVLqFp
sUZ3BEvdXSjWPAG65xKopsaD+PnKpkzIKTcjQLy+3dx08A8l5V4wDSpjd9M86I7c
h32vByUjYq/l5rVztP8ZOkW3tq6ParyVw22VyjJGcj0LlyBnAbgcrCbw2ZsVFFnr
72Q8lfMrK8B+2YHyVz68CM54K29OAsm459OdzCcN8MXUSp33ck2TYoJxhsT+qWR6
1N2y1kb+Noq6ewYktUCwUHwwLLIoOCa3UiF1lMTpziq/rNjz0sIcvpg1ml7GymO7
8/lqxX5OyEMVACXbVQkNtwhVMagih1CWPgwZHCZWiVk/2BS85sYou0kvsxZByW44
0vRWRAbgcMWPw7viD7gVY8SksmqGblJfogKTqD382Wjp/gk1FvM=
=P0Vg
-END PGP SIGNATURE-

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

Re: sha1 pgp fingerprint

2017-01-26 Thread Werner Koch 
On Thu, 26 Jan 2017 10:56, pe...@digitalbrains.com said:

> second-preimage attack. The problems with SHA-1 are with collision
> resistance, not preimage attacks.

Correct, but we should also mention that even collissions are not yet a
current problem - but one we definitely want to be prepared for.

The whole fuzz about replacing SHA-1 from https (I write https and not
TLS for a reason) may help to learn about algorithm replacement
procedures for the future.  Replacing SHA-1 in X.509 certificates, as
used for the Web, will not magically make the Web in any way more
secure.  The problems with the Web infrastructure are not due to SHA-1
or even RSA-1024; Shamir's old rule still holds: "Crypto will not be
broken, it will by bypassed".


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: gnupg website

2017-01-26 Thread Werner Koch 
On Wed, 25 Jan 2017 23:33, r...@sixdemonbag.org said:

> That's the sort of thing that causes a lot of crypto nerds to twitch and
> mutter "rekey, rekey".

For example OpenSSH does a rekeying not later than 4 GiByte even for 128
bit block length ciphers.

The block length problem is known since we use block ciphers.  Despite
that their are practical solution for most problem domains
(i.e. rekeying) the new standard cipher contest (which led to AES) was
started back in the last millennium.  One explicit goal was to
standardize on a 128 bit block length cipher to stop thinking about this
problem.

I tried to explain in my first reply that there is no real problem in
sweet32.  The real problem is allowing to run arbitrary code on your
machine - Javascript is the simple attack vector to exploit bugs in the
client software.  Why generating incredible huge amounts of traffic for
each individual target when you can also write an exploit which works on
a large percentage of all clients.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: gnupg website

2017-01-26 Thread Filipp Gunbin 
On 25/01/2017 17:16 -0800, Glenn Rempe wrote:

> I would also like to note that gnupg.org does not appear to work on
> the latest versions of Apple iOS or macOS  Safari due to TLS cert
> issues. It fails to load in Safari on either platform (but Chrome and
> Firefox do work on macOS, Safari is the only browser on iOS).

That's true on my macOS 10.12.2.

Filipp


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

Re: gnupg website

2017-01-26 Thread Andrew Gallagher 
On 26/01/17 00:16, Andrew Gallagher wrote:
> 
> gnupg.org *does* keep 3DES at the end of the supported suites, so surely
> it should not be affected. I'm tempted to write this off as a
> mistake by ssllabs.

I've spoken to ssllabs and it appears that this was an ambiguity in the
wording of their blog post. That means the downgrade to C next month is
legit - not because 3DES is present, but because 3DES is present *and*
GCM is absent.

What both this and Glenn's Apple issue have in common is the lack of
ECDHE+GCM suites in the cipher list. I generally use the following
config in Apache:

SSLCipherSuite \
  "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
  EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 \
  EECDH EDH+AESGCM EDH+aRSA +3DES 3DES \
  !aNULL !eNULL !LOW !EXP !MD5 !KRB5 !PSK !SRP !DSS !SEED !RC4"

This uses all HIGH suites in a sensible order but still falls back to
3DES for XP compatibility. When retiring 3DES this simplifies to:

SSLCipherSuite \
  "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
  EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 \
  EECDH EDH+AESGCM EDH+aRSA !MEDIUM !LOW !aNULL !eNULL !PSK"

Andrew.



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

Re: sha1 pgp fingerprint

2017-01-26 Thread Peter Lebbing 
On 26/01/17 00:47, sivmu wrote:
> The question I have not yet found any clear answer for, is why is nobody
> talking about this and should pgp keys be identified by a stronger hash
> alogrithm in the future?

Subverting SHA-1 as used for OpenPGP fingerprints requires a
second-preimage attack. The problems with SHA-1 are with collision
resistance, not preimage attacks.

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: sha1 pgp fingerprint

2017-01-26 Thread Damien Goutte-Gattat 

On 01/26/2017 12:47 AM, sivmu wrote:

The question I have not yet found any clear answer for, is why is nobody
talking about this and should pgp keys be identified by a stronger hash
alogrithm in the future?


People *do* talk about this. But a change of the hash algorithm used for 
fingerprinting keys cannot be decided unilateraly by GnuPG developers. 
All OpenPGP implementations have to agree on such a change, that's why 
the discussions occur on the IETF OpenPGP mailing list.


See for example those threads:

https://www.ietf.org/mail-archive/web/openpgp/current/msg08265.html

https://www.ietf.org/mail-archive/web/openpgp/current/msg08693.html



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