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: 4, Insightful) by meustrus on Tuesday December 08 2015, @08:24PM
So...judging by the comments so far, GnuPG is still incredibly hard to understand at a glance even if you know what it's for. And nobody even bothers to explain what it's for. Right now I think it would be more important to make encryption *easy*, even more important to make it *hard to get wrong*, rather than making it stronger.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 2, Troll) by ticho on Tuesday December 08 2015, @08:47PM
No, everyone is just being an asshole, gnupg is pretty good. :)
(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.
(Score: 2) by gnuman on Tuesday December 08 2015, @10:01PM
Right now I think it would be more important to make encryption *easy*
No.
Encryption is no a panacea and to use it correctly you need to know how it works, more or less, or all you are doing is undermining your and possibly other's information safety. There is already a massive amount of information of web-of-trust and how to use GPG properly. If that is too much of a pain for you, then your use-pattern will not benefit from GPG anyway since, for sake of convenience, you will bypass required manual checking. In that scenario you are no better off than without it.
(Score: 2) by VLM on Tuesday December 08 2015, @10:55PM
And the other problem is application of a GUI shell never made something inherently complex, simple. Usually a GUI makes things harder to use.
You can make a bad UI easier, sometimes, with a good gui, but on average trying to layer any random UI on top of any other UI isn't going to improve anything.
You run into this a lot with the noobs talking about DF. Ya know, if the software company (its actually one dude..) upgraded it to make the dorfs cute cartoons, it would be way easier to play. And then all the DF players hurt themselves rolling their eyes. Sure, that's the problem, sure... Maybe in the opinion of a non-player.
(Score: 2) by Zinho on Tuesday December 08 2015, @11:35PM
Then it sounds like the challenge is education. In the perfect world everyone has the benefits of good encryption, not just the intellectual and programming elites. If the massive amount of information [thecodelesscode.com] that's available isn't within the mental grasp of the PHBs, grandmas, and department secretaries of the world then we can't expect the rest of us to get the benefits of herd immunity that we'd like.
One way or another we should bridge the gap between where we are and where we'd like to be. That will probably take:
* convincing everyone that encryption is important and worth their time
* making the tools and education needed accessible to everyone
* rolling out good encryption everywhere
As you correctly pointed out, doing it wrong hurts everyone. If the bar of learning to use the tools properly is too high (too much time investment required) then either the tools are wrong, the educational materials are wrong, or both. At the moment, I'd say that it's both.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
(Score: 3, Interesting) by darkfeline on Tuesday December 08 2015, @11:00PM
GnuPG is actually not that hard to use if you read the manual and not just the manpage. It's definitely a power user level program, though.
The solution is to create a separate configuration and management GUI and for apps to provide better integration. I don't think either of those is directly GnuPG's responsibility; I'd rather GnuPG focus on getting the details of the implementation right, because if the implementation is flawed, making it easier to use will do fuck-all for privacy and security.
Join the SDF Public Access UNIX System today!
(Score: 2) by FatPhil on Tuesday December 08 2015, @11:53PM
Open Source software = One act of power users
(That's an anagram, found by my g/f a couple of days ago, but I think it's rather good, so thought I'd share.)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Wednesday December 09 2015, @04:04AM
Is this where I channel RMS and say that then term Open Source misses the point? [gnu.org].
(Maybe your G/f can find an anagram for Free/Libre Software)
Wait... Your "anagram" introduces the letter 'p' in the second half of the equation. Shenanigans!
(Score: 0) by Anonymous Coward on Wednesday December 09 2015, @06:13AM
Nevermind. I found the 'p' on the left side of the equation (open).
(Score: 3, Informative) by frojack on Tuesday December 08 2015, @11:04PM
The only part I found hard to understand is TOFU.
TFS doesn't explain it, TFA just says "hey we got it", but none of the links lead to anything explaining WTF is TOFU. (The question is asked without reference to the equally mysterious food item).
Other than that, the installation utilities in some of the Email packages (Thunderbird's Enigma add-on, as well as others) pretty well handle all the mysterious steps these days.
No, you are mistaken. I've always had this sig.
(Score: 1) by Freebirth Toad on Wednesday December 09 2015, @06:51AM
From the GnuPG mailing list [gnupg.org]:
(Score: 0) by Anonymous Coward on Wednesday December 09 2015, @02:20AM
S/MIME is already built into virtually every non-web-based mail client out there, from PINE to Thunderbird to Apple's mail program for iGadgets. All you need is a certificate, which you can get for free from Comodo in 2048-bit strength. Once you have that, most of the programs just automagically configure everything for you.
If you have a cert in your keychain store in OSX, Apple's mail program automatically learns of it and uses it without you having to set anything up.
S/MIME provides most of the advantages of PGP (with one or two arcane flaws). It probably won't keep state-funded actors like the NSA/GHCQ from reading your mail (eventually), but it will keep out anyone else.
(Score: 0) by Anonymous Coward on Wednesday December 09 2015, @05:06PM
I will have to look into this, though asking the average user to not use webmail may be asking too much :P
(Score: 2) by meustrus on Tuesday December 15 2015, @09:28PM
This is my whole point. Casual users don't have the faintest idea what a certificate is or where to get one. You say you can get one from Comodo but is it appropriately secure by default? How would a casual user know it's secure? A good encryption scheme does not assume that its users know all of this. A good encryption scheme goes out of its way to educate its users and prevent them from making insecure decisions.
The worst problem is the "automagically" part. As a software developer myself, I hate magic. Absolutely hate it. When software behaves magically, that means that it's supposed to "just work". But software breaks sometimes. And when it breaks, the hoops developers went through to abstract all the gritty details ends up hiding them from me as I try to debug the problem.
Magic is really terrible in cryptography because when the software breaks, you won't even know it. You generated an insecure key and GnuPG let you use it anyway. You started secure mode but your ISP intercepted the commands and pretended everything was fine. You visited a web site with HTTPS but the certificate came from someone that you really don't trust (even though your browser does). There are solutions to all of these problems but you'll never look for them if you don't know it's broken. When magic is involved you won't know because everything magically "just worked" anyway.
You might say there is a contradiction here. How can I expect the tools to simultaneously configure themselves correctly and not be magical? Aren't those the same thing? Well the thing is that they aren't. Magic is not the same thing as sane defaults and consistent conventions. That's why the key is to prevent users from doing the wrong thing while still expecting them to do something and helping them do it.
Rather than keep trying to explain myself, however, I would like to defer to someone who has the experience to know what the good tools are. These recommendations from Edward Snowden [theintercept.com] are along the lines of what I'm suggesting. At least outside of the far more useful recommendations about operational security which is of far more utility to the average person anyway.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?