Re: Trezor - Could this be the model for a PGP crypto device?

2015-03-10 Thread Jonathan Schleifer
On Tue, 10 Mar 2015 13:35:27 +0900, NIIBE Yutaka gni...@fsij.org wrote:

 Confirmation push button would be a good idea, and I have been
 considering how we can enhance the OpenPGPcard specification so that
 we could do something like that for future implementation(s).

Does this really need to be part of the specification? For example, the Gnuk 
could just delay signing / decryption / authentication until the button has 
been pressed and return an error if it doesn't get pressed within a certain 
amount of time.

-- 
Jonathan


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


Re: GPG4Win 2.2.3 Smart card support

2015-03-10 Thread Werner Koch
On Tue, 10 Mar 2015 08:14, deepak.sax...@safenet-inc.com said:

 I am trying to test file encryption with SafeNet smart cards. (CardOs/ Java 
 and other tokens).
 I am getting error message: The card application is not yet supported.

You need to write an application which GnuPG knows about.  The source
files scd/app-*.c implement the hist part of the card applictions.  If
you card has a pkcs#15 structure it would be used, if not you need to
provide the specifications for the card and write such an application
driver or find someone who is interested in doing that.

You may however use the card directly sending the respecive APDUs to the
card.  You can test this with gpg-connect-agent; use 

  scd serialno undefined

to convince scdaemon to use the card without any known application and
then run

 scd help apdu

to learn about the APDU command.

 I can see the list of supported tokens as:
 https://wiki.debian.org/GnuPG/CCID_Driver

This is a lower layer.  On Windows pkcs@11 is used and AFAICS it works
for you.


Salam-Shalom,

   Werner


p.s.
 The information contained in this electronic mail transmission 
 may be privileged and confidential, and therefore, protected 
 from disclosure. If you have received this communication in 
 error, please notify us immediately by replying to this 

Did the GCHQ complied with that request when they grabbed all those SIM
card keys? ;-)

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


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


Re: AES-NI, symmetric key generation

2015-03-10 Thread Andre Heinecke
Hi,

To answer your first question regarding gpg4win:

On Monday, March 09, 2015 05:15:14 PM Maricel Gregoraschko wrote:
 Hello All,I would first like to thank you for your effort and time
 developing gnupgp.I have a couple of questions: 1. Does GnuGP (in
 particular, the Windows binaries distributed for gpg4win) use AES-NI, the
 Intel dedicated AES instruction set?

No, it has been disabled due to a bug. I've opened gnupg/issue1919 to track 
this.

 There are some concerns, I'm not sure
 how realistic, about backdoors built into the CPU themselves. 

AES is an algorithm that produces deterministic results. Not really something 
to backdoor like a RNG. 

 I noticed
 there is an option to configure, --disable-aesni-support. Where can I get
 the full configure command as it was used to build the posted gpg4win
 binaries, to check if that switch was present or not?

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob;f=src/Makefile.am

Look for gpg4win_pkg_package_configure (e.g. gpg4win_pkg_libgcrypt_configure)

 Also is there any
 option to turn hardware acceleration on or off at runtime? 

No.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: gpg in a cybercafé

2015-03-10 Thread Jonathan Schleifer
On Thu, 05 Mar 2015 22:27:36 +, flapflap flapf...@riseup.net wrote:

 The current version (1.3) of Tails comes with GnuPG 1.4.12.

That's just not true. Not only is the gpg2 command available, but the change 
log even explicitly states that GnuPG 2 was added to improve smartcard support.

--
Jonathan


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


Re: Suggestions for a Practical Scheme to Manage Multiple Identities?

2015-03-10 Thread Ville Määttä
On 10.03.15 04:41, NIIBE Yutaka wrote:
 So this is not a question about portable flash drives vs. smartcards per
  se. I _think_ I understand those risks and trade-offs but if there is
  something I'm missing then, of course, I'd like to know.
 I had an experience that one of my family members took my portable
 flash drive for his/her own purpose (and it took hours/days for me to
 realize the fact).
 
 This might be another risk.

On top of all the other problems of a general purpose storage device.

I'd say just go with a smartcard or purpose built token device [1][2].

As for the multiple identities, different smartcards as needed. That
makes the reader the only device to carry and the cards you can cut
(some precut) to SIM-card size to make carrying easy. And there are
small readers available.

[1]: http://www.seeedstudio.com/wiki/index.php?title=FST-01
[2]: http://www.fsij.org/doc-gnuk/

-- 
Ville



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

2015-03-10 Thread Werner Koch
On Tue, 10 Mar 2015 10:05, aheine...@intevation.de said:

 Also is there any
 option to turn hardware acceleration on or off at runtime? 

You can globally disable certain hardware features: Create a file

--8---cut here---start-8---
# We do not want to use AES-NI
intel-aesni
--8---cut here---end---8---

and store it as /etc/gcrypt/hwf.deny . This should work also on Windows
if you copy that file to every drive.  The list of hardware
features in the current development version is:

{ HWF_PADLOCK_RNG, padlock-rng },
{ HWF_PADLOCK_AES, padlock-aes },
{ HWF_PADLOCK_SHA, padlock-sha },
{ HWF_PADLOCK_MMUL,padlock-mmul},
{ HWF_INTEL_CPU,   intel-cpu },
{ HWF_INTEL_BMI2,  intel-bmi2 },
{ HWF_INTEL_SSSE3, intel-ssse3 },
{ HWF_INTEL_PCLMUL,intel-pclmul },
{ HWF_INTEL_AESNI, intel-aesni },
{ HWF_INTEL_RDRAND,intel-rdrand },
{ HWF_INTEL_AVX,   intel-avx },
{ HWF_INTEL_AVX2,  intel-avx2 },
{ HWF_ARM_NEON,arm-neon }

Libgcrypt 1.6 has less features.

BTW, I just pushed a change for 2.1 to show the used Libgcrypt
configuration:

--8---cut here---start-8---
$ gpg --list-gcrypt-config
version:1.6.3-beta12:
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:
pubkeys:dsa:elgamal:rsa:ecc:
digests:crc:gostr3411-94:md4:md5:rmd160:sha1:sha256:sha512:tiger:whirlpool:stribog:
rnd-mod:linux:
cpu-arch:x86:
mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S:
threads:none:
hwflist:intel-cpu:intel-ssse3:intel-pclmul:intel-aesni:intel-avx:
fips-mode:n:n:
rng-type:standard:1:
--8---cut here---end---8---


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


Re: AES-NI, symmetric key generation

2015-03-10 Thread Pete Stephenson
On 3/9/2015 6:15 PM, Maricel Gregoraschko wrote:
 Hello All,

Hi!

 2.  When using symmetric encryption and providing a passphrase, I
 understand the actual encryption key is generated on the spot, used to
 do the encryption, and then discarded from memory and not stored
 anywhere, is that correct?

Correct.

 If the user wanted, can they dump the encryption key to store it
 securely, and use it to decrypt, instead of the password?

Yes, but the security is only as strong as the weakest link: if one uses
a weak passphrase to encrypt a message, an adversary could guess the
password.

If one used a long random string as a passphrase, this is functionally
equivalent to a strong key, so why bother with using the key itself to
decrypt instead of the passphrase?

You can show the symmetric session key for a message using the
--show-session-key option.

Here's an example of text I encrypted with gpg --symmetric:
-BEGIN PGP MESSAGE-
Version: GnuPG v1

jA0EAwMCYFod0NxVEONgySM6oLcax81PoXTPKk2R+zdP2XZ+rA1ILbKy3+sg0xs8
B8SW2A==
=Iz40
-END PGP MESSAGE-

The passphrase is test (no quotes).

pete@kaylee:~$ gpg --show-session-key  example.txt
[prompt for password]
gpg: CAST5 encrypted data
gpg: gpg-agent is not available in this session
gpg: encrypted with 1 passphrase
gpg: session key: `3:62A2421F805F6CB1767A9DF07983ADDF'
gpg: example.txt: unknown suffix

Later, I can use gpg with the --override-session-key option to supply
the decryption key directly. Use gpg --override-session-key [session
key], using the format given above:

pete@kaylee:~$ gpg --override-session-key
3:62A2421F805F6CB1767A9DF07983ADDF  example.txt
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
Hello world!
gpg: WARNING: message was not integrity protected

See the manpage or https://www.gnupg.org/documentation/manpage.html for
more details.

One interesting note about show/override-session-key: if one is
compelled to decrypt a message (or else...), one can use those options
on messages encrypted using GnuPG's symmetric or the more usual
asymmetric (i.e., public key) encryption methods. The manpage says,
This option is normally not used but comes handy in case someone forces
you to reveal the content of an encrypted message; using this option you
can do this without handing out the secret key.

In other words, if you're compelled to decrypt a message that was
encrypted to your public key, you don't need to hand over your private
key (which would allow someone to decrypt all your messages, sign new
messages, etc.). Instead, you would just hand over the encrypted message
and the session key used to encrypt it. Since each message uses a new,
random session key, only that single message can be decrypted and your
private key is not compromised.

Cheers!
-Pete


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


Re: AES-NI, symmetric key generation

2015-03-10 Thread Maricel Gregoraschko
Pete,Very useful info about using --show-session-key to avoid revealing your 
private asymmetric key.In your example (gpg --show-session-key  example.txt) 
, had you somehow set up gpg to use symmetric by default, rather than 
asymmetric + symmetric?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.
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.
  From: Pete Stephenson p...@heypete.com
 To: Maricel Gregoraschko maricelgregorasc...@yahoo.com 
Cc: gnupg-users@gnupg.org 
 Sent: Tuesday, March 10, 2015 10:36 AM
 Subject: Re: AES-NI, symmetric key generation
   
On 3/9/2015 6:15 PM, Maricel Gregoraschko wrote:
 Hello All,

Hi!

 2.  When using symmetric encryption and providing a passphrase, I
 understand the actual encryption key is generated on the spot, used to
 do the encryption, and then discarded from memory and not stored
 anywhere, is that correct?

Correct.

 If the user wanted, can they dump the encryption key to store it
 securely, and use it to decrypt, instead of the password?

Yes, but the security is only as strong as the weakest link: if one uses
a weak passphrase to encrypt a message, an adversary could guess the
password.

If one used a long random string as a passphrase, this is functionally
equivalent to a strong key, so why bother with using the key itself to
decrypt instead of the passphrase?

You can show the symmetric session key for a message using the
--show-session-key option.

Here's an example of text I encrypted with gpg --symmetric:
-BEGIN PGP MESSAGE-
Version: GnuPG v1

jA0EAwMCYFod0NxVEONgySM6oLcax81PoXTPKk2R+zdP2XZ+rA1ILbKy3+sg0xs8
B8SW2A==
=Iz40
-END PGP MESSAGE-

The passphrase is test (no quotes).

pete@kaylee:~$ gpg --show-session-key  example.txt
[prompt for password]
gpg: CAST5 encrypted data
gpg: gpg-agent is not available in this session
gpg: encrypted with 1 passphrase
gpg: session key: `3:62A2421F805F6CB1767A9DF07983ADDF'
gpg: example.txt: unknown suffix

Later, I can use gpg with the --override-session-key option to supply
the decryption key directly. Use gpg --override-session-key [session
key], using the format given above:

pete@kaylee:~$ gpg --override-session-key
3:62A2421F805F6CB1767A9DF07983ADDF  example.txt
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
Hello world!
gpg: WARNING: message was not integrity protected

See the manpage or https://www.gnupg.org/documentation/manpage.html for
more details.

One interesting note about show/override-session-key: if one is
compelled to decrypt a message (or else...), one can use those options
on messages encrypted using GnuPG's symmetric or the more usual
asymmetric (i.e., public key) encryption methods. The manpage says,
This option is normally not used but comes handy in case someone forces
you to reveal the content of an encrypted message; using this option you
can do this without handing out the secret key.

In other words, if you're compelled to decrypt a message that was
encrypted to your public key, you don't need to hand over your private
key (which would allow someone to decrypt all your messages, sign new
messages, etc.). Instead, you would just hand over the encrypted message
and the session key used to encrypt it. Since each message uses a new,
random session key, only that single message can be decrypted and your
private key is not compromised.

Cheers!
-Pete





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


Re: AES-NI, symmetric key generation

2015-03-10 Thread Maricel Gregoraschko
 AES is an algorithm that produces deterministic results. Not really something 
to backdoor like a RNG. 
I admit I haven't looked at the AES-NI instruction set, but I've read that it 
could be easy for the CPU to reconstruct the key from a sequence of calls 
typical to AES encryption/decryption (I think implementations even use 
Intel-provided code), and store it for later retrieval through a secret CPU 
instruction set.  From: Andre Heinecke aheine...@intevation.de
 To: gnupg-users@gnupg.org; Maricel Gregoraschko 
maricelgregorasc...@yahoo.com 
 Sent: Tuesday, March 10, 2015 5:05 AM
 Subject: Re: AES-NI, symmetric key generation
   
Hi,

To answer your first question regarding gpg4win:

On Monday, March 09, 2015 05:15:14 PM Maricel Gregoraschko wrote:
 Hello All,I would first like to thank you for your effort and time
 developing gnupgp.I have a couple of questions: 1. Does GnuGP (in
 particular, the Windows binaries distributed for gpg4win) use AES-NI, the
 Intel dedicated AES instruction set?

No, it has been disabled due to a bug. I've opened gnupg/issue1919 to track 
this.

 There are some concerns, I'm not sure
 how realistic, about backdoors built into the CPU themselves. 

AES is an algorithm that produces deterministic results. Not really something 
to backdoor like a RNG. 

 I noticed
 there is an option to configure, --disable-aesni-support. Where can I get
 the full configure command as it was used to build the posted gpg4win
 binaries, to check if that switch was present or not?

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob;f=src/Makefile.am

Look for gpg4win_pkg_package_configure (e.g. gpg4win_pkg_libgcrypt_configure)



 Also is there any
 option to turn hardware acceleration on or off at runtime? 

No.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

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


Re: AES-NI, symmetric key generation

2015-03-10 Thread vedaal
On 3/10/2015 at 4:19 PM, Maricel Gregoraschko maricelgregorasc...@yahoo.com 
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: AES-NI, symmetric key generation

2015-03-10 Thread Maricel Gregoraschko
Thanks Werner.On Windows, you mean on each drive letter, in the root directory? 
(e.g. c:\hwf.deny, d:\hwf.deny, etc.?).Also would there be a way to make gpg 
display which hardware features are being used when encrypting/decrypting (to 
confirm that the deny file was correctly placed and actually had an effect)? 
Thank you.
  From: Werner Koch w...@gnupg.org
 To: Andre Heinecke aheine...@intevation.de 
Cc: gnupg-users@gnupg.org; Maricel Gregoraschko maricelgregorasc...@yahoo.com 
 Sent: Tuesday, March 10, 2015 10:58 AM
 Subject: Re: AES-NI, symmetric key generation
   
On Tue, 10 Mar 2015 10:05, aheine...@intevation.de said:



 Also is there any
 option to turn hardware acceleration on or off at runtime? 

You can globally disable certain hardware features: Create a file

--8---cut here---start-8---
# We do not want to use AES-NI
intel-aesni
--8---cut here---end---8---

and store it as /etc/gcrypt/hwf.deny . This should work also on Windows
if you copy that file to every drive.  The list of hardware
features in the current development version is:

    { HWF_PADLOCK_RNG, padlock-rng },
    { HWF_PADLOCK_AES, padlock-aes },
    { HWF_PADLOCK_SHA, padlock-sha },
    { HWF_PADLOCK_MMUL,padlock-mmul},
    { HWF_INTEL_CPU,  intel-cpu },
    { HWF_INTEL_BMI2,  intel-bmi2 },
    { HWF_INTEL_SSSE3, intel-ssse3 },
    { HWF_INTEL_PCLMUL,intel-pclmul },
    { HWF_INTEL_AESNI, intel-aesni },
    { HWF_INTEL_RDRAND,intel-rdrand },
    { HWF_INTEL_AVX,  intel-avx },
    { HWF_INTEL_AVX2,  intel-avx2 },
    { HWF_ARM_NEON,    arm-neon }

Libgcrypt 1.6 has less features.

BTW, I just pushed a change for 2.1 to show the used Libgcrypt
configuration:

--8---cut here---start-8---
$ gpg --list-gcrypt-config
version:1.6.3-beta12:
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:
pubkeys:dsa:elgamal:rsa:ecc:
digests:crc:gostr3411-94:md4:md5:rmd160:sha1:sha256:sha512:tiger:whirlpool:stribog:
rnd-mod:linux:
cpu-arch:x86:
mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S:
threads:none:
hwflist:intel-cpu:intel-ssse3:intel-pclmul:intel-aesni:intel-avx:
fips-mode:n:n:
rng-type:standard:1:
--8---cut here---end---8---


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


Re: AES-NI, symmetric key generation

2015-03-10 Thread Werner Koch
On Tue, 10 Mar 2015 20:39, maricelgregorasc...@yahoo.com said:
 Thanks Werner.On Windows, you mean on each drive letter, in the root
 directory? (e.g. c:\hwf.deny, d:\hwf.deny, etc.?).Also would there be

Yes, that was the idea.  The file names should however be

  c:\etc\gcrypt\hwf.deny
  d:\etc\gcrypt\hwf.deny

I have not tested this.

 a way to make gpg display which hardware features are being used when
 encrypting/decrypting (to confirm that the deny file was correctly
 placed and actually had an effect)? Thank you.  From: Werner Koch

Not yet. 2.1.3 will have a command to list it.  You may simply encrypt a
large file and compare the times.  It is way faster with AES-NI enabled.


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


GnuPG News for February 2015

2015-03-10 Thread Werner Koch
Hi!

Find below the plain text version of 
https://gnupg.org/blog/20150310-gnupg-in-february.html


Shalom-Salam,

   Werner



1 GnuPG News for February 2015
══

  Indeed, very exiting news this month: The financial crisis of The
  GnuPG Project is over.  Due to an unexpected amount of donations
  received in the first days of February we can keep on working for at
  least the next 2 or 3 years.

  How did this happen?  At the [31C3] Nico Josattis arranged an
  Interview with [Julia Angwin] who writes for [ProPublica].  Eventually
  on the 5th her [article] was published and immediately received a lot
  of attention.  Not only at the ProPublica site but at many other news
  site as well.  While checking my mail on that evening, I noticed more
  than thousand notification mails for donations and even better: that
  continuous stream of donations did not stop for the next days.  Alone
  on the first day we received more than 120,000 € and thus more than
  our initial goal.  I even had to fix the script building the donation
  progress bar to not overflow the right margin the same night.  I also
  received a call from one of the Stripe founders who offered yearly
  donations from Stripe and Facebook each at 50, $.  Amazing.

  I like to *thank everyone* for supporting the project, be it small or
  large individual donations, helping users, providing corporate
  sponsorship, working on the software, and for all the encouraging
  words by mail, blogs, and even postcards.

  Due to that new publicity for GnuPG, I received many requests for
  interviews and for several days journalists and photographers visited
  me in my office.  They wrote several articles for German papers and
  radio stations, for example in the [taz], the [Süddeutsche Zeitung],
  and the [Deutsche Welle]. I hope these articles help to keep up the
  awareness for the importance of privacy issues.

  GnuPG does not stand alone: there are many other projects, often
  unknown to most people, which are essential to keep the free Internet
  running.  Many of them are run by volunteers who spend a lot of unpaid
  time on them.  They need our support as well!

  Now what to do with all that money?  Before a final plan can be
  drafted, tax issues need to be resolved.  Given that g10^code (the
  legal entity behind the project) is not a charity, we need to find a
  way to stretch the use of the money beyond this year.  My tax advisor
  is currently looking into this and I will report on the outcome in
  another blog entry.

  Regardless of this I started to look out for a second developer and
  fortunately [Neal Walfield] was searching for a job and accepted my
  offer to work on GnuPG.  Neal is well known for his work on modern
  operating systems and I consider him an excellent hacker.  I am glad
  to have him on board.


  [31C3] https://events.ccc.de/congress/2014/wiki/Main_Page

  [Julia Angwin] http://juliaangwin.com

  [ProPublica] http://www.propublica.org

  [article]
  
http://www.propublica.org/article/the-worlds-email-encryption-software-relies-on-one-guy-who-is-going-broke

  [taz] http://www.taz.de/Verschluesselung-mit-GnuPG/!154635/

  [Süddeutsche Zeitung]
  
http://www.sueddeutsche.de/digital/verschluesselungssoftware-gnu-pg-wie-ein-mann-das-e-mail-geheimnis-verteidigt-1.2355155

  [Deutsche Welle] http://dw.de/p/1Eebj

  [Neal Walfield] http://walfield.org


1.1 Release status
──

  GnuPG [2.1.2] was released on the 11th, [2.0.27] on the 18th, and
  [1.4.19] on the 27th.

  The 1.4.19 release features a fix for a new side channel attack on the
  Elgamal encryption (which used to be the default public key encryption
  algorithm until 2009).  Go ahead and read how Genkin’s group describes
  the [details] of this attack.  The release also includes a mitigation
  for another SCA to be described in the forthcoming paper /Last-Level
  Cache Side-Channel Attacks are Practical/ by Yarom et al.

  Libgcrypt [1.6.3] was released on the 27th to fix the described SCAs
  for GnuPG 2.0 and 2.1.


  [2.1.2]
  https://lists.gnupg.org/pipermail/gnupg-announce/2015q1/000361.html

  [2.0.27]
  http://lists.gnupg.org/pipermail/gnupg-announce/2015q1/000362.html

  [1.4.19]
  http://lists.gnupg.org/pipermail/gnupg-announce/2015q1/000363.html

  [details] http://www.cs.tau.ac.il/~tromer/radioexp/

  [1.6.3]
  http://lists.gnupg.org/pipermail/gnupg-announce/2015q1/000364.html


1.2 Released and not yet released changes
─

  Several segfaults due to NULL-derefs and invalid memory reads when
  using garbled keyrings were fixed.  These unlikely exploitable bugs
  were detected by fuzzing instrumented versions of GnuPG; [Hanno Böck's
  report] has some details.  A long standing implementation flaw copying
  memory stored values to integers variables was also found and fixed.
  These bug fixes have been backported to 2.0 and 1.4; Daniel Kahn
  Gillmor was kind enough

RE: GPG4Win 2.2.3 Smart card support

2015-03-10 Thread Saxena, Deepak
Hi Yutaka,

I am trying to test file encryption with SafeNet smart cards. (CardOs/ Java and 
other tokens).
I am getting error message: The card application is not yet supported.

I have dll libraries for my tokens but I am new to GPG4Win.
Can you please guide me the way to import the library or steps by how can I 
configure GPG4win to support these tokens/ smartcards.

I can see the list of supported tokens as:
https://wiki.debian.org/GnuPG/CCID_Driver

It it anyhow possible to support other tokens??


-Original Message-
From: NIIBE Yutaka [mailto:gni...@fsij.org] 
Sent: Tuesday, March 10, 2015 11:16 AM
To: Saxena, Deepak
Cc: gnupg-users@gnupg.org
Subject: Re: GPG4Win 2.2.3 Smart card support

Hello,

This is second time for me to receive the message like:

 The information contained in this electronic mail transmission may be 
 privileged and confidential, and therefore, protected from disclosure. 
 If you have received this communication in error, please notify us 
 immediately by replying to this message and deleting it from your 
 computer without copying or disclosing it.

I can't answer to a message saying like this.  Perhaps, so can't everyone (and 
that would be the reason why you didn't get reply).

Thus, this is not the reply, but a monologue of mine.

In January, I wrote a message to this list:

https://lists.gnupg.org/pipermail/gnupg-users/2015-January/052298.html

It may help somehow, but it should be just a coincidence.
-- 
The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.



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


Re: AES-NI, symmetric key generation

2015-03-10 Thread Pete Stephenson
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 problem decrypting it. Indeed,
the current version of GnuPG is able to decrypt messages generated from
old (even ancient!) versions of PGP and GnuPG with few, if any, issues.

Cheers!
-Pete

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


Re: AES-NI, symmetric key generation

2015-03-10 Thread Werner Koch
On Tue, 10 Mar 2015 20:33, maricelgregorasc...@yahoo.com said:

 I admit I haven't looked at the AES-NI instruction set, but I've read
 that it could be easy for the CPU to reconstruct the key from a

Possible.  It is also easy to detect the instructions used for software
based AES keyscheduling and leak the key from that knowledge.  I'd pick
AES-NI for its better performace and SCA resistance.

RDRAND for random numbers is a different story.  No sane crypto tool
should soley rely on this instruction.


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