1. 21
  1.  

  2. 13

    2 cent: gpg sucks, but this “signal is the best” hype shit really grinds my gears. i want sane federated encryption, not an encrypted fenced garden with moxie/facebook who decides. and accounts not chained to mobile numbers. pretty please.

    1. 4

      So, this is an aspect of Gruq’s philosophy as I understand it - I agree with your wishlist FWIW but I think he tries to embrace what he sees as best of breed tools in wide use.

      1. 4

        How about matrix.org for “sane federated encryption”? Or did you mean email-based?

        1. 3

          matrix is one of the saner proposals i’ve seen, yes. but last time i’ve looked there was not much activity in the repositories for servers (which were alpha/beta state). and i have a dislike of using http for everything (transport protocol over transport protocol over transport protocol.. it’s elephants all the way down!). inventing an own protocol doesn’t have to end with overstandartization. moxies argument against federation is that things will break because someone hasn’t implemented it. the web kind of works most of the time (even videos!11) and it’s federated as fsck!

          i fear we’ve lost the battle for chat systems for the next few years. whatsapp/signal were there at the right time and i guess fit the “worse is better” theme. at least irc seems not to have died yet, “The asteroid to kill this dinosaur is still in orbit.”. (irc isn’t really federated, but i cut it some slack as it is nearly 30 years old.)

          regarding encryption: the signal-way of doing crypto is nice, but doesn’t really work with non-realtime messages like mail afaik. i’d like to see something where one well reviewed algorithm is chosen as standard (maybe to be re-evaluated on a yearly basis or when required because of attacks against the cipher). gpg is such a complicated program because it has so many different ways of doing things. what really is needed is a tool with no options apart from choosing the keyfile to use.

          1. 4

            what servers? synapse is “late beta” and running quite ok on matrix.org homeserver. dendrite is seeing lots of development currently. The team isn’t against transports other than JSON-over-HTTP, but they also haven’t seen the need for anything else.

            Matrix megolm is somewhat based on signal double ratchet, but differs in significant ways in order to make non-realtime chat possible. It has been audited by NCC.

            1. 1

              “last time i’ve looked”, which was around fosdem and not really thorough. i’m sorry if my comment sounded like a matrix-rant! i sometimes tend to go all nit-picking :) matrix is sure one of the saner chat systems, and i’m glad anyone is still trying to do federated protocols (in their spare time. no less!)

              1. 2

                No worries. And no need to be sorry. I apologise if I made you feel like you had to. I’m glad if I could make some things more clear. Matrix is not currently done in spare time, but that might change if they don’t receive enough funding. Please see matrix.org for more info.

            2. 3

              I will tweak your remark about one well-reviewed algorithm: We need one well-reviewed protocol for each major use-case (1:1 chat, group chat, non-realtime communication, … there are some other important end-user needs for crypto beyond communication, too), and crypto algorithms need to be parameters to that protocol. The crypto choices need to be a parameter both so that users don’t have to trust a central authority’s choice of defaults, and to enable rapid deployment of changes in the event of a high-impact vulnerability.

              1. 3

                the funny thing is that most problems are solved (at least academically) since some time, but people don’t like to read papers. one example that comes to mind are regexp implementations.

                The crypto choices need to be a parameter both so that users don’t have to trust a central authority’s choice of defaults, and to enable rapid deployment of changes in the event of a high-impact vulnerability.

                i don’t really see a problem with choosing one of the well reviewed crypto algorithms, as long as it isn’t chosen by a single nation state / whatever. i think the best bet would be to trust the international community of cryptographers with this, as long as they can do it without interference from nation states. if we can’t trust them we are doomed either way.

                1. 2

                  I will tweak your remark about one well-reviewed algorithm: We need one well-reviewed protocol for each major use-case (1:1 chat, group chat, non-realtime communication

                  Exactly. I said that to them. Also, I advocated at least one high-assurance-secure implementation of each logical service (eg HTTP, filesystems) that was important to our infrastructure. The protocols and implementations funded by taxpayers like they do so much with top performing CompSci or private groups producing them. Then, we have at least one of every use case to draw on that should have low defects.If the hard work is done robustly & well-documented, the maintenance effort should cost less or take less volunteers. Plus, they can sell stuff on top of it with the core being a differentiator.

                  That was the hypothesis anyway. The politics of academia and realities of the marketplace might disagree with it when or if it’s attempted. ;)

                2. 1

                  what really is needed is a tool with no options apart from choosing the keyfile to use

                  A thousand times yes!

                3. 2

                  I’d love to hear somebody’s privacy and security analysis of matrix.org. Looking at that more closely has been on my to-do list for a while.

              2. 4

                GPG is so simple. You and someone else generate some keys. You exchange them safely somehow validating each other. Then, just write stuff in a text file with boring name, seal it with GPG, and send the resulting file over some medium (eg email). Ignore all other functionality since it’s complicated or requires trusting third parties. Just do one-to-one with text files. The UI problems could even be scripted away or programmed as an extension into an editor.

                The result: you get protection the NSA couldn’t break that works on diverse hardware and software (reduces subversion risk). Most people aren’t worried about NSA. Usually a weaker threat. So, something NSA had hard time with should be extra safe for them.

                1. 4

                  The problem is that simple, relatively easy to use work flow isn’t the one advocated. Instead gpg nerds go on about the web of trust and key signing parties and tell people off for doing minor things wrong.

                  Is there a gpg work flow documented somewhere that is as easy to use as signal and a verified key? I would love to use that.

                  1. 1

                    Not that easy yet but simple enough to be made easy. Start with this:

                    http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/

                    Here’s the major steps:

                    Generating key, exporting one’s own public key, importing others’ public keys, encrypting a file for a specific user whose key is in database, or decrypting a file from the user. The front end just needs to be able to handle those actions. The whole thing might be reduced to an open or seal command in a plugin for a text editor for day to day use with extra commands in the menu for generate, import, export, or backup db. Alternatively, a modification of GPG itself to straight-up delete all the other crap or at least the interfaces to it importing the result into a GUI app with better interface.

                  2. 3

                    The trouble is that all the boring, trivial UI stuff never gets done. Partly, I suspect, because no-one is ever paid to do it.

                    1. 2

                      the guy developing gpg gets money, more than a lot of free software projects can dream of: https://en.wikipedia.org/wiki/Werner_Koch

                      i guess with that money a somewhat usable gui should be possible.

                      1. 1

                        Remember that he got so little for so long he was thinking of quiting. Then, some emergency money was thrown at him largely without conditions after the press about that. So, it’s not the same as a person just making stuff with money coming in regularly with expectations by users for great UX. He can do it but is not incentivized to do it.

                        1. 2

                          Even if he was, he’s not a UX expert - that’s something that requires a bit of knowledge, planning, research, and likely a big refactor afterwards.

                          1. 1

                            Good point. Most programmers, esp for crypto stuff, aren’t UX experts. Hell, we’ve been seeing “Why Johnny Can’t Use My App” papers from them for some time now.

                            1. 2

                              Of course, he could hire a UX designer, (or firm) but that’s quite a bit of money. Considering GPG’s status though, someone might be willing to do it pro bono.

                          2. 2

                            usability is a well known reason why people don’t use it. why don’t take a part of the money and pay another developer to build and maintain a nice gui? if the wikipedia article is still correct, the donations of facebook and stripe equal $100000/y. even if it would be reduced to 50k due to taxes, it is still a nice amount of cash in germany: “In Germany, the average household net adjusted disposable income per capita is USD 31 925” http://www.oecdbetterlifeindex.org/topics/income/

                        2. 1

                          Good point. Alternatively, like with my experience, the programmers just hack together a solution that will work for them and their local audience. Then, don’t put in further effort to develop it into more general solution for wide audience. I didn’t even publish mine since they were very, very specific to my use case.

                          1. 6

                            keybase has done quite a decent job making a more user-friendly interface to GPG (CLI and GUI).

                            1. 4

                              Are they still encouraging users to hand over their private keys to them? That puts it in the bad sector as far as I’m concerned; if I’m going to be trusting a central organisation I might as well just use Facebook messenger.

                              1. 2

                                Good point. I loved the Keybase concept when I last looked into it. Since this topic keeps coming up, I might try out their client in the near future to see if I can offer something better than GPG cheat sheet haha.

                        3. 3

                          Ugh… this is just… so muddled on multiple levels.

                          Let’s start with PGP - PGP is a software suite currently developed by Symantec. Perhaps he meant GPG:

                          To help maintain this nerd street cred, pretty much every PGP guide on the Internet (and there are a lot of PGP guides on the Internet) has loads of arcane obscure weird commands to run. How to set up sub keys.

                          Because there are numerous GPG tutorials out there. For the record GPG and PGP both implement the same standard: OpenPGP.

                          Personally I think people want “easy encryption & security” but the fundamental problem is that one can’t outsource trust management. In the end one need to understand on a deeper level how security tools work even if they are “arcane obscure weird commands” initially. If they don’t want to maybe they don’t need more security than is already provided by TLS (e.g. HTTPS).

                          Other than that it doesn’t matter that much how you configure your PGP environment.

                          Well of course it matters as people have been compromised because of trivial mistakes like leaving version info in their messages.

                          The main problem with the YubiKey is that they tend to go missing, in which case you’ll lose access to all your emails.

                          Usually the encryption key is stored in key escrow, that means one generate it on an offline laptop and copies to all hardware tokens. Just like the master key.

                          Try to avoid PGP for more secure protocols instead (e.g. Signal, WhatsApp, even XMPP+OTR)

                          OMEMO is the new standard for encryption for XMPP. It offers several benefits over OTR like offline messages and support for multiple devices.

                          The main drawback of OpenPGP is that it doesn’t support forward secrecy so leaked key exposes all previous messages.

                          1. 2

                            Totally agree with the “use a yubikey” thing. It solves problems I was hung up on solving myself (like how to manage keys on all the machines I used).

                            Edit: Though, I don’t fully like yubikey - the form factor is dang near perfect.. but their implementations are not fully open source. NitroKey seems to be more in line with open sourcedness, but they are currently lacking the form factor.

                            1. 3

                              but their implementations are not fully open source.

                              Well I don’t know what’s your threat model but open-source won’t help much because even if you compiled the firmware yourself and loaded it on a hardware built by someone else you cannot be sure it’s working correctly or even at all. And even if you built the hardware yourself you’d have to trust your suppliers not to backdoor any part of your solution.

                              Yubico has an interesting blog post about that.

                              1. 3

                                I prefer it to be open source, not because of a threat model, but because if yubico goes under, someone will have to re-invent their wheel (assuming their IP wasn’t released… etc). The community will be stuck using devices (current open source implementations like the nitrokey) that do half the things.. and are 3 times the size.

                                Edit: RIP Pebble!

                                1. 1

                                  Fair enough.

                                  Yubikey NEO’s OpenPGP applet is open source. Although you cannot flash it on a regular Yubikey, you need a “developer edition” key.

                                2. 2

                                  Here’s mine on concepts of hardware subversion aimed at ASIC’s:

                                  https://news.ycombinator.com/item?id=10468624

                              2. 1

                                Thoughts about the utility of PGP/GPG make me question whether web-based models where nothing leaves the browser unencrypted - are an alternative, after all many trust (all) their passwords to such an approach?

                                1. 2

                                  The web browser model relies on a single common root of trust. There are around 150 organisations (the root CAs) who are more-or-less completely trusted (we’re starting to get some checks and balances on their activities, but it’s very much bolted-on. Meanwhile your security depends on the trustworthiness of e.g. the governments of Kazakhstan and Turkey, and several companies widely suspected to be under the control of the Chinese or US government. Likewise password managers tend to rely on entirely trusting the password manager operator. If you’re willing to trust a single central authority everything becomes a lot easier, but PGP/GPG is for people who can’t or won’t do so.