"proprietary state-of-the-art end-to-end encryption technology,"
and people are somehow surprised ?
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 …
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.
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
"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.
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!.............
.....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
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)
- .....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."
@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.
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".
@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!!
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.
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.
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.
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...
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.
"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.
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.