Re: Why gpg 2.1.9 cannot export secret key without passphrase?

[Andrey Utkin]

On 27.11.2015 13:28, Peter Lebbing wrote:
> I think it makes sense to be able to store a private key without a passphrase 
> in
> a safe place (as in: an actual safe), so you don't run the risk that you 
> forgot
> the passphrase. Currently, this is not possible

Is it impossible straight from RFC 4880 in any defined mode, or is it
just a wrong behaviour in GnuPG/Libgcrypt? Empty passphrases are banned
in several places in this software:

gnupg: agent/protect.c: 1218 (hash_passphrase())
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/protect.c;h=cdb39fd1310dd539b3fa88f55e117a9aeecdb1e9;hb=refs/heads/master#l1218
libgcrypt: cipher/kdf.c: 245 (_gcry_kdf_derive())
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=cipher/kdf.c;h=ad5c46efdce696896f60521f8fe856ea102e6950;hb=refs/heads/master#l245

I haven't learned the RFC yet, so any quick tips are very appreciated.

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

Re: Why gpg 2.1.9 cannot export secret key without passphrase?

[Peter Lebbing]

On 30/11/15 20:10, Andrey Utkin wrote:
> Is it impossible straight from RFC 4880 in any defined mode, or is
> it just a wrong behaviour in GnuPG/Libgcrypt?

It is a specific bug of GnuPG 2.1, and Werner's comment on the bug entry
mentioned here makes me believe he intends to fix it eventually.

GnuPG 1.4 and 2.0 can export keys without passphrases, and this is fully
defined in RFC 4880.

> Empty passphrases are banned in several places in this software:

Yes; that's because there is a difference between not encrypting stuff
and encrypting it with an empty passphrase :). The latter is just silly.
The only purpose of doing that is to be able to tell your client that
you "encrypted it" without technically lying. And I'm not making stuff
up. This actually happens (I'm looking at you, DropBox!).

When a private key is stored without a passphrase, it is stored without
encryption. The actual packet looks different: it clearly indicates that
what follows is plaintext. If you were to encrypt it with an empty
passphrase, it would actually be encrypted, but with a key that
corresponds to an empty passphrase and hence would be trivially cracked
by anyone.

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

problems decrypting ASCII-armored file

[Ryan Hoffman]

Hello,

I encrypted a file (on Mac OSX) some time ago using:

> gpg -ca filename

And then uploaded the outputted file to Google Docs.

Some time later I downloaded the file, and I can't even get gpg to sink its
teeth in:

> gpg filename
gpg: no valid OpenPGP data found.
gpg: processing message failed: eof

I'm using the following version to decrypt:
> gpg --version
gpg (GnuPG) 1.4.16
Copyright (C) 2013 Free Software Foundation, Inc.

Here's the file's header as viewed with "less" (the starting non-printing
character is suspicious):
-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.1 (Darwin)
jA0EAwMCLguhB+jNpUJgye3pjG0GqOKYEV/k0xsrH1Ui+qfJd4+BQzJmoo9T+dO+
KIuPgjIgAjpIuG/Eq+za/pXROVsruw+Iw9KsJ55GhfHuFBOJnWGjeNSNn0ExO+TA


And here's how the file end:
fFP/Cdd8aYkpBFtuvDu9dlT9sAGbm4SfcJjjSrgBlco7LQVhKXAxzaIvit+FNg8l
e9Il0fX6NVBy3hE=
=LF2x
-END PGP MESSAGE-

Any suggestions?

Thanks,

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

Re: How important are Admin PIN and Passphrase in this scenario?

[NIIBE Yutaka]

On 11/30/2015 08:04 AM, Daniel Krebs wrote:
> There is a smartcard with subkeys for encryption, signing and
> authentication.
[...]
> In any case there seems to
> be no really benefit of using extraordinary strong admin pin because
> there are only three tries before the card get rendered unusable. The
> passphrase is only used in the secure environment.

I agree your argument in general.  I think that it depends on the
smartcard implementation, its strength against physical attacks,
and how you protect/detect your smartcard against possible steal.

If the implementation stores your private key as raw data with no
encryption (and use pin/passphrase only for authentication), complex
pin/passphrase doesn't matter, perhaps.

When the implementation stores your private key encrypted by
pin/passphrase and the hardware is relatively weak by physical
attacks, pin/passphrase with enough entropy still makes sense
(somehow).

Suppose I have a practice to use my token everyday and I always make
sure having it, so that I can know its non-existence.  Then, when I
lost my token, if I could believe that it would take a week (to break
the token phisically + to break encryption by brute force) by
complex passphrase, it makes sense for me.
-- 

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

Re: [RFC] Keychain for GPG, SSH, X.509 etc. (inspired by Split GPG)

[Andrey Utkin]

On 28.11.2015 17:36, Peter Lebbing wrote:
> On 27/11/15 22:55, Andrey Utkin wrote:
>> Any comments?
> 
> Could you outline a sequence of steps that goes wrong without your
> solution and right with it?
> 
> Like:
> 
> - SSH to compromised PC
> - Use SSH agent forwarding
> - While logged in to compromised PC, SSH from there to another
> 
> Wrong:
> - Compromised PC opens whole host of SSH connections purporting to be you
> 
> Right:
> - Keychain confirmation server comes in guns blazing, data center
> containing compromised server turns into mushroom cloud
> - Mushroom clouds don't impersonate sysadmins
> 
> I'd like to see a detailed usage scenario. Preferably with mushroom clouds.
> 
> Peter.
> 

Thanks for your interest.
Your joke describes one of usage scenarios quite well :)
Let me describe how exactly this is supposed to work when key must be used.

The whole process still looks similar to smartcard key usage, especially
regarding user's action to enable key access operation (PIN entry). So
it is easier to start with looking at using smartcard.

Note: I have no practical experience with actual OpenPGP smartcards and
I'm not convinced with their usability enough to spend couple of
hundreds of bucks or more (with shipping cost) to try them. As far as I
see there is a common problem with reviewing what exactly is being
encrypted/signed. I was told on another forum that this issue is solved
by pinpads with displays, like this one (sorry for russian):
http://www.rutoken.ru/products/all/rutoken-pinpad/ , but this is what I
otherwise see for "pgp smartcard pinpad":
https://www.google.com/search?q=pgp+smartcard+pinpad=isch
Why not to make such review and confirmation operation fully
software-defined, overcoming limitations of hardware appliances? This
idea is even more appealing when you consider the accessibility of both
VPSs and handheld devices with great displays? VPS or handhelds are
attackable, but their availability allows user to set up one dedicated
to keys operation, keeping attack surface of key vault minimal.

This is what is wrong with the case of smartcards in my opinion.
In a word:
- costs money ( -> won't be chosen by a lot of people despite the rise
of interest to privacy);
- costs even more money and/or time to get it in far countries (good
stuff is not quite available locally, or is, but for very high price);
- key length limitations on certain hardware solutions (can't say for
all, but I guess that 's true for majority of available hardware);
- hard to use large set of keys.


Let's also look at the case when we use local keys just on a local
machine (as I do now, being unwilling to go with smartcards).

Consider the case that user has just one full-blown workstation at hand,
and needs to use untrustworthy software like browsers and closed-source
apps. The workstation is not powerful enough to jail all untrusted
applications to virtual machines like Qubes OS project proposes. (Even
if it is powerful enough, Qubes OS is far from being production-ready,
and manual AppVM handling without Qubes is pain.) In this case, what is
primarily important is to store keys (and, well, all sensitive data)
anywhere but locally. This looks like the situation with SSH agent
forwarding to untrusted host (regarding that we don't want to store keys
on it), but with the difference that we _start_ on an untrusted machine
and we are not ssh-ed to it from anywhere. So even without confirmation
control, remoting the keys operation is beneficial. And if we add user
confirmation interface, then we eliminate the risk of what you have
described as "Compromised PC opens whole host of SSH connections
purporting to be you".
The confirmation interface can be implemented in any convenient way.
E.g. the confirmation dialog may be raised on a network-enabled
smartphone; keys may be stored on smartphone or on a remote server.

So, my speculations make me think that I want to implement what I have
described in original posting, and that I would want it the same way
even if I used smartcards daily.

I am sorry if all my long posts don't explain a lot to you or don't make
a lot of sense. I raised the discussion here in hope to gather opinions
or get directed towards ready-to-use solutions not known to me before.
Now I see that it probably makes sense to try to implement this schema
in a limited scope, see how it goes, describe it comprehensively (with
mushroom clouds, as requested) and present it here for review.
Thanks.




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

Re: problems decrypting ASCII-armored file

[Robert J. Hansen]

On 11/30/15 5:41 PM, Andrew Gallagher wrote:
> That's a Unicode byte order mark. Strictly, it should only be used in
> UTF-16 documents but in the real world it's commonly used to mark any
> Unicode file

It's a UTF-16BE BOM, you mean.  The UTF-8 BOM is 0xEF 0xBB 0xBF.

It's a little weird.  You don't see much UTF-16BE out there.

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

Malware detected

[Dale Sander]

I downloaded gpupg for windows, during the installation Webroot Endpoint 
Protection reported that GSPAWN-WIN32-HELPER.EXE was infected with 
W32.Malware.Gen and was blocked.. has the source code been infected or is this 
some kind of false detection?

Thank you,

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

Re: Why gpg 2.1.9 cannot export secret key without passphrase?

[Andrey Utkin]

On 30.11.2015 21:53, Peter Lebbing wrote:
> On 30/11/15 20:10, Andrey Utkin wrote:
>> Is it impossible straight from RFC 4880 in any defined mode, or is
>> it just a wrong behaviour in GnuPG/Libgcrypt?
> 
> It is a specific bug of GnuPG 2.1, and Werner's comment on the bug entry
> mentioned here makes me believe he intends to fix it eventually.
> 
> GnuPG 1.4 and 2.0 can export keys without passphrases, and this is fully
> defined in RFC 4880.

Thanks for clarification. I'd be glad to help Werner to fix it if he has
no time.
Could you please direct me to exact S2K-stuff modes for exporting it
which would be compliant with earlier GnuPG branches 1.4 and 2.0? Then I
would have a chance to accomplish the fix in finite time.

>> Empty passphrases are banned in several places in this software:
> 
> Yes; that's because there is a difference between not encrypting stuff
> and encrypting it with an empty passphrase :). The latter is just silly.
> The only purpose of doing that is to be able to tell your client that
> you "encrypted it" without technically lying. And I'm not making stuff
> up. This actually happens (I'm looking at you, DropBox!).
> 
> When a private key is stored without a passphrase, it is stored without
> encryption. The actual packet looks different: it clearly indicates that
> what follows is plaintext. If you were to encrypt it with an empty
> passphrase, it would actually be encrypted, but with a key that
> corresponds to an empty passphrase and hence would be trivially cracked
> by anyone.

Surely these two ways are distinguishable. But for unattended processing
cases, I'd like a mode that makes utils skip all passphrase entry
prompts. I guess the no-encryption case ("trivially cracked by anyone")
is needed here.
Which of the mentioned modes was used in 1.4 and 2.0 for exporting
without passphrase?




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

Re: problems decrypting ASCII-armored file

[Andrew Gallagher]

> 
> Here's the file's header as viewed with "less" (the starting non-printing 
> character is suspicious):
> -BEGIN PGP MESSAGE-

That's a Unicode byte order mark. Strictly, it should only be used in UTF-16 
documents but in the real world it's commonly used to mark any Unicode file. 
I'm assuming this is a UTF-8 file? If so, you should just be able to delete the 
character using vim or similar and try again.

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

Re: scdaemon lockup with Yubikey NEO

[NIIBE Yutaka]

On 12/01/2015 08:19 AM, the...@otpme.org wrote:
> So are any devs reading on this list? The problem is reproducible
> and i am willing to help debugging and whatever is needed to fix the
> issue. :)

Yes.

It is not reproducible for me.  I'm using OpenSSH 6.9p1.

>> i've done some more testing and found out that the problem starts to
>> exist with openssh version 6.8p1. With 6.7p1 everything works perfect.
>> I downloaded the openssh tarballs one by one, compiled with
>> ./configure;make and just copied the "ssh" binary.
>>
>> I was able to reproduce the problem with the following steps:
>>
>> 1. Start gpg-agent: eval $(gpg-agent --daemon --enable-ssh-support
>> --log-file ~/.gnupg/gpg-agent.log)
>> 2. Login to any host with your SSH key and keep the session open: ssh
>> -l root localhost
>> 3. Plug your yubikey out/in
>> 4. Try to login with your SSH key to any other host

Do you have multiple gpg-agent when you encounter failure?  Or
multiple scdaemon?
-- 

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