back to article Upstart encryption app walks back privacy claims, pulls from stores after probe

A new-ish messaging service that claimed to put privacy first has pulled its end-to-end encryption claims from its website and its app from both the Apple and Google software stores after being called out online. Converso – a comms app launched in September 2022 – billed itself as a "next-generation messaging app that keeps …

  1. Anonymous Coward
    Anonymous Coward

    "proprietary state-of-the-art end-to-end encryption technology,"

    and people are somehow surprised ?

    1. KittenHuffer Silver badge

      Re: "proprietary state-of-the-art end-to-end encryption technology,"

      Yeah, it's like the old 'new & improved' advertising line. If it's new how can it be an improvement when there was nothing before it, and if it's an improvement how can it be new?

      Encryption is very hard to get right. The most state of the art encryption is that which a lot of people have worked on (and is generally open source), so can't really be proprietary. And proprietary encryption means it has only been worked on by a few people (and is probably closed source), so is very unlikely to be state of the art.

      1. Anonymous Coward
        Anonymous Coward

        Re: "proprietary state-of-the-art end-to-end encryption technology,"

        Quote: "....proprietary encryption...is probably closed source..."

        This does not automatically mean that "it has only been worked on by a few people".

        You are eliding responsibility for the application code (which may be proprietary) with responsibility for underlying algorithms (which may be in the public domain).

        See: https://en.wikipedia.org/wiki/Daniel_J._Bernstein

        1. Anonymous Coward
          Anonymous Coward

          Re: "proprietary state-of-the-art end-to-end encryption technology,"

          Is there really any difference between a perfectly implemented very poor encryption algorithm and very poorly implemented perfect encryption algorithm... neither will do what they're supposed to.

          1. yetanotheraoc Silver badge

            Re: "proprietary state-of-the-art end-to-end encryption technology,"

            "Is there really any difference between a perfectly implemented very poor encryption algorithm and very poorly implemented perfect encryption algorithm"

            Yes, there's a difference. In the first case you have good programmers who don't know very much about encryption. Hands up those of us who don't know much about encryption. In the second case you have poor programmers who either know a fair bit about encryption, or more likely they just made a lucky pick. Give the first group a good algorithm, and you will get a good result. Give the second group a good algorithm, and ... oh, wait.

        2. KittenHuffer Silver badge

          Re: "proprietary state-of-the-art end-to-end encryption technology,"

          I thought the claim was that the encryption was proprietary. If the encryption is 'standard' and the app wrapping it up is proprietary then I feel the statement that they're making is misleading.

  2. Knightlie
    FAIL

    I saw this on Mastodon - the database of "encrypted" messages and users details was publicly accessible... :facepalm

  3. Anonymous Coward
    Anonymous Coward

    Sub-Contracted Privacy?? Really??

    Quote: "...A new-ish messaging service...no storage of messages on servers..."

    Have I mentioned before that the use of an interweb service which uses E2EE is a single point of failure for any user?

    That includes Signal, Telegram, WhatsApp....and all the other "services" on the interweb.

    Perhaps a better place to start would be a peer-to-peer messaging application:

    - software ONLY on peer devices (where encryption and decryption is done)

    - no stored or persistent or transmitted keys.......

    - .....but rather a random key for every message (calculated on each peer and thrown away after use)

    - perhaps using Gmail or mail.com as transport

    - .....so Eve gets a different hacking problem with every message....what a concept!

    If anyone is interested in the "single point of failure" assertion:

    - Link: https://forums.theregister.com/forum/all/2023/05/13/drug_arrests_sky_ecc/

    But no one wants to hear this....everyone seems to want to sub-contract their privacy to huge companies like Meta. Good luck with that!!!

    Sigh!.............

    1. Doctor Syntax Silver badge

      Re: Sub-Contracted Privacy?? Really??

      "Have I mentioned before ....?"

      How would we know? You're posting A/C

      1. Anonymous Coward
        Anonymous Coward

        Re: Sub-Contracted Privacy?? Really??

        @Doctor_Syntax

        There's more than one way of being anonymous......not just posting as A/C.......

    2. Crypto Monad Silver badge

      Re: Sub-Contracted Privacy?? Really??

      .....but rather a random key for every message (calculated on each peer and thrown away after use)

      And you think you're the first person to have thought of that?!

      Have a read of the protocol called OTR ("Off The Record"): https://otr.cypherpunks.ca/otr-wpes.pdf

      1. Anonymous Coward
        Anonymous Coward

        Re: Sub-Contracted Privacy?? Really??

        OTR and Torchat was how people were communicating back in my dodgier days around Silk Road and the likes. No saved msgs, all encrypted, many servers in case of compromise. And even then it'd existed for years. So many people verifying it works. Never understood why people would take up these new ones that are closed off.

        Going back even further, I used to be into warez, and we all communicated over IRC with encryption to the server, AND THEN with encryption in the client with Blowfish, with keys changing regularly so even if someone got in, they'd need the latest key. That was 2 DECADES ago. Bring back the classics I say!

        (Or ya know..don't do crimes I guess)

    3. An_Old_Dog Silver badge

      Re: Sub-Contracted Privacy?? Really??

      - .....but rather a random key for every message (calculated on each peer and thrown away after use)

      If you're not using "public" public-key cryptography, you still have to set up an initial key exchange between the parties.

      This reminds me of the "perfect" encryption method I thought up in high school using BASIC's RND() function ... and the flaws I realized it contained when I learned about random, vs pseudo-random, number generators in college. You learn more, and when you think about what you had thought, you say to yourself, "Oh, shit."

  4. Roger Lipscombe
    Big Brother

    It both is and isn't a hard problem

    The hard part of an encrypted messaging system isn't the encryption -- that's a thoroughly solved problem. The hard part is the key distribution.

    1. Anonymous Coward
      Anonymous Coward

      Re: It both is and isn't a hard problem

      @Roger_Lipscombe

      Quote: "The hard part is the key distribution"

      No....not at all! Secret keys do not need to be distributed at all. Keys can be arranged so that they are randomly assigned and are only calculated, used once and then thrown away.

      No keys saved or transmitted or persistent anywhere.

      Link: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

      Note that this article makes really confusing use of the words "key" and "keys". The D/H protocol uses tokens which have NOTHING to do with the secret key.

      Alice and Bob exchange tokens. They use these tokens to CALCULATE the secret key as needed at the point of use. The secret key is never saved or transmitted or persistent anywhere.

      1. Jon 37

        Re: It both is and isn't a hard problem

        That's just a way of solving part of the key distribution problem.

        It does not protect against an active attacker that can modify the communications. The attacker can substitute in their own negotiation messages, so Alice and Bob both have secure communications with Eve, not with each other. Eve can then forward the messages so they don't notice.

        It does not help with the problem of "is this really the person I think it is".

        1. Mishak Silver badge

          Re: It both is and isn't a hard problem

          Which is why Signal also has a "safety number" to validate the user at the other end is the person you think it is.

        2. Anonymous Coward
          Anonymous Coward

          Re: It both is and isn't a hard problem

          @Jon_37

          ....but not if Alice and Bob have exchanged their public tokens well away from the interweb, say using physical media. And this exchange only happens once.

          Eve never knows the values of these public tokens.....even though Alice and Bob do know them.

          Eve has even less insight into the private tokens.

          (1) How does Eve impersonate either Alice or Bob?

          (2) And if Alice and Bob use some prearranged topic (e.g. the names of two Alfred Hichcock movies) as authentication INSIDE encrypted messages, how would Eve replicate this hidden authentication?

          Eve really might have a pretty difficult job!!

          1. Anonymous Coward
            Anonymous Coward

            @AC - Re: It both is and isn't a hard problem

            Not if Eve works for a US Three Letter Agency.

      2. t245t Silver badge

        Re: It both is and isn't a hard problem

        > Alice and Bob exchange tokens. They use these tokens to CALCULATE the secret key as needed at the point of use. The secret key is never saved or transmitted or persistent anywhere.

        This gets a minus 11 downvote /s

        1. Anonymous Coward
          Anonymous Coward

          @t245t - Re: It both is and isn't a hard problem

          The part in which Alice is verifying before exchanging tokens that Bob is really the intended, real Bob, is missing. Without this, down votes are there to stay.

          1. Dizzy Dwarf

            Re: @t245t - It both is and isn't a hard problem

            Just check for malintent as per https://www.ietf.org/rfc/rfc3514.txt, and if clear, you're good to go.

            1. Claptrap314 Silver badge
              Pint

              Re: @t245t - It both is and isn't a hard problem

              Man. If that's not a greybeard nerdcheck, I don't know what is. No, I've not memorized that rfc's number. Yes, I knew what it was. Have one ----->

    2. Eclectic Man Silver badge
      Boffin

      Re: It both is and isn't a hard problem

      Roger Lipscombe: The hard part of an encrypted messaging system isn't the encryption -- that's a thoroughly solved problem.

      But the mathematicians are working all the time to break number-theoretic cryptographic algorithms, and AFAIK, there is no proof that factoring of large numbers, or solving the discrete logarithm problem in finite fields is 'difficult'. I am pretty sure that the UK's GCHQ knew about Elliptic Curve Cryptosystems before they were publicly proposed. (I asked Clifford Cocks* about this once, and there was a brief pause, when I realised I had been 'undiplomatic', and he replied that he thought Koblitz had published first. Make of that what you will.)

      The NSA, GCHQ and undoubtedly other FIS (Foreign Intelligence Services) almost certainly know things about current encryption algorithms that they are keeping very quiet about.

      *https://en.wikipedia.org/wiki/Clifford_Cocks#:~:text=Clifford%20Christopher%20Cocks%20CB%20FRS,in%201977)%20the%20RSA%20algorithm.

      1. Anonymous Coward
        Anonymous Coward

        @Eclectic Man - Re: It both is and isn't a hard problem

        I'm on your side with this.

        An encryption algorithm developed by foreigners that are not controlled by US, adopted so easily ?

        History is teaching us this : https://en.wikipedia.org/wiki/Bullrun_(decryption_program)

      2. Charlie Clark Silver badge

        Re: It both is and isn't a hard problem

        Any encryption algorithm that can be broken is as useless to the spooks as it is to anyone else. They've learned the hard way that the best algorithms are those devloped openly under peer review. When it comes to interception they know that there are plenty of old school methods that will get them what they want.

    3. Anonymous Coward
      Anonymous Coward

      Re: It both is and isn't a hard problem

      That is a solved problem too.

      The unsolvable element is actually the user.

  5. Captain Scarlet Silver badge
    Stop

    vulnerabilities

    Ok the vulnerabilities bit confused me, is this the Google Adsense part the vulnerability?

    1. Doctor Syntax Silver badge

      Re: vulnerabilities

      It's certainly not something you'd look for in something privacy related. You also have to ask yourself how it got there.

      Did the developers put it in deliberately and if so why?

      If it got dragged in with some other stuff imported from some repository somewhere what else got dragged in? And why did the developers not spot it? And what else didn't they spot?

      Either way it doesn't cast a good light on the development process.

    2. katrinab Silver badge
      Flame

      Re: vulnerabilities

      It certainly wasn't a good thing to put it there, but it was far from the worst example of a vulnerability in that POS.

      The fact that all the messages were stored in plain text in a publicly accessible database with no password was probably the biggest vulnerability.

      1. Captain Scarlet Silver badge

        Re: vulnerabilities

        Right yes that is it, read it twice and put it down as poor design rather than a vulnerability.

  6. Fred Flintstone Gold badge

    And so ..

    .. another inglorious attempt at subversion ends. As if that would even fly these days.

    Nice try, though, but the moment I see someone mention "proprietary encryption" they've lost me. Kerckhoffs' Principle and all that..

  7. Anonymous Coward
    Anonymous Coward

    He declined to answer a question about the Google Analytics tracker.

    He's embarrassed to admit it was, in fact, an accidental rogue Google engineer accidentally driving by who accidentally planted the tracker, accidentally by accident, which accidentally coincided with the code being accidentally exposed to accidental injection by accident. I mean what other POSSIBLE reasons can you think of...

    1. Doctor Syntax Silver badge

      Re: He declined to answer a question about the Google Analytics tracker.

      And nobody accidentally noticed that it had happened.

    2. Anonymous Coward
      Anonymous Coward

      Re: He declined to answer a question about the Google Analytics tracker.

      And by sheer amazing coincidence there was a backend ready to receive and hold that data, just as happened with Google's Streetview WiFi scanning.

      The very fact that they tried to sell that BS shows you just how much they hold the general public in contempt.

  8. Long John Silver
    Pirate

    The base criterion for judging a public encryption system?

    Ask not whether one's encrypted message can be decrypted by a third party. Instead, ask whether the anticipated timespan of secrecy is sufficient for the information to be used as intended, and without interference.

  9. choleric

    Signal AND WhatsApp?

    "It claimed it could stand up to the likes of Signal and WhatsApp in the security stakes."

    So you conflate the two in terms of security. It would be helpful to tease out how you do, and how you don't.

    One of the problems with discussions over secure comms is the lack of clarity.

    1. MJB7

      Re: Signal AND WhatsApp?

      Sure, Signal has _much_ better security than WhatsApp - but while Signal is top of the Premier League and WhatsApp is low in Division 1, Converso is a bunch of mates who get together for a kick-about and a beer.

  10. StrangerHereMyself Silver badge

    RSA

    What's wrong with using RSA as a public key encryption method? Yes, it's difficult to use but is IMHO as safe as other types (such as Elliptic Curve).

    Hell, even RC4 is used every day on a massive scale (in Microsoft's RDP protocol) and I never heard anyone cracking that.

    1. MJB7

      Re: RSA

      It is perfectly possible to write secure systems with RSA. What's wrong with it, is that it is slower to sign/encrypt than a corresponding EC algorithm, and it is _much_ slower to generate a new key. That last point matters if each participant generates a new keypair for each message (as they should), and only uses the persistent key pair for authenticity.

      There _is_ a theoretical point that because quantum computers break asymmetric cryptography in a completely different way to classical computers, a quantum computer that can break RSA-3076 will need about 12 times as many qbits as one that can break NIST-P256. If quantum computers develop at something like Moore's Law (a _big_ if), that gives RSA-3076 about a decade advantage over P256.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like