From Newsgroup: comp.mobile.android

What Is Zero-Knowledge Encryption?

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. Files are encrypted
before or within a customer-controlled environment, and
the provider stores an unreadable encrypted version
rather than the original content.

Think of a project lead placing confidential contracts
inside a locked safe before sending that safe to a
storage facility. The facility can store the safe, but
it cannot open it without the key. In the same way, a
zero-knowledge service is designed to store encrypted
files without being able to read their contents.

This is different from ordinary encryption at rest.
Encryption at rest protects files on a server, but the
provider may still control the keys that unlock them.
With zero-knowledge encryption, the key-control model is
designed to reduce that provider access.

There is a trade-off. If a team loses its password,
recovery key, or documented recovery process, the
provider may be unable to restore access to protected
files. For an IT manager choosing private cloud storage,
the right question is not only rCLIs it encrypted?rCY It is
rCLWho holds the keys, and how will our team recover
access if something goes wrong?rCY

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 recipientrCOs device. A message, call, or shared
file is turned into unreadable encrypted data before it
travels across the network. The recipientrCOs device then
uses the correct key to make that content readable
again.

Consider an HR manager sending a confidential employee
document to an external employment lawyer. With
end-to-end encryption, the document is protected during
the exchange so that the service carrying it does not
read the documentrCOs contents as it travels between the
two authorized devices.

This is stronger than ordinary encryption in transit.
Encryption in transit, such as a secure connection
between a browser and a cloud server, protects data on
that part of the journey. End-to-end encryption is
designed to protect the content all the way between the
intended endpoints.

End-to-end encryption does not remove every security
responsibility. A compromised laptop can expose files
after they are decrypted, and backups or connected
services may have their own protection model. Before
sharing sensitive files, an IT manager should confirm
what is covered by end-to-end encryption and which
parts of the workflow need separate controls.

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


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-09 20:41, Kim JongUn wrote:

What Is Zero-Knowledge Encryption?

...

What Is End-to-End Encryption?

Interesting, but why post it to comp.mobile.android?
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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

Rudy,

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>

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

R.Wieser once wrote:

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.

Would you always trust the end-to-end security of popular messaging apps,
or would you prefer to allow end users to manage it themselves?

Example: https://github.com/Ch1ffr3punk/MicroCrypt

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

R.Wieser once 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).

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

Users only need to exchange their password out of band, and then they can simply copy and paste the encrypted message into any mobile or desktop app.

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

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

R.Wieser once wrote:

Lets go thru the steps, shall we ?

Sure!

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.

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.

That's all Granny Smith has to do, with just a few clicks, while remembering the password for her loved ones. :-)

MicroCrypt is designed for the elderly, those who are not tech-savvy, and people with disabilities, as it avoids the high learning curve of OpenPGP
and leaves no traces on the user's device.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android


"R.Wieser" <address@is.invalid> writes:

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

Symmetric ? That to me means its disqualified.

Why though? There is no magical vulnerability in symmetric
encryption. Asymmetric encryption solves key distribution problem,
nothing else. If two people exchange keys as passwords written on pieces
of paper when they meet in person, then their encrypted messages do not magically become easier to decrypt.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Librarian2025 wrote:

"R.Wieser" <address@is.invalid> writes:

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

Symmetric ? That to me means its disqualified.

Why though? There is no magical vulnerability in symmetric
encryption. Asymmetric encryption solves key distribution problem,
nothing else. If two people exchange keys as passwords written on pieces
of paper when they meet in person, then their encrypted messages do not magically become easier to decrypt.

+1
--
https://contact.virebent.art
gemini://contact.virebent.art
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Gab,

Why though? There is no magical vulnerability in symmetric
encryption.

You're correct, there is nothing magical about it.

Asymmetric encryption solves key distribution problem,
nothing else.

Just think of what could happen when one of both parties "looses" their symetric key ? And just assume that they do not realise that it has happened.

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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

Gab,

Why though? There is no magical vulnerability in symmetric
encryption.

You're correct, there is nothing magical about it.

Asymmetric encryption solves key distribution problem,
nothing else.

Just think of what could happen when one of both parties "looses" their symetric key ? And just assume that they do not realise that it has happened.

You realize a few methods rely on generating and exchanging a symmetric
key in an initial step encrypted by asymmetric keys?
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Nuno,

You realize a few methods rely on generating and exchanging a
symmetric key in an initial step encrypted by asymmetric keys?

That would solve the problem related to exchanging(?) a symmetric key.

But than why use symmetric keys when you already have something that
generates and works with a-symmetric ones ? Thats twice the work, with no benefit.

Just think of what could happen when one of both parties "looses"
their symetric key ? And just assume that they do not realise
that it has happened.

You did not answer this one though.

What would be possible when someone else gets hold of the symmetric key ? Would he be able to MITM ?

Would he be able to do the same with either or both the public keys ?

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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

Nuno,

You realize a few methods rely on generating and exchanging a
symmetric key in an initial step encrypted by asymmetric keys?

That would solve the problem related to exchanging(?) a symmetric key.

But than why use symmetric keys when you already have something that generates and works with a-symmetric ones ? Thats twice the work, with no benefit.

Efficiency of computation, smaller complexity.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android


"R.Wieser" <address@is.invalid> writes:

Gab,

Why though? There is no magical vulnerability in symmetric
encryption.

You're correct, there is nothing magical about it.

Asymmetric encryption solves key distribution problem,
nothing else.

Just think of what could happen when one of both parties "looses" their symetric key ?

I'm pretty sure they then would exchange keys again. Same as they've
done before and same as they would have to do if one of them lose secret
key. The process of exchanging keys would be different, of course, but
not necessarily "worse" than in case of asymmetric encryption.

And just assume that they do not realise that it has
happened.

We can "just assume" a lot of things. Let's assume that one of them lost
their secret key and they lost the email of the other party. So now
they can't access their previous correspondence, and they don't know
where to write to re-establish communication. Now what?

Regards,
Rudy Wieser

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Nuno,

You realize a few methods rely on generating and exchanging a
symmetric key in an initial step encrypted by asymmetric keys?

...

But than why use symmetric keys when you already have something that
generates and works with a-symmetric ones ? Thats twice the work,
with no benefit.

Efficiency of computation, smaller complexity.

You do seem to have little context awareness.

Your answer is in regard to using only one encryption method (likely the symmetric key one). Your own "You realize" talks about using *both*
methods in the same program.

So, again : why use a symmetric key when you already have generated and used an a-symmetric one - just so you could safely get that symmetric key to some other party ?

Just think of what could happen when one of both parties "looses"
their symetric key ? And just assume that they do not realise
that it has happened.

I'm still missing an answer to this question though. :-|


I get the feeling that you have no idea how to defend your stance that the usage of symmetric encryption is equal to that of a-symmetric encryption.

In that case we should end our conversation sooner rather than later.

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Librarian2025,

Just think of what could happen when one of both parties "looses"
their symetric key ?

I'm pretty sure they then would exchange keys again.

Thats not what I asked.

We can "just assume" a lot of things.

Ah yes, the famous whataboutism.

Try to answer the question. If you can't than maybe just keep your mouth shut.

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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

Nuno,

You realize a few methods rely on generating and exchanging a
symmetric key in an initial step encrypted by asymmetric keys?

...

But than why use symmetric keys when you already have something that
generates and works with a-symmetric ones ? Thats twice the work,
with no benefit.

Efficiency of computation, smaller complexity.

You do seem to have little context awareness.

Your answer is in regard to using only one encryption method (likely the symmetric key one). Your own "You realize" talks about using *both* methods in the same program.

So, again : why use a symmetric key when you already have generated and used an a-symmetric one - just so you could safely get that symmetric key to some other party ?

Because the asymmetric encryption used to exchange the symmetric key is
more expensive than the symmetric encryption, so in a longer exchange
you do asymmetric encryption at the beginning, to establish the key for
the cheaper symmetric encryption that takes place for the rest of the conversation/exchange.

(See SSL and TLS.)

Just think of what could happen when one of both parties "looses"
their symetric key ? And just assume that they do not realise
that it has happened.

I'm still missing an answer to this question though. :-|

I get the feeling that you have no idea how to defend your stance that the usage of symmetric encryption is equal to that of a-symmetric
encryption.

That's not my stance.

In that case we should end our conversation sooner rather than later.

Regards,
Rudy Wieser

--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Nuno,

So, again : why use a symmetric key when you already have generated and
used an a-symmetric one - just so you could safely get that symmetric key
to some other party ?

Because the asymmetric encryption used to exchange the symmetric key is
more expensive than the symmetric encryption, so in a longer exchange
you do asymmetric encryption at the beginning, to establish the key for
the cheaper symmetric encryption that takes place for the rest of the conversation/exchange.

And so you have drifted off from how to use symmetric encryption keys for exchange of multiple messages (ref: hermes suggested MycroCrypt program) to
a so-called session-encryption key - normally with a rather short lifespan.

But you have a point, I did not think of doing it that way.

Just think of what could happen when one of both parties "looses"
their symetric key ? And just assume that they do not realise
that it has happened.

And I'm *still* missing an answer to this question.

I get the feeling that you have no idea how to defend your stance that
the usage of symmetric encryption is equal to that of a-symmetric
encryption.

That's not my stance.

Than what /is/ your stance ?


But, in a nutshell :

The security of a symmetric key fully depends on how often you replace it.

An a-symmetric public key doesn't have that vulnerability.

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android


"R.Wieser" <address@is.invalid> writes:

Librarian2025,

Just think of what could happen when one of both parties "looses"
their symetric key ?

I'm pretty sure they then would exchange keys again.

Thats not what I asked.

Well, that's what I answered.

We can "just assume" a lot of things.

Ah yes, the famous whataboutism.

It was not me who started with "just assume..."

Try to answer the question. If you can't than maybe just keep your mouth shut.

I'm not obligated to only give you answers that you like.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Librarian2025,

Just think of what could happen when one of both parties
"looses" their symetric key ?

I'm pretty sure they then would exchange keys again.

Thats not what I asked.

Well, that's what I answered.

And with it you've shown to me you're dishonest.

Goodbye.

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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

Nuno,

So, again : why use a symmetric key when you already have generated and
used an a-symmetric one - just so you could safely get that symmetric key >>> to some other party ?

Because the asymmetric encryption used to exchange the symmetric key is
more expensive than the symmetric encryption, so in a longer exchange
you do asymmetric encryption at the beginning, to establish the key for
the cheaper symmetric encryption that takes place for the rest of the
conversation/exchange.

And so you have drifted off from how to use symmetric encryption keys for exchange of multiple messages (ref: hermes suggested MycroCrypt program) to a so-called session-encryption key - normally with a rather short lifespan.

But you have a point, I did not think of doing it that way.

I think at one point in the thread the usefulness of symmetric
encryption was questioned, hence why I mentioned that.

Just think of what could happen when one of both parties "looses"
their symetric key ? And just assume that they do not realise
that it has happened.

And I'm *still* missing an answer to this question.

I get the feeling that you have no idea how to defend your stance that
the usage of symmetric encryption is equal to that of a-symmetric
encryption.

That's not my stance.

Than what /is/ your stance ?

If I have to have a stance and make it public on anything you choose to
point out in the context of threads I'm replying to, that's a game I
don't want to play.

But, in a nutshell :

The security of a symmetric key fully depends on how often you replace it.

An a-symmetric public key doesn't have that vulnerability.

Oh, but it does have similar weaknesses depending on size and the
advance of computing machinery, and making them age-limited is a thing
that *is* done too.

Regards,
Rudy Wieser

--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Nuno,

I think at one point in the thread the usefulness of symmetric
encryption was questioned, hence why I mentioned that.

Not by me. I *did* however question its application :

[quote=me]

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

Symmetric ? That to me means its disqualified.
[/quote]

I get the feeling that you have no idea how to defend your stance
that the usage of symmetric encryption is equal to that of
a-symmetric encryption.

That's not my stance.

Than what /is/ your stance ?

If I have to have a stance and make it public on anything you choose
to point out in the context of threads I'm replying to, that's a game
I don't want to play.

*You* say that thats not your stance , but when I than ask what that stance
is you don't want to tell ? Thats odd ...

But, in a nutshell :

The security of a symmetric key fully depends on how often you replace
it.

An a-symmetric public key doesn't have that vulnerability.

Oh, but it does have similar weaknesses depending on size and the
advance of computing machinery, and making them age-limited is a
thing that *is* done too.

Weaknesses that are equal or surpass that of a symmetric encryption ?

And Nuno, I've been *trying* to compare the security of the usage of the encryption *keys*. Can you stay on that subject ?

And to re-re-re-repeat myself :

[quote]
Just think of what could happen when one of both parties "looses"
their symmetric key ? And just assume that they do not realise
that it has happened.
[/quote]

I'm *still* missing an answer to this question. :-(

Or, bluntly said: I'm getting the feeling you want to ignore the, to me, obvious.

You may do that ofcourse, but you're getting tiresome. You want to put your POV (stance?) forward and have me respond to it ? Than I expect the same
from you.

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2