News: 1684305009

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

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

(2023/05/17)


A new-ish messaging service that claims to put users' privacy first has changed its tune – and the end-to-end encryption claims on its website – as well as pulling its app from both the Apple and Google app stores after being called out online.

Converso – a comms app launched in September 2022 – billed itself as a "next-generation messaging app that keeps your conversations completely private." This, according to the developer's website, included " [1]proprietary state-of-the-art end-to-end encryption technology," no storage of messages on servers, and " [2]absolutely no use of user data." It claimed it could stand up to the likes of Signal and WhatsApp in the security stakes.

A blogger who goes by Crnković and has an interest in encryption protocols heard about Converso from an ad on a podcast and decided to poke around to see if the software lived up to the hype.

[3]

To this end, he downloaded [4]the APK and said he'd found Converso's code, among other issues, contained a Google Analytics tracker – which is frowned upon in data privacy circles. The app also appeared to use RSA and a drop-in software development kit from Seald for encryption and public key authentication.

[5]

[6]

"Dissecting Converso was in large part a learn-as-you-go exercise for me, as I don't have prior experience reverse engineering mobile apps," Crnković told The Register . "I was shocked at each exponentially worse mistake."

Crnković published [7]an article about these findings on May 10, and The Register contacted Converso on May 12 for its response. By May 13, much of the wording on the website – including the "proprietary" E2EE claims – had since disappeared or been watered down quite a bit.

[8]

Converso CEO and founder Tanner Haas, in a long email to The Register , said his startup "takes issues with privacy very seriously, and when we were informed of vulnerabilities we immediately worked to patch them as quickly as possible."

"Any information related to users, phone numbers, and data is protected and not accessible to attackers," Haas continued. He declined to answer a question about the Google Analytics tracker.

Converso is "in talks" and "going to work directly with Seald," according to Haas. When asked what encryption protocol(s) Converso uses, Haas directed The Register to the [9]Seald website .

[10]Google: You get crypto, you get crypto, almost everyone gets email crypto!

[11]International cops urge Meta not to implement secure encryption for all

[12]Accidental WhatsApp account takeovers? It's a thing

[13]Meta, Twitter, Apple, Google urged to up encryption game in post-Roe America

We also asked Haas if Converso uses Seald as the app's only certificate authority for mapping identities to public keys, as Crnković noted in the blog.

"Although Seald is used as a third party certificate authority, there are additional authentication steps that are designed to prevent anyone from reading other users' protected messages," Haas wrote in the email. "This includes preventing users from accessing cipher texts that are not intended for them."

[14]

The messaging service had "already rebuilt the app authentication flow before any potential issues were exposed. Any secrets that are leaked on the client side are from an older version of the app, and anyone who is on the latest updates is no longer using the identities generated on the previous version," he added.

Haas encouraged Crnković to retest Converso in 60 days "with the same enthusiasm" as the original blog. He also reiterated "we never have and never will have commercial use of user data."

Additionally, the app has been "temporarily taken off" of the App Store and Google Play "while we address and improve any remaining potential vulnerabilities."

Let the countdown begin. ®

Get our [15]Tech Resources



[1] https://web.archive.org/web/20230423020851/https://conversoapp.com/about-us/

[2] https://web.archive.org/web/20230421215900/https://conversoapp.com/

[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZGSlyggTphfNXIa8oSDl2gAAAMA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[4] https://apkpure.com/converso-future-of-privacy/com.conversoapp.android/variant/1.0.7-XAPK

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZGSlyggTphfNXIa8oSDl2gAAAMA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZGSlyggTphfNXIa8oSDl2gAAAMA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[7] https://crnkovic.dev/testing-converso/

[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZGSlyggTphfNXIa8oSDl2gAAAMA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[9] https://www.seald.io/

[10] https://www.theregister.com/2023/03/01/google_client_side_encryption/

[11] https://www.theregister.com/2023/04/21/meta_encryption_police/

[12] https://www.theregister.com/2023/02/21/accidental_whatsapp_account_takeover/

[13] https://www.theregister.com/2022/09/20/encryption_abortion_data/

[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZGSlyggTphfNXIa8oSDl2gAAAMA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[15] https://whitepapers.theregister.com/



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

Anonymous Coward

and people are somehow surprised ?

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

KittenHuffer

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.

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

Anonymous Coward

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

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

Anonymous Coward

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.

Knightlie

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

Sub-Contracted Privacy?? Really??

Anonymous Coward

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!.............

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. The hard part is the key distribution.

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

Anonymous Coward

@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.

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

Jon 37

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".

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

Eclectic Man

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.

<Skyhook> Where is 'bavaria' proper? I thought it was austria.
-- Seen on #Linux