1. 26
    Keybase, Zoom and Messaging crypto privacy write.privacytools.io

  2. 22

    I’m glad I resisted everybody pushing me to use keybase.

    It’s centralized and closed, this was bound to happen.

    1. 9

      Even as somebody who did some of that pushing, I agree. This or something like it was inevitable. I had hoped there’d be more time…

      1. 4

        Could you elaborate your thinking here? I’m curious which aspect of this situation you’re concerned about.

        I’m currently a Keybase user, although I never used any of the chat/git/etc. features - I used it basically just as a way to help others bootstrap trust in the PGP key I use (because oh god, you’re not gonna use WoT). Now there’s a flood of people leaving the product, but to me the trust calculus is the same as before: sure the server is closed source, but the clients are free software so I didn’t (have to) trust the server anyway. That applies to Zoom now too; I don’t trust them but I don’t have to.

        I think there’s definitely cause for concern, don’t get me wrong: there’s an argument to be made that it’s more important that people are reviewing the client now, and that we don’t know if that’s actually happening (see e.g. OpenSSL before Heartbleed). I’m also nervous that they’re going to shut down the service. But most of the “I’m leaving Keybase” commenters, AFAICT, don’t seem to see this nuance; instead they’re just saying that Zoom owning Keybase suddenly means that the entire service is universally untrustworthy. That just makes no sense to me. The primary reason that Keybase was trustworthy before was because of the math that underlined the crypto, and Zoom acquiring Keybase doesn’t change mathematics.

        Am I missing something?

        1. 6

          Some keybase users (myself included) had been waiting for months to be able to disassociate the stellar wallet from their accounts. IIRC, this was a server side issue. (I don’t want to imply anything nefarious, but the fact is and was that you could disassociate all other identities/links, except the one that keybase had financial interests in.)

          That’s an example of a server-side issue that an open-source client and good maths doesn’t fix, unfortunately.

          The other development that I found strange is that the latest version of the identity proof process had vendor lock-in effects. You can no longer build a keybase server clone and be compatible with that version, unless you get e.g. lobsters to modify their integration. The original proof process did not have this property.

        2. 1

          What is centralized in this context?

        3. 10

          This post links to a project called “bitpost” which the author is involved with. I didn’t think it was worth submitting a separate article just to comment on that, but I wanted to share something I noticed.

          “Bitpost uses a proprietary encryption system.”. As of right now, that page describes a crypto system that has approximately 8-bit security if I understand it right. I think there might be a bug in the python-looking code, so it’s hard to be sure whether the code is representative of the system. In any case I don’t see any way you’d want to rely on this for private stuff without replacing that design with something else.

          Sorry if my comment is off-topic.

          Edit: I just saw that @freddyym is said author. Hi Freddy. Tl;dr: I think for the crypto algorithms you are better off taking something off the shelf. Such as nacl/libsodium. That doesn’t guarantee safety, but it certainly improves the chances (at least for myself, being a non-expert).

          1. 4

            Thanks for checking it out. I’m not developing the actual crypto, although I’ve expressed similar concerns. I’ll pass it on to the actual developer.

            1. 9

              This might be helpful in pointing out the concern: Assuming the “alpha list” is not considered to be secret, here’s a Mathematica demo that breaks this sytem (successfully decrypts the “test” message on that page):

              In[36]:= ReleaseHold[
                Hold@Map[(#/(GCD @@ xs)) &, xs] /. 
                 xs -> {812099919484224000000, 389131211419524000000, 
                   845937416129400000000, 812099919484224000000}] // 
                  "\"qP)\[Not]wkIv;M[nfNiE5Y/A`eQg0macX.uO,2}Dz \
              6LyVZRBptHs@'|lKU?^%£!h<jT#bS]&WFCx*8{93$:Go~d4rJ7(>1\\", {#}] &]
              Out[36]= {"t", "e", "s", "t"}

              Notably, it does rely on the alpha list, which you can see in the application of StringTake. It does not rely on the password at all, and does not do any sort of brute forcing - just first semester university maths (or late high school). But anyway, all of this shouldn’t matter. Pre-packaged stuff is definitely the way to go. :)

              Now if only I knew why that Hold is required…

              1. 3

                I also stumbled across this today. I’d recommend using something like cryptography.

                In any case, seeing a home-brewed toy implementation like this one doesn’t instil confidence.

                1. [Comment from banned user removed]

                  1. 4

                    Can you clarify what you mean by a cipher for privacy? What security goals does it aim to achieve that aren’t already covered by standard cryptographic primitives? PGP is showing its age nowadays and both are CLIs, not libraries.

                    I’m happy to discuss this more over email with yourself or the developer, if you reach out at the info in my profile.

                    1. [Comment from banned user removed]

                      1. 2

                        I still don’t understand what possible use-case there is for a home-rolled “cipher”.

                        1. [Comment from banned user removed]

                          1. 2
                            1. Encrypted messages are indistinguishable from random noise and so cannot be compressed.
                            2. A cipher is not a compression algorithm.
                            3. Compressing before encrypting seems more possible but it opens the doors to other security issues: https://sidechannel.tempestsi.com/a-brief-analysis-of-data-compression-security-issues-2d6368782e31
                            1. 3

                              That article is a lot of background context with very little coverage of the actual weakness.

                              To save you a click: compressing first leaks information about how compressible the content being sent is. If an attacker is able to inject traffic to a vpn (eg by getting the victim browser to visit a page they control) they can try different patterns; if the resulting traffic is small, it has been compressed well, indicating that the pattern appears in some other content on the vpn.

                              1. 1

                                This is extremely useful, thank you very much!

              2. 4

                I wrote up my thoughts on how users can protect themselves from this: https://peergos.org/posts/keybase-left-building

                1. 2

                  What I like most with Keybase is the encrypted git repos. Easy to setup and easy to start working with your team. If something like this exists that doesn’t require too much server administration, maybe I would switch.

                  1. 1

                    Others have expressed similar concern, though I’m not sure that a solution exists.