Re: [cygwin] gpg-agent with ssh support ?

[Xavier Maillard]

Doug Barton  writes:

> Otherwise, there is an easy way to solve your problem on the Windows
> platform, you should strongly consider it.

I fear I do not understand. Did I miss something ? Off course I'd
rather go the easy way ! :D

Regards
-- Xavier.

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

Re: [cygwin] gpg-agent with ssh support ?

[Doug Barton]

On 3/11/15 10:27 PM, Xavier Maillard wrote:


Doug Barton  writes:


On 3/11/15 3:15 AM, Werner Koch wrote:

The standard ssh client on Windows seems to be Putty; you may use it
with the native GnuPG for Windows (i.e. Gpg4win) by using the option
--enable-putty-support instead of --enable-ssh-support.


PuTTY also has its own agent support, which works quite well. I'm not
sure why it's necessary to reinvent the wheel here. :)


Still, one has to install a new piece of software but, in my case, it
can be ok.

So, just to be sure I understand:

1. install putty


2. Use PuTTY's agent, called Pageant.
http://the.earth.li/~sgtatham/putty/0.64/htmldoc/Chapter9.html#pageant

It comes in the PuTTY package, so nothing new to install.

Starting and running gpg-agent so that you can use it with ssh is very 
different from the "easy" socket method that is used for simple password 
entry.


If you have an actual reason to try and fit the square peg into the 
round hole, or if you're the kind of person who likes to do things the 
hard way for whatever reason, then I wish you the best of luck.


Otherwise, there is an easy way to solve your problem on the Windows 
platform, you should strongly consider it.


Good luck,

Doug


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

Re: [cygwin] gpg-agent with ssh support ?

[Xavier Maillard]

Doug Barton  writes:

> On 3/11/15 3:15 AM, Werner Koch wrote:
>> The standard ssh client on Windows seems to be Putty; you may use it
>> with the native GnuPG for Windows (i.e. Gpg4win) by using the option
>> --enable-putty-support instead of --enable-ssh-support.
>
> PuTTY also has its own agent support, which works quite well. I'm not
> sure why it's necessary to reinvent the wheel here. :)

Still, one has to install a new piece of software but, in my case, it
can be ok.

So, just to be sure I understand:

1. install putty
2. put enable-putty-support into gpg-agent.conf
3. gpg-connect-agent reloadagent /bye
4. enjoy ?

Regards
-- Xavier.

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

Re: Enigmail speed geeking

[Stephan Beck]

Hi Robert,

Am 11.03.2015 um 18:10 schrieb Robert J. Hansen:

> "Things you're doing wrong with Enigmail" is a short (500-word) essay on
> four mistakes I repeatedly see Enigmail users making.  However, it's not
> limited to Enigmail: most of the content is broadly applicable to any
> cryptosystem.
> 
> http://robert-hansen.com/?p=83


I enjoyed reading your blog. In particular, the about page is really worth 
reading.
As to your enigmail essay, point 1, would you go that far that keeping keys on
hard disk is unsafe and using a smart card is a must? I joined the list some
weeks ago and half of the messages (I'm exaggerating) were/are about smart
cards, so I take up this point here, although you might not have implied it.

TIA

Stephan





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

Re: AES-NI, symmetric key generation

[Maricel Gregoraschko]

Peter,My understanding was that if you don't pass --symmetric, then a session 
key is generated, with which the clear text is (symmetrically) encrypted and 
then the session key is encrypted (asymmetrically) with the public key. 
Conversely, if you do pass --symmetric, then there is no random-generated 
"session" key, and gpg simply generates a symmetric key from the passphrase, 
that it encrypts the clear text with. Are you saying that that is not the case, 
and there there is a session key, used to encrypt the clear text, and the 
session key gets encrypted, again, symmetrically with the passphrase-generated 
key?
However my question regarding the standardization format was not necessarily 
related to the OpenPGP protocol, but rather, at the most basic level of 
symmetric encryption in general: you have a key, a cleartext, a symmetric block 
cipher algorithm and a mode of operation . Is the format of the output 
standardized within this context, of a symmetric block cipher encryption, 
rather than as part of OpenPGP? Would another software or encryption library be 
able to decrypt a text symmetrically encrypted with gpg, not taking into 
account additional layers of asymmetric encryption?Thank you for your help.
  From: Peter Lebbing 
 To: Maricel Gregoraschko ; Gnupg-users 
 
 Sent: Wednesday, March 11, 2015 3:06 PM
 Subject: Re: AES-NI, symmetric key generation
   
On 11/03/15 18:55, Maricel Gregoraschko wrote:


> One more question: Is there any standardization in output formats 
> between encryption programs and libraries, for example say you
> encrypt with AES128 in CBC, with the same key (directly or via
> passphrase), and since the output will have to have, in addition to
> the actual ciphertext, algorithm indentification on it, possible
> pasphrase-to-key, plus mode-specific data such as the iv/nonce, is
> there a specification of the format of how these come in?

The passphrase-based encryption of GnuPG is entirely specified in RFC
4880, and there is no reason to worry that future versions of GnuPG
cannot read a symmetrically encrypted file created now.

Also, it is *not* the case that the key used to encrypt the data is the
key derived from your password!

The key to encrypt the data, the session key, is randomly generated. The
passphrase is used to derive a key, and this derived key is used to
encrypt the session key, and only the session key!

However, I do notice that RFC 4880 allows the use of a password-derived
key to encrypt the data[1]. I don't think GnuPG will generate such
OpenPGP messages, but it might accept and decrypt them.

HTH,

Peter.

[1] RFC 4880 section 5.3:

> If the encrypted session key is not present (which can be detected on
> the basis of packet length and S2K specifier size), then the S2K 
> algorithm applied to the passphrase produces the session key for 
> decrypting the file, using the symmetric cipher algorithm from the 
> Symmetric-Key Encrypted Session Key packet.

-- 
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: AES-NI, symmetric key generation

[Pete Stephenson]

On 3/11/2015 6:55 PM, Maricel Gregoraschko wrote:
> Thank you Pete for clearing things up. Makes a lot of sense to store
> passphrase-to-key identification data, in addition to actual algorithm
> used, in the output message rather than have the decryptor just assume
> things.

Indeed. The folks who created the OpenPGP standard were quite
forward-thinking in regards to such things.

> I figured out how to use --show-session-key: in my tests it doesn't show
> the key when encrypting, only when decrypting, that's good enough, I'm
> ok with doing a test decryption just to show the key.

Ah, that was my mistake: I forgot to specify that --show-session-key
only works when decrypting a message. Considering the intended purpose
of that option (being compelled to turn over a key), I suppose that's a
reasonable limitation in when it can be used.

> One more question: Is there any standardization in output formats
> between encryption programs and libraries, for example say you encrypt
> with AES128 in CBC, with the same key (directly or via passphrase), and
> since the output will have to have, in addition to the actual
> ciphertext, algorithm indentification on it, possible pasphrase-to-key,
> plus mode-specific data such as the iv/nonce, is there a specification
> of the format of how these come in?

You'd have to ask Werner, the head developer, about that.

RFC 4880 completely specifies how the algorithms are implemented. In
theory, it should be possible to split a message into it's various
packets (gpgsplit is designed to do this), then decrypt the
symmetrically-encrypted packet using the method specified in the RFC,
but I have not attempted to do this.

Cheers!
-Pete

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

Re: AES-NI, symmetric key generation

[Peter Lebbing]

On 11/03/15 18:55, Maricel Gregoraschko wrote:
> One more question: Is there any standardization in output formats 
> between encryption programs and libraries, for example say you
> encrypt with AES128 in CBC, with the same key (directly or via
> passphrase), and since the output will have to have, in addition to
> the actual ciphertext, algorithm indentification on it, possible
> pasphrase-to-key, plus mode-specific data such as the iv/nonce, is
> there a specification of the format of how these come in?

The passphrase-based encryption of GnuPG is entirely specified in RFC
4880, and there is no reason to worry that future versions of GnuPG
cannot read a symmetrically encrypted file created now.

Also, it is *not* the case that the key used to encrypt the data is the
key derived from your password!

The key to encrypt the data, the session key, is randomly generated. The
passphrase is used to derive a key, and this derived key is used to
encrypt the session key, and only the session key!

However, I do notice that RFC 4880 allows the use of a password-derived
key to encrypt the data[1]. I don't think GnuPG will generate such
OpenPGP messages, but it might accept and decrypt them.

HTH,

Peter.

[1] RFC 4880 section 5.3:

> If the encrypted session key is not present (which can be detected on
> the basis of packet length and S2K specifier size), then the S2K 
> algorithm applied to the passphrase produces the session key for 
> decrypting the file, using the symmetric cipher algorithm from the 
> Symmetric-Key Encrypted Session Key packet.

-- 
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: AES-NI, symmetric key generation

[Maricel Gregoraschko]

Thank you Pete for clearing things up. Makes a lot of sense to store 
passphrase-to-key identification data, in addition to actual algorithm used, in 
the output message rather than have the decryptor just assume things.
I figured out how to use --show-session-key: in my tests it doesn't show the 
key when encrypting, only when decrypting, that's good enough, I'm ok with 
doing a test decryption just to show the key.
One more question: Is there any standardization in output formats between 
encryption programs and libraries, for example say you encrypt with AES128 in 
CBC, with the same key (directly or via passphrase), and since the output will 
have to have, in addition to the actual ciphertext, algorithm indentification 
on it, possible pasphrase-to-key, plus mode-specific data such as the iv/nonce, 
is there a specification of the format of how these come in?Thanks!


  From: Pete Stephenson 
 To: Maricel Gregoraschko ; 
gnupg-users@gnupg.org 
 Sent: Tuesday, March 10, 2015 5:32 PM
 Subject: Re: AES-NI, symmetric key generation
   
On 3/10/2015 8:28 PM, Maricel Gregoraschko wrote:
> Pete,
> Very useful info about using --show-session-key to avoid revealing your
> private asymmetric key.

No worries.

> In your example ("gpg --show-session-key < example.txt") , had you
> somehow set up gpg to use symmetric by default, rather than asymmetric +
> symmetric?

No. It was a nearly "out of the box" setup with only some minor changes
to my gpg.conf file in regards to accessing keyservers. Nothing that
would affect the modes of encryption.

> If I explicitly pass --symmetric, --show-session-key does nothing
> (gpg4win) (and I guess the key is not really a random "session" key as
> when sending a PGP message) but rather the key deterministically
> generated from the passphrase.

Works fine for me. Try copy-pasting the text into the command prompt
rather than reading from a file. Use Ctrl-Z then Enter to tell GnuPG
you're done entering a message and it should start processing things.

Here's an encrypted message I generated with "gpg --symmetric --armor"
on GPG4Win 2.2.3:

-BEGIN PGP MESSAGE-
Version: GnuPG v2

jA0EAwMC2lG4z3grm9G1ySTYXvITlKTun7NvaLnznJZI4AhGJyTk+rFkAdufNRzB
cC6eqAI=
=j73k
-END PGP MESSAGE-

(password is "test" with no quotes)

gpg --show-session-key yields a session key of
"3:C4A5BBCBB7C8F846FCA3A9BDDED0EB7F".

The same message encrypted a few seconds later with the same password
yields:

-BEGIN PGP MESSAGE-
Version: GnuPG v2

jA0EAwMCgnIlCp86aLq1ySQt2veDYta5U1uxPiust4siTyduBe7+CVhupax2HKeI
Zcm3Rx0=
=kZPs
-END PGP MESSAGE-

and a session key of "3:A81A96428D44DEAD3A6079CC22145B51

It appears that GnuPG uses the iterated-and-salted secret-to-key method
(see https://tools.ietf.org/html/rfc4880#section-3.7.1.3 ) to generate
the session key.

You're right: the key is derived from a passphrase and so is not truly
random, but the salt is random which helps a bit. Of course, the salt is
not encrypted, so the message protection depends only on the strength of
your passphrase.

> I agree, using key instead of passphrase doesn't enhance security
> (assuming an attacker knows that the key was derived from a passphrase
> and with what key derivation algorithm? I assume the randomness/entropy
> of the key itself is high enough regardless of the passphrase strength?). 

The attacker would be able determine quite a bit of information about
how the message was encrypted (as this same information would be needed
by a legitimate user to decrypt the message):

Here's an excerpt from the double-verbose (-vv) output from the second
encrypted message above (all this is available without entering the
passphrase):

:symkey enc packet: version 4, cipher 3, s2k 3, hash 2
        salt 8272250a9f3a68ba, count 2752512 (181)

The attacker would know the cipher being used (cipher 3 = CAST5), the
fact that the key is derived from a user-provided string (the fact that
s2k is used), which string-to-key algorithm is used (s2k 3 =
iterated-and-salted), the hash used (hash 2 = SHA-1), the salt, and the
number of times to iterate the S2K algorithm.

The attacker won't know the strength of your passphrase -- it could be
"cat" or a long string of random characters -- but it tells them that
the key was generated using user-provided input.

> The reason I was asking if it's a possibility to store the symmetric key
> to decrypt with later, was to protect against future changes in the key
> derivation algorithm, that would make gpg generate a different key for
> the same passphrase, useless to decrypt previously encrypted data.

GnuPG follows the OpenPGP standard (RFC 4880). The standard defines
certain key derivation algorithms and provides the ability to add new
ones if needed. Adding new key derivation algorithms in the future
should not have any affect on existing encrypted messages.

Since each message clearly identifies the algorithm used to encrypt it,
future versions of GnuPG should have no prob

Re: AES-NI, symmetric key generation

[Robert J. Hansen]

> Thanks Vedaal, yep that would be one mighty strong password!

It's also way overkill.  :)

"gpg --armor --gen-rand 1 16" will produce a (relatively) short
passphrase suitable for pretty much any imaginable usage.  128 shannons
of entropy's nothing to sneeze at.

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

Re: AES-NI, symmetric key generation

[Maricel Gregoraschko]

Thanks Vedaal, yep that would be one mighty strong password!
  From: "ved...@nym.hush.com" 
 To: Maricel Gregoraschko ; 
gnupg-users@gnupg.org 
 Sent: Tuesday, March 10, 2015 4:42 PM
 Subject: Re: AES-NI, symmetric key generation
   
On 3/10/2015 at 4:19 PM, "Maricel Gregoraschko"  
wrote:



>I agree, using key instead of passphrase doesn't enhance security 
>(assuming an attacker knows that the key was derived from a 
>passphrase and with what key derivation algorithm? I assume the 
>randomness/entropy of the key itself is high enough regardless of 
>the passphrase strength?). The reason I was asking if it's a 
>possibility to store the symmetric key to decrypt with later, was 
>to protect against future changes in the key derivation algorithm, 
>that would make gpg generate a different key for the same 
>passphrase, useless to decrypt previously encrypted data.Thank you 
>for your support.

-

If you don't want to keep your passsphrase, and want only to keep the session 
key,
and you want this to have no weakness because of a questionably strong enough 
password that was used to generate the key,
then there is an easy way to do what you want:

[1] Encrypt a test message to any of your own keys.

[2] Decrypt this test message, with the option of --show-session-key

[3] Use this session key as the 64 character password for your symmetric 
encryption, (and save it, or you won't be able to decrypt the symmetric 
message).

[4] Decrypt your symmetrically encrypted file or message, using the option of 
--show-session-key

[5] Save this session key, and if you wish, you can destroy the first one. (you 
can always get it back by decrypting your message of step [1] ).


The string-to-key part of generating the session key for the symmetrically 
encrypted message, will be using a random 64 character GnuPG generated session 
key as it's password.

You can't find a better password (especially even one that you don't have to 
remember ;-)  )


vedaal



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

Re: [cygwin] gpg-agent with ssh support ?

[Doug Barton]

On 3/11/15 3:15 AM, Werner Koch wrote:

The standard ssh client on Windows seems to be Putty; you may use it
with the native GnuPG for Windows (i.e. Gpg4win) by using the option
--enable-putty-support instead of --enable-ssh-support.


PuTTY also has its own agent support, which works quite well. I'm not 
sure why it's necessary to reinvent the wheel here. :)


Doug


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

Enigmail speed geeking

[Robert J. Hansen]

At the Circumvention Tech Festival there was an event called
speed-geeking, where the people responsible for a tool would speak for a
few minutes on something related to the tool and field a few minutes of
Q&A from the audience about the tool.  I received a number of requests
afterwards to reprise my Enigmail speed-geeking presentation, so I wrote
it up and put it online.

"Things you're doing wrong with Enigmail" is a short (500-word) essay on
four mistakes I repeatedly see Enigmail users making.  However, it's not
limited to Enigmail: most of the content is broadly applicable to any
cryptosystem.

http://robert-hansen.com/?p=83



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

Re: bugs.gnupg.org TLS certificate

[Werner Koch]

On Wed, 11 Mar 2015 15:12, br...@minton.name said:

> git.gnupg.org) don't use that certificate.  Have you considered a wildcard
> certificate?  I know this has been discussed before, e.g. at

Too expensive ;-).  To stop all these complaints I will add a so called
real certificate but first I need to move the tracker to another
machine.


Shalom-Salam,

   Werner

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


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

bugs.gnupg.org TLS certificate

[Brian Minton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I wanted to report a bug of gnupg, but my browser complained about the
certificate (self-signed, and for kerckhoffs.g10code.com) rather than
bugs.gnupg.org.  I noticed that https://gnupg.org has a trusted certificate
from Gandi Standard SSL CA, but bugs.gnupg.org (and other sites such as
git.gnupg.org) don't use that certificate.  Have you considered a wildcard
certificate?  I know this has been discussed before, e.g. at
https://lists.gnupg.org/pipermail/gnupg-users/2013-December/048415.html

thanks,
- --
Brian Minton
br...@minton.name
http://brian.minton.name
Live long, and prosper longer!
OpenPGP fingerprint = 8213 71DD 4665 CF4F AE20  2206 0424 DC19 B678 A1A9
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAlT95+kACgkQa46zoGXPuql5WQD/ekTmNWoSkZmaBN4R24Y59cHt
rOYzvL0k0kWWOKTt0dwA/1T+07f4PT8zH5QQJdQxcK8HvoxZeJHbwH1uJqIrzKv1
=9aIo
-END PGP SIGNATURE-

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

Re: [cygwin] gpg-agent with ssh support ?

[Brian Minton]

I would like to second the request for this feature.

On Wed, Mar 11, 2015, 6:23 AM Werner Koch  wrote:

> On Wed, 11 Mar 2015 07:18, xav...@maillard.im said:
>
> > I enabled ssh support in the gpg-agent.conf file as usual and I
> > clearly see the socket files for both GNUpg and SSH.
>
> The Unix Domain Socket emulation used by Cygwin is different from the
> emulation used by GnuPG on Windows.  Recall that Cygwin is its own OS on
> top of Windows.  You may try to build GnuPG for Cygwin and install this.
> However, I would not suggest this.
>
> The standard ssh client on Windows seems to be Putty; you may use it
> with the native GnuPG for Windows (i.e. Gpg4win) by using the option
> --enable-putty-support instead of --enable-ssh-support.
>
> > Do you know a way to fix that and only use gpg-agent as my sole agent
> > entry point for both gpg and ssh ?
>
> IIRC, gniibe once posted a description on how Cygwin's socket emulation
> works on Windows.  It might be possible to add this to gpg-agent.
>
>
> Salam-Shalom,
>
>Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [cygwin] gpg-agent with ssh support ?

[Werner Koch]

On Wed, 11 Mar 2015 07:18, xav...@maillard.im said:

> I enabled ssh support in the gpg-agent.conf file as usual and I
> clearly see the socket files for both GNUpg and SSH.

The Unix Domain Socket emulation used by Cygwin is different from the
emulation used by GnuPG on Windows.  Recall that Cygwin is its own OS on
top of Windows.  You may try to build GnuPG for Cygwin and install this.
However, I would not suggest this.

The standard ssh client on Windows seems to be Putty; you may use it
with the native GnuPG for Windows (i.e. Gpg4win) by using the option
--enable-putty-support instead of --enable-ssh-support.

> Do you know a way to fix that and only use gpg-agent as my sole agent
> entry point for both gpg and ssh ?

IIRC, gniibe once posted a description on how Cygwin's socket emulation
works on Windows.  It might be possible to add this to gpg-agent.


Salam-Shalom,

   Werner

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


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