|
|
Log in / Subscribe / Register

GnuPG 2.1.0 "modern" released

[Posted November 6, 2014 by corbet]

From:  Werner Koch <wk-AT-gnupg.org>
To:  gnupg-announce-AT-gnupg.org, info-gnu-AT-gnu.org
Subject:  GnuPG 2.1.0 "modern" released
Date:  Thu, 06 Nov 2014 10:01:51 +0100
Message-ID:  <87ioisn1mo.fsf@vigenere.g10code.de>
Archive‑link:  Article

Hello!

The GnuPG Project is pleased to announce the availability of a
new release: Version 2.1.0.

The GNU Privacy Guard (GnuPG) is a complete and free implementation of
the OpenPGP standard as defined by RFC-4880 and better known as PGP.

GnuPG, also known as GPG, allows to encrypt and sign data and
communication, features a versatile key management system as well as
access modules for public key directories.  GnuPG itself is a command
line tool with features for easy integration with other applications.
A wealth of frontend applications and libraries making use of GnuPG
are available.  Since version 2 GnuPG provides support for S/MIME and
Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom). It can
be freely used, modified and distributed under the terms of the GNU
General Public License.

Three different versions of GnuPG are actively maintained:

- GnuPG "modern" (2.1) is the latest development with a lot of new
  features.  This announcement is about the first release of this
  version.

- GnuPG "stable" (2.0) is the current stable version for general use.
  This is what most users are currently using.

- GnuPG "classic" (1.4) is the old standalone version which is most
  suitable for older or embedded platforms.

You may not install "modern" (2.1) and "stable" (2.0) at the same
time.  However, it is possible to install "classic" (1.4) along with
any of the other versions.


What's New in GnuPG-2.1
=======================

  - The file "secring.gpg" is not anymore used to store the secret
    keys.  Merging of secret keys is now supported.

  - All support for PGP-2 keys has been removed for security reasons.

  - The standard key generation interface is now much leaner.  This
    will help a new user to quickly generate a suitable key.

  - Support for Elliptic Curve Cryptography (ECC) is now available.

  - Commands to create and sign keys from the command line without any
    extra prompts are now available.

  - The Pinentry may now show the new passphrase entry and the
    passphrase confirmation entry in one dialog.

  - There is no more need to manually start the gpg-agent.  It is now
    started by any part of GnuPG as needed.

  - Problems with importing keys with the same long key id have been
    addressed.

  - The Dirmngr is now part of GnuPG proper and also takes care of
    accessing keyserver.

  - Keyserver pools are now handled in a smarter way.

  - A new format for locally storing the public keys is now used.
    This considerable speeds up operations on large keyrings.

  - Revocation certificates are now created by default.

  - Card support has been updated, new readers and token types are
    supported.

  - The format of the key listing has been changed to better identify
    the properties of a key.

  - The gpg-agent may now be used on Windows as a Pageant replacement
    for Putty in the same way it is used for years on Unix as
    ssh-agent replacement.

  - Creation of X.509 certificates has been improved.  It is now also
    possible to export them directly in PKCS#8 and PEM format for use
    on TLS servers.

A detailed description of the changes can be found at
https://gnupg.org/faq/whats-new-in-2.1.html .


Getting the Software
====================

Please follow the instructions found at https://gnupg.org/download/ or
read on:

GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found
at https://gnupg.org/mirrors.html .  Note that GnuPG is not available
at ftp.gnu.org.

On ftp.gnupg.org you find these files:

 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2  (3039k)
 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig

This is the GnuPG 2.1 source code compressed using BZIP2 and its
OpenPGP signature.

 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_2014110...  (6225k)
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_2014110...

This is an experimental installer for Windows including GPA as
graphical key manager and GpgEX as an Explorer extension.  Please
de-install an already installed Gpg4win version before trying this
installer.  This binary version has not been tested very well, thus it
is likely that you will run into problems.  The complete source code
for the software included in this installer is in the same directory;
use the suffix ".tar.xz" instead of ".exe".

Although several beta versions have been released over the course of
the last years, no extensive public field test has been done.  Thus it
is likely that bugs will show up.  Please check the mailing list
archives and the new wiki https://wiki.gnupg.org for latest
information on known problems and workaround.


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.1.0.tar.bz2 you would use this command:

     gpg --verify gnupg-2.1.0.tar.bz2.sig

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See below for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.1.0.tar.bz2, you would run the command like this:

     sha1sum gnupg-2.1.0.tar.bz2

   and check that the output matches the first line from the
   following list:

2fcd0ca6889ef6cb59e3275e8411f8b7778c2f33  gnupg-2.1.0.tar.bz2
9907cb6509a0e63331b27a92e25c1ef956caaf3b  gnupg-w32-2.1.0_20141105.exe
28dc1365292c61fbb2bbae730d4158f425463c91  gnupg-w32-2.1.0_20141105.tar.xz


Release Signing Keys
====================

To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these four keys:

  2048R/4F25E3B6 2011-01-12
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048/E0856959 2014-10-29
  Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
  David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>

  rsa2048/33BD3F06 2014-10-29
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

  rsa2048/7EFD60D9 2014-10-19
  Key fingerprint = D238 EA65 D64C 67ED 4C30  73F2 8A86 1B1C 7EFD 60D9
  Werner Koch (Release Signing Key)

You may retrieve these files from the keyservers using this command

  gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \
                  2071B08A33BD3F06 8A861B1C7EFD60D9

The keys are also available at https://gnupg.org/signature_key.html
and in the released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed using my standard PGP key.


Internationalization
====================

This new branch of GnuPG has support for 4 languages: French, German,
Japanese, and Ukrainian.  More translations can be expected with the
next point releases.


Documentation
=============

If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at

  https://gnupg.org/faq/whats-new-in-2.1.html

The file gnupg.info has the complete user manual of the system.
Separate man pages are included as well but they have not all the
details available in the manual.  It is also possible to read the
complete manual online in HTML format at

  https://gnupg.org/documentation/manuals/gnupg/

or in Portable Document Format at

  https://gnupg.org/documentation/manuals/gnupg.pdf .

The chapters on gpg-agent, gpg and gpgsm include information on how
to set up the whole thing.  You may also want search the GnuPG mailing
list archives or ask on the gnupg-users mailing lists for advise on
how to solve problems.  Many of the new features are around for
several years and thus enough public knowledge is already available.


Support
=======

Please consult the archive of the gnupg-users mailing list before
reporting a bug <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  For commercial support
requests we keep a list of known service companies at:

  https://gnupg.org/service.html

The driving force behind the development of GnuPG is the company of
its principal author, Werner Koch.  Maintenance and improvement of
GnuPG and related software takes up most of their resources.  To allow
him to continue this work he kindly asks to either purchase a support
contract, engage g10 Code for custom enhancements, or to donate money:

  https://gnupg.org/donate/


Thanks
======

We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.  A final big Thank You goes to Hal Finney, who too early passed
away this year.  Hal worked on PGP and helped to make OpenPGP a great
standard; it has been a pleasure having worked with him.


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

to post comments

GnuPG 2.1.0 and Mailpile

Posted Nov 6, 2014 19:01 UTC (Thu) by jondo (guest, #69852) [Link] (2 responses)

Great! It seems that some of the changes are directly connected to the topics of the Mailpile blog post Some thoughts on working with GnuPG.

GnuPG 2.1.0 and Mailpile

Posted Nov 6, 2014 20:06 UTC (Thu) by sjj (guest, #2020) [Link]

Thanks for the link, I didn't really know just how small the GPG "team" is... It's really amazing how small the pool of developers is with a lot of our critical infrastructure code. Unsung heroes, tragedy of the commons.

Heh, looks like "Heinrich Heine (Der Dichter)" has been replaced by "Glenn Greenwald <glenn@example.org>".

GnuPG 2.1.0 and Mailpile

Posted Nov 11, 2014 14:11 UTC (Tue) by ber (subscriber, #2142) [Link]

If Smári's thoughts on GnuPG reveal something, it is that we need to spread more knowledge about how GnuPG works. In the post, the supported API of GnuPG, GPGME is miss-spelled and the current python libaries for interacting with it were not identified. http://wiki.gnupg.org/APIs shows that pyme has moved to a new location with 0.9 published on May 2014 and the alternative pygpgme's 0.3 is from 2012. There is example code which is nice to work with.

Of course the command line interface is not the best stable interface to program GnuPG, it is because it is used as an interface to humans using the command line. GPGME is much better, of course it can be improved further.

Yes, Werner and his company g10code need your support, see http://g10code.com/index.html#sec-1-1 . (Full disclosure: My company Intevation is a business partner of g10code.)

GnuPG 2.1.0 "modern" released

Posted Nov 7, 2014 11:44 UTC (Fri) by epa (subscriber, #39769) [Link] (34 responses)

Did I read that right? All support for PGP 2.x keys has been removed? I could understand no longer encrypting with them but there is still a need to verify signatures on archived messages, for example.

GnuPG 2.1.0 "modern" released

Posted Nov 7, 2014 17:24 UTC (Fri) by raven667 (subscriber, #5198) [Link]

My guess is that you should just use gpg 1.4 which is parallel installable by design, that way each era of the tool isn't crudded up with legacy support, each has a consistent design matched to the data it works with.

GnuPG 2.1.0 "modern" released

Posted Nov 7, 2014 19:57 UTC (Fri) by dkg (subscriber, #55359) [Link] (32 responses)

PGP 2.x keys (more precisely, OpenPGPv3 keys) are not things you should be relying on these days.

The OpenPGPv3 fingerprint specification is trivially spoofable, and almost all OpenPGPv3 keys are significantly smaller and weaker (typically 1024-bit RSA) than modern keys (2048-bit RSA is the minimum you should consider), and they tend to use MD5 as a signature digest (a bad idea because MD5 is no longer collision-resistant).

Verifying legacy signatures in historical archives (or decrypting historical messages) is a job for historical tools, not something that we want to encourage modern software that people might use in contemporary situations to do. There are enough logistical problems with including this sort of fallback mode to make it a worthy decision to streamline a security-focused tool by removing features that were explicitly deprecated 16 years ago:

V3 keys SHOULD only be used for backward compatibility because of three weaknesses in them[...]

GnuPG 2.1.0 "modern" released

Posted Nov 9, 2014 21:41 UTC (Sun) by epa (subscriber, #39769) [Link] (31 responses)

The linked reasons for why not to use v3 keys are not terribly convincing. Or rather, they are fine as reasons not to sign and encrypt new documents with such keys, or generate new keys in this format; they are poor reasons to justify why existing data using such keys should no longer be supported. Key ids and key signatures do not matter much - fine, drop support for importing old keys by id if that can be spoofed, but the case that matters is when you already have the full key and want to use it. Only the weakness of MD5 is a convincing reason, but still it applies much more to why you should not use MD5 from now onwards, much less as an argument that existing MD5 signatures are somehow breakable in practice (they are not).

But really the question is one of principle. We know that over time ciphers and hashes will become less secure, so what is used today will be deprecated in the future. So if you encrypt a document today, will it still be decryptable in the future? If the package manager in your distribution pushes out a new version of GPG (and that will happen, unless those packaging it are alert enough to spot the backwards incompatibility and split it off as a separate package name) then existing files can no longer be decrypted or verified. It is as if gzip stopped reading old format .gz files. OK for a major version upgrade, perhaps, but not something to happen regularly, even if there are very good reasons not to compress anything more in that format.

Now the GPG developers have a solution: maintaining a historical release (1.4) which supports the old key formats. That works, as long as some wrapper can be written to invoke the correct GPG version, and this wrapper is updated in tandem with GPG itself.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 7:50 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link] (30 responses)

MD5 is an cornerstone of the v3 packets format (PGP-2) and that is a major problem. MD5 is broken and thus all v3 keys should be considered broken. If there is still data encrypted to an PGP-2 key it should be re-encrypted in the the process of the regular migration to a new medium. If you don't do that you will have to maintain a copy of GPG or PGP-2 in your box with the spare 5.25 floppy drives.

If it comes to reading old mail - re-encrypt it. If that is such important to many people, i wonder why no easy mail re-encrypt tool exists? In fact you don't even need to re-encrypt it, it is sufficient to add another encryption key.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 8:09 UTC (Thu) by dlang (guest, #313) [Link] (29 responses)

so how would mail from me to you sitting in your inbox get re-encrypted?

you don't have access to my key, and I don't have access to your inbox.

or are you saying that anything that was signed by an old key should be considered unsigned at this point?

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 9:00 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link] (28 responses)

You encrypted to my old public key and thus I can I can decrypt it with my old secret key and encrypt it again to my current public key.

Right, signed mails should be considered unsigned. We can't claim that SHA-1 is broken (which it is currently not) to an extend that Mozilla will soon reject TLS connections made with SHA-1 and at the same time keep on using and trusting MD5 which is known to be weak for 20 years, has easy to create collisions for 8 years, and pre-image attacks are known for 3 or 4 years.

(and yes, I can't understand why ssh still defaults to MD5 fingerprints)

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 10:01 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (1 responses)

The known pre-image attack for MD5 is only marginally better than brute force. It's a theoretical rather than practical attack, nobody has or could obtain the resources to even try it once as a proof of concept, let alone weaponise it.

I agree that we should migrate off MD5, and SHA-1 too, but migrating off something is not quite the same as it being broken. People have been saying MD5 will "soon" be broken for about a decade now and it's still standing. When the tornado warning siren sounds, you should seek shelter, but it would be a mistake to therefore conclude that each time the siren sounds a tornado hits.

If you have a message sent to you in 1996 with an MD5 MAC, you can in many ways be even _more_ confident in 2014 that it's genuine than you could when you received it in 1996. Because if somebody broke MD5 _before_ 1996 they have so far kept it secret for 18 years, which is quite remarkable and thus very unlikely.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 11:23 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link]

Okay. A MAC is very different from a plain hash and even HMAC-MD5 is still believed to be safe. OpenPGP does not use a MAC, though.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 10:06 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

but even the pre-image attacks don't result in a document that looks like a reasonable e-mail, or other human readable document (even a computer interpreted binary needs a bunch of 'junk' thrown in to create a match)

So while it doesn't result in a mathematically 'guaranteed[*]' signature, something signed by an old key that looks reasonable still has a very high probability of being what was initially signed.

As for encryption, how does being able to generate a new document that has the same hash as the old one make it possible to see what was in the old document?

I agree with the earlier poster, it's worth preventing these old keys from being used to sign/encrypt new stuff, but it doesn't make sense to prevent them from being used to access existing data (or validate the signature of the old data)

As I said before, it's just not possible to re-sign every document that was created, and even for encryption, if the encrypted version of the document is in the hands of the bad guy, re-encrypting your copy of it will achieve absolutely nothing in terms of preventing the bad guy from decrypting it.

So no, those documents should not be thrown away and their signatures treated as being worthless.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 11:20 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link]

Okay, okay,

what we see here is the usual problem of practical cryptography: We have to find some middle ground between those who use the software for every days purpose and the more paranoid geeks, known crypto gurus, and policy requirements. That is not easy and with my pragmatic user hat on I agree to your concerns. OTOH, I have to defend the use of such "insecure" practise from the complains of the latter group. See for example https://bugs.debian.org/739424 .

Instead of trying to fix flaws related to the use of PGP-2 keys, 2.1.0 simply kicks out all support and I feel now much safer not to keep on maintaining all these little workarounds for PGP-2.

To say it with Rick: We always have 1.4.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 16:55 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

> but even the pre-image attacks don't result in a document that looks like a reasonable e-mail, or other human readable document (even a computer interpreted binary needs a bunch of 'junk' thrown in to create a match)

While you would probably notice in an email it is demonstrated that you can create JPEGs with the same MD5 and it's not even hard anymore.

http://natmchugh.blogspot.co.uk/2014/10/how-i-created-two...

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 19:54 UTC (Thu) by dlang (guest, #313) [Link]

so that means that when you can throw in a huge amount of essentially random data without the user noticing, then signatures involving md5 are not that useful

But if you limit the problem space to something that is human readable and makes sense (in a human or programming language without large blobs), then it becomes a MUCH harder problem.

And if you are trying to alter what someone said to make it seem like they actually said something else (as opposed to just vandalizing something, for which deleting the data is just as effective, and not protected by any encryption/signing), then you are even more contrained.

If you have signatures on code, then before any weakness in the hash is significant you need to be able to replace it with new code that will compile, and doesn't scream "something wrong" when a human looks at it.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 16:01 UTC (Thu) by epa (subscriber, #39769) [Link] (21 responses)

I think you are failing to draw a distinction between "algorithm X has known weaknesses which may, at some future date, lead to a possible way to forge signatures or break encryption" - which is currently true of MD5 - and "algorithm X is so weak it is broken today, and here is some proof of concept code which forges a signature or cracks an encrypted message".

We all agree that MD5 is less than ideal because there have been some successful research efforts to find weaknesses in it. We all agree that at some point in the future it is likely that further flaws will be found, and/or advances in CPU power will make a brute force attack possible using the existing known weaknesses.

What doesn't make sense is to deduce from that that existing MD5 signatures (or keys which use MD5, etc) are so broken they are not worth supporting for existing documents. Existing signed and encrypted messages exist in many people's inboxes. For better or worse electronic mail and saved mailboxes are used as a permanent archive and record of what people said. Some of those messages will be from people who are no longer alive, or who for whatever other reason refuse to re-sign older messages with whatever is today's recommended system.

If you feel that "signed mails should be considered unsigned" then I invite you to take a message signed with an older key and produce a forgery with the same signature. (No, not a block of random data but an even remotely plausible forged message.)

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 16:26 UTC (Thu) by dkg (subscriber, #55359) [Link] (20 responses)

I'm sorry, but "at some future date" hasn't been true for MD5 for years. MD5-based signatures were forged back in 2008.

epa wrote:

I invite you to take a message signed with an older key and produce a forgery with the same signature.

First: the issue isn't whether some arbitrary LWN commenter has the time, resources, and skills to mount such an attack (though i agree if they can, that's really bad for the digest). The problem is whether a dedicated adversary has the time, resources, and skills.

Secondly: i acknowledge that the sort of attacks mounted by the rogue CA project referenced above were attacks against MD5's collision-resistance, which shouldn't be possible to mount against an existing signature, because this form of attack needs the victim to continue making signatures in the present, against data that is under the attacker's control at some level. But the tool that verifies such a signature (GnuPG) has no way of knowing whether such a thing is happening. The only thing the tools sees is the signed data and the signature itself.

So if the tool is going to make any conclusive statement (like "this signature is valid and was made by the key in question over the data you see here"), it can't be sure. Cryptographic tools need to provide strong assurances, and GnuPG (or anything else at this point) simply can't provide those assurances over data that is signed with an MD5 digest any more, because the digest is not cryptographically reliable.

GnuPG has done the right thing by dropping this support.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 18:28 UTC (Thu) by epa (subscriber, #39769) [Link] (19 responses)

First: the issue isn't whether some arbitrary LWN commenter has the time, resources, and skills to mount such an attack (though i agree if they can, that's really bad for the digest). The problem is whether a dedicated adversary has the time, resources, and skills.
It really depends on your application. A dedicated adversary has the ability to tap my phone line, but that does not stop me personally from using telephone banking. Others will have more stringent requirements. There certainly is value in cryptography which is strong enough to stop any adversary short of a dedicated supercomputer-backed attack by Mossad or whatever your preferred fantasy scenario is. At that point, the weak link in the chain will not be the cryptography.

GPG doesn't know what the user's requirements are and isn't in a position to judge whether MD5 is strong enough. You suggest that if the tool cannot provide a strong assurance it should not support any checking. But there might be practical attacks against SHA256 being executed right now by NSA cryptographers, just that we don't know about them. It is not possible for GPG or any other program to provide any "assurance" about cryptographic strength now or in the future. Or, to reuse a catchphrase from elsewhere: mechanism, not policy. It is the user's policy decision which ciphers and hash functions to accept as secure enough, and GPG's job to check what it is asked to check. (Of course it would be a good idea to ship GPG with a default policy requiring strong ciphers and key lengths; nobody wants to go back to the bad old days when PGP's default configuration generated crappy keypairs. But in the end it is the user's choice to override that if wanted.)

On the other hand, if what you say is correct, and it should just drop support for hash functions which it can't provide any assurance for, then that would apply just as well to the historic branch of GPG. Support for the older keys should be removed from 1.4 also. Or if there is a reason for 1.4 to exist and a reason for it to continue supporting the older keys, perhaps that's because there is a legitimate need to keep using these older cryptographic mechanisms, for all that they may be breakable by some possible adversary?

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 21:58 UTC (Thu) by raven667 (subscriber, #5198) [Link] (18 responses)

I'm not sure I understand what you are advocating here.

> whatever your preferred fantasy scenario is

Just to point out that in a post Snowden world we know that wholesale surveillance, where everyone is subjected to attack by a dedicated well-resourced agencies, is the new normal and not a fantasy.

> isn't in a position to judge whether MD5 is strong enough

Sure we are, MD5 is known to be insufficient for any cryptographic purpose at this time, it is not best practice to use it anymore for anything new, new tools don't need to include it, only tools which may have to deal with legacy data and legacy formats. I linked elsewhere to an instance of someone creating two different JPEG images without visible artifacts that MD5 to the same value, it only cost $0.67 on Amazon with GPU compute.

> there might be practical attacks against SHA256 being executed right now by NSA cryptographers, just that we don't know about them

Sure, anything is possible, but it is not likely and we have no evidence, not even sketchy evidence, that this is the case. Assurance is about probabilities and is never black and white, yes and no, secure or insecure. Or to put it another way, security is a fantasy, technically you are always insecure and we can only argue about how much is acceptable risk.

> if there is a reason for 1.4 to exist and a reason for it to continue supporting the older keys, perhaps that's because there is a legitimate need to keep using these older cryptographic mechanisms

Having a separate supported tool for legacy data and not supporting it in the current tool is a valid migration strategy, and valid software development practice. What is the practical problem with having two different versions of the tool for different eras of cryptographic support?

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 22:20 UTC (Thu) by dlang (guest, #313) [Link] (10 responses)

requiring people to install a new package to keep accessing their existing data when they upgrade a package is not a nice way to do things.

Split it into a different binary if you want (if keeping things combined is too ugly), but the new binary should call the old one transparently to the user if it's needed.

And the package should include both by default.

This business of "don't delete version 1.4 when you install 2.1 because you will sometimes need one and sometimes need the other" is user hostile

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 3:52 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (9 responses)

Versions 1.4 and 2.x are, by design, able to be installed at the same time.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 8:40 UTC (Fri) by dlang (guest, #313) [Link] (8 responses)

This is still a suboptimal user experience, now the user has to figure this out, and if they just do an upgrade to the new version, they can no longer read their old data.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 10:00 UTC (Fri) by rodgerd (guest, #58896) [Link]

Which is more than a little irritating when one has data retention policies that can go into the decades.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 18:34 UTC (Fri) by dlang (guest, #313) [Link] (6 responses)

expanding on this a bit.

while the two versions can be installed at the same time, they can't both be called gpg, so now the distro (or user) has to pick a name for the old version, it's path, etc and remember it.

Then there is the issue of system automation. You have to change all scripts that could validate or decrypt anything to know about both versions and figure out which version to call.

This is anything but portable and standard from system to system.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 19:00 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link] (3 responses)

I just wonder whether automated checking of PGP-2 signatures does no somewhat contradict the original claim that it is not possible to decrypt or verify old data. We are talking about 15 year old data - you still need to check it by a script?

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 19:06 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

> We are talking about 15 year old data - you still need to check it by a script?

why not? why should you no longer be able to use automation tools just because the data is old?

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 19:23 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link]

Applying 15 year old patches to at least 15 year old software? If you are forced to use such old and thus buggy software, verification of the patches is not very helpful. But if you think different, there is 1.4.

Also recall that until 2 or 3 years, many people kept an installation of PGP-2 to be able to decrypt their old mail because it was legally not possible for gpg to do that (IDEA patent). Not very different to what GPG 2.1 ask you to do. With the only difference that GPG does this for security reasons.

For the minority of users with these specal needs we spend the time and trouble to keep 1.4 alive and hopefully secure.

GnuPG 2.1.0 "modern" released

Posted Nov 17, 2014 10:30 UTC (Mon) by epa (subscriber, #39769) [Link]

A "script"? No. You want to view these older messages in your email client. What, you don't have older archived mboxes going back decades?

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 21:25 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

IIRC (and I'm not 100% sure about this), but the command line interface isn't completely compatible between the two anyways, so having them both be available as 'gpg' wouldn't be suitable anyways.

GnuPG 2.1.0 "modern" released

Posted Nov 15, 2014 10:13 UTC (Sat) by dd9jn (✭ supporter ✭, #4459) [Link]

Right, the PGP-2 command line compatible options

-k[v][v][v][c] [user-id] [keyring]

have been removed from 2.x a long time ago but are still available in 1.4 despite that they are marked as as deprecated since 1999.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 23:15 UTC (Thu) by epa (subscriber, #39769) [Link] (6 responses)

Widespread NSA surveillance - yes. The NSA breaking into your mbox files on disk and somehow changing messages to ones with forged signatures because of some MD5 weakness - no. Whatever the reason to drop support for the older key format, it is not because breaking PGP signatures or encryption with them is even remotely feasible today. (25 years from now it might be different, which is why these older keys should be avoided for new encryption or signing.)

A working attack against PGP, for example to forge the signature on a message, would be a sensational result. That is a long way from generating two JPEG files of random pixels which have the same MD5 hash.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 0:31 UTC (Fri) by dkg (subscriber, #55359) [Link] (5 responses)

I'm not compelled at all by the argument for signature verification -- if you didn't notice whether a given signature on an e-mail was valid when you received it 15 years ago from your peer with a v3 key, it really isn't important that you find out today. And you can still read the signed message without verifications.

There are exceptions here, like people doing software archaeology, who might be interested in signatures of old tarballs (but don't have particular security requirements for their work). Archaeologists can use special tools.

So what about people who have encrypted data that really do need to be able to read their archives? Those folks are probably best off decrypting with specialized tools and re-encrypting.

Most people using GnuPG today do not have old v3 secret keys, and some of those who do have old v3 keys don't have any significant v3-encrypted data. So it's a very small group of users who have the need for v3 decryption, and those users are likely to be people with some level of crypto or software experience at this point.

So we need to weigh the options. We can give all users the rope to hang themselves with old, broken crypto, and ask our already-stretched-thin crypto developers to maintain extra code that they know is too weak to offer strong guarantees. Or we can ask the archaeologists with their legacy sigs and old-crypto-heads with legacy encrypted archives to use specialized tools for their specialized needs.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 8:42 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

if the signature only matters when it's received, why does it need to be cryptographicaly strong? you want to be able to validate the signature years later if it's something worth signing in the first place.

Also, having a standard practice to decrypt all your data and re-encrypt it means exposing data in it's decrypted state much more frequently than you need to. Not a good security recommendation.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 8:53 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

Yes, if you do find that the current encryption is too weak the cautious practice would be to encrypt it again - so it is now doubly encrypted and you don't need to churn through all the plaintext.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 18:30 UTC (Fri) by dlang (guest, #313) [Link]

that would be reasonable, except that they are dropping support for decrypting the inner layer of encryption, so it's not double encrypted, you need to decrypt it to plaintext and then encrypt it agains.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 8:56 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

What you call an archaeologist is anyone with signed or encrypted messages from twenty years ago (or often less). It is not at all unusual for correspondence to be kept that long - perhaps not all correspondence, but important messages, which are particularly those where cryptography is likely to be used.

GnuPG 2.1.0 "modern" released

Posted Nov 14, 2014 18:30 UTC (Fri) by dlang (guest, #313) [Link]

don't just think about correspondence, think about signed code dumps/patches

GnuPG 2.1.0 "modern" released

Posted Nov 7, 2014 19:46 UTC (Fri) by dkg (subscriber, #55359) [Link] (2 responses)

We've just put 2.1.0 in debian experimental. If you run debian testing/unstable, please consider trying it out and reporting your findings.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 9:27 UTC (Thu) by DrMcCoy (subscriber, #86699) [Link] (1 responses)

Well, I installed it, and aptitude removes dirmngr while it's at it.

gpg2 --refresh-keys complains about a missing /usr/bin/dirmngr, though. Reinstalling dirmngr, gpg2 --refresh-keys then "IPC connect call failed" when trying to connect to dirmngr. --refresh-keys is unusable.

No obvious google results, apart from a mailing list entry that dirmngr is mandatory.

GnuPG 2.1.0 "modern" released

Posted Nov 13, 2014 18:29 UTC (Thu) by dkg (subscriber, #55359) [Link]

It sounds like you might have the wrong version of dirmngr installed? gnupg2 from experimental Recommends: dirmngr >= 2.1.0~.

LWN is not a great place to report bugs in debian packaging, though. Would you mind opening a bug in the debian BTS where we can follow up with further details?


Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds