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: 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?