Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

Kim,

In cloud storage, zero-knowledge encryption is a privacy
model where the provider does not hold the key needed to
decrypt customer's protected data.

iow, "zero-knowledge encryption" is a mis-nomer.

You could as well claim that the intermediate servers in an SSL connection
work with "zero-knowledge encryption" - when all they do is to shuttle some binary data to and fro.

What Is End-to-End Encryption?

End-to-end encryption protects content from the moment
it leaves an authorized device until it reaches the
intended recipient's device.

Wrong again. That is not what it *is*, that is what it *does*.(or /should/ do).

End-to-End Encryption is simply the (act of) encrypting of the data on the source machine, and only allowed the data to be decrypted on the target
machine - because no other machines than those two have the (encryption and) decryption keys.

This is different from ordinary encryption at rest.

No, it isn't. Its not a property of an encryption method, its a feature of how the transfer is managed. P2P (point-to-point) versus P2S2P (point-to-server-to-point).

Encryption at rest protects files on a server, but the
provider may still control the keys that unlock them.

And there you have the problem : *why* should a provider have the decryption keys for data that is only ment for a specific recipient ?

Answer: The company - mostly one of those "social media" ones - wants to
know whom is saying what to whom. Hey, how otherwise would they know which kind of advertisements they best send to either party ? :-)

This is stronger than ordinary encryption in transit.

Bullshit.

The problem is not the encryption, but allowing other parties than the
source and target to have their respective decryption keys.

End-to-end encryption does not remove every security
responsibility.

Ofcourse not. But whats left has got absolutily zero to do with whatever
kind of encryption (if any) was used.

If you walk to or from the bank you can get robbed (or even forget the
plastic bag with the money in it in a bus or train, or even ontop of your car/cab. And yes, all three have happened). Thats is not something the
bank has any responsibility for.

iow, even if you do not use any kind of (end-to-end) encryption, you
*always* need basic computer sanitation (to keep malware outof it).
Otherwise you could loose a *lot* more than the contents of such an a end-to-end encryption protected converation.

Regards,
Rudy Wieser



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

Kim,

Perhaps you should contact the website and let them know your thoughts?

<https://cloudbasedbackup.com/en/blog/zero-knowledge-encryption-vs-end-to-end-encryption-whats-the-difference>

I've got no intention to talk to a sales department in made-up 10-dollar
words where common 10-cent words work as well.

And do read (first few lines of) both the "What Is Zero-Knowledge
Encryption?" and "What Is End-to-End Encryption?" paragraphs. They say
exactly what I posted.

Bottom line ? You're in a "dorothy visits the Wizard of Oz" situation,
quite impressed by what you see (read). Just do not look behind the
curtain, as that would ruin the magic. :-)

Regards,
Rudy Wieser




--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

Hermes,

Would you always trust the end-to-end security of popular messaging apps,

In one word ? No.

Some time ago there was such an app offering encrypted P2P communication,
but which turned out to be P2P to the server, and than from the server P2P
to the endpoint.

And even when they (now) name it E2E, a weaseling company could simply
define themselves to be an "E". Would you be able to detect that for yourself ? I don't think so.

or would you prefer to allow end users to manage it themselves?

How ?

And mind you, you said "messaging apps", not email where you create the message in a text-editor, than encypt it, and than add the resulting file as an attachment. Thats much to cumbersome - especially on a smartphone.

iow, if you offer the raw text to the messaging app you already have to
trust that the app will not MITM the conversation or also send a duplicate
to the message-apps company (or elsewhere).

Regards,
Rudy Wieser



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

On 2026-09-11 20:07, R.Wieser wrote:

Hermes,

...

or would you prefer to allow end users to manage it themselves?

How ?

And mind you, you said "messaging apps", not email where you create the message in a text-editor, than encypt it, and than add the resulting file as an attachment. Thats much to cumbersome - especially on a smartphone.

iow, if you offer the raw text to the messaging app you already have to
trust that the app will not MITM the conversation or also send a duplicate
to the message-apps company (or elsewhere).

Can the app, on install, create automatically an encryption key that
only exists on the app? Then send the public part to the server, so that
any client can download the public key of anyone they want to message.

All clients would do the same.

The private key, only exists on the client.

Just as PGP in email, but automatic. Would that work?

--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

Hermes,

MicroCrypt is a multi-purpose symmetric encryption app for mobile and desktop.

Symmetric ? That to me means its disqualified.

Users only need to exchange their password out of band,

:-) How ? Or, said otherwise : chicken-and-the-egg much ?

The nice thing about a-symetric keys is is that the encoding key may be known(!)/given to everyone - as long as the decoding key stays at home.

and then they can simply copy and paste the encrypted message
into any mobile or desktop app.

Did I already say that thats cumbersome ? Yeah, I think I did.

Lets go thru the steps, shall we ?

1) Open app.
2) Copy the received message
3) Paste it in the decoder app (if possible! Otherwise a file needs to be used)
4) Read the decoded message
5) Copy the message into a text-editor as a reference (you don't want to
have to remember everything you're replying to, do you ?), compose a reply
(, remove the reference text)
6) copy the reply text from the editor
7) Paste the text into the encoder (or again use a file)
8) Copy the encoded text (or again use a file)
9) paste encoded text into the message.

Thats a *lot* of steps. :-( Even more if the en/decoder only works with files.

It's so easy to use that even Granny Smith can use it with her grandchildren.

I sincerely doubt that.

Now if you would have said *her grandchildren* (5-year-olds) I would
probably have believed you. :-)

Regards,
Rudy Wieser



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

Carlos,

iow, if you offer the raw text to the messaging app you already have to
trust that the app will not MITM the conversation or also send a
duplicate
to the message-apps company (or elsewhere).

Can the app, on install, create automatically an encryption key that only exists on the app?

Than *you already trust the app* not to do either of what I mentioned, and
you quoted, in the above.

Then send the public part to the server, so that any client can download
the public key of anyone they want to message.

A messaging app could use *a* public key, not necessarily that of the
intended receipient. Can you view the public key use by the app for the current E2E message ? If not ....

... and even if you can that doesn't mean that that is the key thats used
...

Yes, there is a LOT of trust for the app involved. :-( :-)

All clients would do the same.

The private key, only exists on the client.

Just as PGP in email, but automatic. Would that work?

Only if you trust the messaging-app not to pull a fast one - again, see what you quoted.

Regards,
Rudy Wieser



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

On 2026-09-11 22:16, R.Wieser wrote:

Carlos,

iow, if you offer the raw text to the messaging app you already have to
trust that the app will not MITM the conversation or also send a
duplicate
to the message-apps company (or elsewhere).

Can the app, on install, create automatically an encryption key that only
exists on the app?

Than *you already trust the app* not to do either of what I mentioned, and you quoted, in the above.

Use open source.

Then send the public part to the server, so that any client can download
the public key of anyone they want to message.

A messaging app could use *a* public key, not necessarily that of the intended receipient. Can you view the public key use by the app for the current E2E message ? If not ....

... and even if you can that doesn't mean that that is the key thats used
...

Yes, there is a LOT of trust for the app involved. :-( :-)

Again, use open source.

All clients would do the same.

The private key, only exists on the client.

Just as PGP in email, but automatic. Would that work?

Only if you trust the messaging-app not to pull a fast one - again, see what you quoted.

Regards,
Rudy Wieser

--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

Hermes,

Lets go thru the steps, shall we ?

Sure!

[snip]

1) Open MicroCrypt.
2) Paste the received message, then decrypt and edit it in MicroCrypt.
3) Finish editing, then encrypt and copy/paste the message into your
messenger or email app.

Ah, thats what I get for trying to work with the incomplete information that has been provided : microcrypt is *not* an en/decryption program, its a text-editor that does en/decryption too.

But yes, that makes it a lot easier. Now if only microcrypt would /not/
have used a symmetric key ...

And by the way: the decryption in step #2 needs a decryption key. I take it that microcrypt offers an easy list to select the needed one from ?

Unless ofcourse granny just told their (grand)kids to use the same encryption-key ... :-)

Regards,
Rudy Wieser



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

Carlos,

Than *you already trust the app* not to do either of what I mentioned,
and
you quoted, in the above.

Use open source.

"open source" is not a magical solve-all incantation. Most people use open source in a pre-compiled form. Its better, but still far from perfect.

Yes, there is a LOT of trust for the app involved. :-( :-)

Again, use open source.

It doesn't change the "lots of trust for the involved" problem.

Unless you grab yourself the sourcecode, read *and understand* the whole
thing and than compile it on your own machine you still trust others to have done their work in this regard too

ref: the offered "walled gardens", where a number bad apps have been found where the developpers where unaware - caught-out by poisonned libraries.

Regards,
Rudy Wieser



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

On 2026-09-12, R.Wieser wrote:

Carlos,

Than *you already trust the app* not to do either of what I mentioned,
and
you quoted, in the above.

Use open source.

"open source" is not a magical solve-all incantation. Most people use open source in a pre-compiled form. Its better, but still far from perfect.

Yes, there is a LOT of trust for the app involved. :-( :-)

Again, use open source.

It doesn't change the "lots of trust for the involved" problem.

Unless you grab yourself the sourcecode, read *and understand* the whole thing and than compile it on your own machine you still trust others to have done their work in this regard too

ref: the offered "walled gardens", where a number bad apps have been found where the developpers where unaware - caught-out by poisonned
libraries.

Source being available still means inspection is possible, whereas with
closed source you really don't have much of an option other than blindly
trust (although, yes, reverse engineering is possible).

Now source being available also works better if you can reproducibly
build it, even if you're not building it yourself. I think F-Droid also
takes this into account, for example. (And this is also why some
licenses say you must make the source available, and if you're releasing
code that can't be used to build the same program, you'd be violating
the license, even if there is *some* source.)


You either trust the application or then you have to trust the OS to
provide some sort of unhijackable interface for encrypted messaging, for example, if the system could have a messaging interface
application, one or several messaging providers (SMS, E-mail, XMPP, ...)
and a separate optional encryption layer.

That does not sound easy to establish, but it at least would make it
easier to audit and trust the encryption part, while allowing different services, even proprietary ones. It would also have the benefit of a
stable, consistent interface between messaging systems (and herein lies
a disadvantage, because not all media are equal, compare the SMS message
length and text encoding needs with electronic mail, but OTOH we've had messaging apps supporting at least SMS and MMS).

Another disadvantage, of course, is the SPOF which could then be
attacked, by having e.g. manufacturers installing backdoored messaging systems...


(As for the encryption system itself, I'd personally favour asymmetric encryption with OpenPGP.)

--
Nuno Silva

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

Nuno,

Source being available still means inspection is possible,
whereas with closed source you really don't have much of an
option other than blindly trust (although, yes, reverse
engineering is possible).

So, in both cases inspection is /possible/ (1).

It doesn't mean that run-of-the-mill "compile me that, batman" users are capable to do either. And don't forget the libraries that are often
imported as binary blobs.

(1) Though I've dis-assembled enough programs to be aware that looking thru sourcecode is mostly a *lot* easier.

You either trust the application or then you have to trust the OS to
provide some sort of unhijackable interface for encrypted messaging,

Indeed.

Do I trust the Android messaging app ? Whats the reason I should ? I
cannot inspect what it does, nor what it sends/receives (does it even
actually encypt the message?), nor what happens in transit. Thats not
trust, that is having blind fate.

Also, you *start* with trusting the OS. If you can't trust it than all your apps could be above board, but that would not mean a thing.

And whatdoyouknow, I'm not running Googles Android. <whistle>

for example, if the system could have a messaging interface
application, one or several messaging providers (SMS, E-mail,
XMPP, ...) and a separate optional encryption layer.

Something like that, yes.

(and herein lies a disadvantage, because not all media are equal,
compare the SMS message length and text encoding needs with
electronic mail, but OTOH we've had messaging apps supporting at
least SMS and MMS).

Thats what status/error codes are for. :-)

Another disadvantage, of course, is the SPOF which could then
be attacked, by having e.g. manufacturers installing backdoored
messaging systems...

Thats not "another disadvantage", that is what we started with.

The *advantage* of the latter is that its modulair, allowing for mix-and-match. And as the complex stuff is in the modules, it would be a
lot easier for a (hobby) programmer to write an UI or posibly a commandline-interface (batch anyone ? :-) ) for it.

Regards,
Rudy Wieser



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Zero-Knowledge Encryption vs End-to-End Encryption: What's the Difference?

Librarian2025,

Symmetric ? That to me means its disqualified.

...

Asymmetric encryption solves key distribution problem,
nothing else.

Thats *one* of the things - a pretty major one - it solves.

But what is the *reason* that it solves the key distribution problem ?

Thats right, you do not need to keep the public key a secret.

Now you have only to ask yourself why that that is. :-)

Regards,
Rudy Wieser



--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)