SoylentNews is people
SoylentNews
The GnuPG team is pleased to announce the availability of a new release
of GnuPG modern: Version 2.1.10. The main features of this release are
support for TOFU (Trust-On-First-Use) and anonymous key retrieval via
Tor.
...
Noteworthy changes in version 2.1.10
====================================
[More after the break.]
* gpg: New trust models "tofu" and "tofu+pgp".
* gpg: New command --tofu-policy. New options --tofu-default-policy
and --tofu-db-format.* gpg: New option --weak-digest to specify hash algorithms which
should be considered weak.* gpg: Allow the use of multiple --default-key options; take the last
available key.* gpg: New option --encrypt-to-default-key.
* gpg: New option --unwrap to only strip the encryption layer.
* gpg: New option --only-sign-text-ids to exclude photo IDs from key
signing.* gpg: Check for ambigious or non-matching key specification in the
config file or given to --encrypt-to.* gpg: Show the used card reader with --card-status.
* gpg: Print export statistics and an EXPORTED status line.
* gpg: Allow selecting subkeys by keyid in --edit-key.
* gpg: Allow updating the expiration time of multiple subkeys at
once.* dirmngr: New option --use-tor. For full support this requires
libassuan version 2.4.2 and a patched version of libadns
(e.g. adns-1.4-g10-7 as used by the standard Windows installer).* dirmngr: New option --nameserver to specify the nameserver used in
Tor mode.* dirmngr: Keyservers may again be specified by IP address.
* dirmngr: Fixed problems in resolving keyserver pools.
* dirmngr: Fixed handling of premature termination of TLS streams so
that large numbers of keys can be refreshed via hkps.* gpg: Fixed a regression in --locate-key [since 2.1.9].
* gpg: Fixed another bug for keyrings with legacy keys.
* gpgsm: Allow combinations of usage flags in --gen-key.
* Make tilde expansion work with most options.
* Many other cleanups and bug fixes.
A detailed description of the changes found in the 2.1 branch can be
found at https://gnupg.org/faq/whats-new-in-2.1.html.
(Score: 2) by fnj on Tuesday December 08 2015, @09:25PM
I am always tempted to think they never address the one overwhelming problem, which is that it is MUCH too hard to use. But on reflection, I always decide that is not/should not be gpg's job. All somebody has to do is introduce a nice GUI shell that presents a dead simple face with appropriate wisely-chosen options built in, and does no more than pull the levers on gpg.
The field looks wide open to me. There are a lot of fairly lame attempts, but I don't see anybody with anything you could remotely call a winner.
Now it's possible that gpg is just far too complicated to put a simple face on it. I've looked at a lot of GUI shells, and they all get bogged down in elaborate options for trust, expiration, what server to publish the public key on, etc. There are horrible problems with Enigmail on Thunderbird.
(Score: 3, Informative) by Nerdfest on Tuesday December 08 2015, @10:32PM
There are a few good ones. EnigMail for Thunderbird is pretty easy for email, as is KMail. K9 for Android works pretty well as well. There are a variety of file encryption utilities for Linux, Android, and probably Windows as well, that are also very simple to use. I really think it would have already become a lot more prevalent if a majority of people weren't using web based email these days. I seem to be one of the few remaining people, even among tech friends, that still uses a thick email client.
(Score: 2) by melikamp on Tuesday December 08 2015, @10:35PM
This is what I am thinking too. To make encryption easy to use, many things have to be implemented beyond the software that does encryption/decryption, and that's not up to GnuPG. For example (and only as example), we can imagine a solution I like to call "GnuPG fob". It is in the form of a USB stick sized computer which runs GnuPG and stores your key database. This requires a hardware manufacturer who designes and buids such machines. A user would have to keep the fob safe in the physical sense, which implies that the user has to be educated about the physical security of the key database. The fob can be used to authenticate and to sign anywhere. In a bank or at the ATM, for example, a user can insert the fob into a USB slot of the bank's computer and have it complete a challenge or to sign a statement. The bank gets zero access to the fob itself, but they can talk over https or whatnot. This scenario requires free communication standards designed and then implemented at the terminals. The fob can be used to authenticate the user at home: once the user inserts it into her own laptop, the laptop software recognizes it automagically and uses it as a service for encryption, decryption, and signing. This requires a coordinated effort on the part of the operating system AND application developers to make everything just workâ˘. If we take email as an example, the email client should be designed to recognize and to use this interface natively. The operating system must also supply an application to manage the fob: ideally, a user could do things like insert 2 fobs, click OK, and have them exchange public keys and such; or insert a fob, click on a web link, and have a public key instantly imported; or to insert a fob, and in 2 clicks have it exported to a reliable and robust public key server. These design challenges are massive, and none of them are GnuPG's responsibility. If anything, GnuPG seems to be the only party that did its homework, while everyone else was sitting on a couch stroking their... let's say egos.
If there's one thing GnuPG does not do well but probably should, it's the symmetric encryption. It's there, but it has a very manual feel to it. I think we should be able to create shared secret database entries (with names and all) and have the streamlined means of communicating via symmetric encryption, and that's arguably something GnuPG could implement in house.
(Score: 2) by VLM on Tuesday December 08 2015, @10:58PM
So a smart card basically.
Now what piece of hardware will have more security holes, a billion user generic operating system with decades of patching, or a thousand user dedicated appliance written next week?
In practice that thing would be powned so fast you'd hear a sonic boom.
(Score: 2) by melikamp on Wednesday December 09 2015, @12:05AM
Pwned how? I am curious to see a likely scenario. Let's say it has 2 hardware ins: the public end, which is used for plaintext, cyphertext, and public key exchange; and the private end, which is used for configuration. Let's say there is a hardware lock, too, to make the private end physically inaccessible during normal operation. I'd say the only practical way to "pwn" it is to steal it, but even that can be mitigated with additional physical security layers.
Anyway, the point is to show that an imaginary smart-card-like device can be easy to use, but this ease could only manifest itself within a software ecosystem which supports such a device, and there's absolutely nothing GnuPG (or similar app) can add to the picture. I'd even say, it looks like GnuPG is the only part of this use case whose implementation is up to par.
(Score: 2) by urza9814 on Wednesday December 09 2015, @08:44PM
So....a YubiKey [yubico.com]?
Just need more companies to roll out support for U2F [wikipedia.org]; the hardware and protocols already exist.
(Score: 1, Informative) by Anonymous Coward on Tuesday December 08 2015, @11:39PM
> All somebody has to do is introduce a nice GUI shell
>
Someone already has. It's called GPA or Gnu Privacy assistant:
https://www.gnupg.org/(en)/related_software/gpa/index.html [gnupg.org]
But now I suppose you'll be complaining that the GUI is not easy enough to use.