VanguardLH wrote on Fri, 26 Jan 2024 20:42:12 -0600 :

> Must be in those thousands of other discussions where a TrueCrypt-
> compatible Android app was mentioned. Wasn't mentioned in this thread.

You're wrong, but you're also right, so I'll correct what I said by saying
the app that decrypts/encrypts TrueCrypt/VeraCrypt container files was
mentioned twice in this thread
Message-ID: <uoumc0$2p9t$1@nnrp.usenet.blueworldhosting.com>
Message-ID: <uou4en$nd6$1@nnrp.usenet.blueworldhosting.com>

As I recall, both you and Frank responded to one of those each, so I simply
assumed you had understood what was stated - but apparently you didn't.

Each mentioned encrypted containers.
You were supposed to know that meant TrueCrypt/VeraCrypt containers.

So we're both right. And we're both wrong. :)

Anyway, I don't really like the EDS GUI, but it works as I've been using it
ever since it was suggested on this newsgroup many years ago for Veracrypt.

Frank Slootweg wrote on 26 Jan 2024 15:46:43 GMT :

> I indeed also had to do quite some searching to find a decryptor on
> Android.

If it's Android VeraCrypt/TrueCrypt container files you want
decrypted/encrypted using a free app then you might want to re-read these.

Message-ID: <uoumc0$2p9t$1@nnrp.usenet.blueworldhosting.com>
Message-ID: <uou4en$nd6$1@nnrp.usenet.blueworldhosting.com>
Message-ID: <up1u6m$jl8$1@nnrp.usenet.blueworldhosting.com>

> My need was/is for unpacking/decrypting archives, possibly only
> one file from that archive, but possibly more, so my needs are more than
> for a single (contacts) file.

That capability of single file plucking was also discussed in this thread.
Message-ID: <up1s3g$h9p$1@nnrp.usenet.blueworldhosting.com>
> That said: I use 7-Zip on the Windows side. On the Android side, the
> standard Samsung 'My Files' can extract an encrypted .zip file (I just
> use plain zip archive with ZipCrypto encryption), but it can only
> extract the whole archive, not individual files/folders.

See if the ZA app will do everything you've ever wanted such an app to do.
Message-ID: <up1p82$dmq$1@nnrp.usenet.blueworldhosting.com>

> So I searched Google Play for something better, amongst them
> 'SecureZIP Reader' (by PKWARE!) [1] and 'RAR' [2], but ended up with 'FX
> File Explorer' [3]. For decrypting single files, FX is probably over the
> top and probably not very handy, but since I needed a 'better'/other
> file manager anyway, that's what I ended up with.

If it's encryption/decryption inside of a file explorer that you want,
maybe you might want the Moto app which seems to do it as a file explorer.
Message-ID: <up1s3g$h9p$1@nnrp.usenet.blueworldhosting.com>

VanguardLH <V@nguard.lh> wrote:
> Frank Slootweg <this@ddress.is.invalid> wrote:
>
> > [1] <https://play.google.com/store/apps/details?id=com.pkware.android>
> "Updated on Jul 28, 2015". Tis possible nothing needs changing in the
> last 8 years over 9 Android versions. Went to:
>
> https://www.pkware.com/products/securezip
>
> Where it mentions "Try It Free", but also mentions having to buy it. It
> is 30-day trialware, so it might cripple itself therafter.

Oops! I did post the correct name 'SecureZIP Reader' (note: 'Reader'),
but I didn't realize that you probably also need writing. My need is
only for extracting/decrypting zip archives. Sorry about that.

> > [2] <https://play.google.com/store/apps/details?id=com.rarlab.rar>
>
> "Updated on Oct 5, 2023", so better maintained. As I recall, RARlabs
> allowed you to extract for free, but you had to buy it to create .rar
> files. That's why other archivers can read/extract from .rar files, but
> they can't write/create .rar archive files. Despite the app page shows
> a RAR app for Android, https://www.rarlab.com/shoprarlab.php does not.
> I did find a link on their home page (https://www.rarlab.com/) to their
> Android app, but no info at their own site about it.

While the app is *named* "RAR", it can handle many other archive
formats, including ZIP, which was the topic of this subthread.

And the 'About this app' pop-in clearly states that it can both
extract/unpack and create archives. And it mentions "encryption", so I
assume it can decrypt and encrypt.

> > [3] <https://play.google.com/store/apps/details?id=nextapp.fx>
>
> Created a shortcut to the app page to look at this one later.

A quick check shows that FX File Explorer can indeed also create
archives in all kinds of archive formats, BUT - at least so far - I've
not seen a way to set encryption when creating an archive (I know it can
decrypt when extracting and archive, because that's what I use it for).

On 2024-01-24 18:23, Andrew wrote:
> Carlos E. R. wrote on Wed, 24 Jan 2024 12:31:13 +0100 :
>
>>> That is why you should keep your default Android contacts completely empty.
>>> Each app you use should be chosen to maintain its own private contacts db.
>>
>> Bollocks.
>>
>> That's nuts.
>>
>> Very inconvenient and cumbersome.
>
> Nobody ever said staying private wasn't "very inconvenient & cumbersome".
> So your feeling it's too hard for you to remain private is likely correct.
>
> The people who take your contacts make it very convenient to upload them.
> Did you ever stop to wonder why they make it so easy to get your contacts?

I don't upload them. And WhatsApp doesn't upload them either, AFAIK.

I can not have one contact list for phones, another for street
addresses, another for whatsap, another for mail addresses. I don't do
it, and I refuse to do it, period.

You have a problem with that, then design some other ecosystem different
than Android, cheap and popular. Or change the laws, internationally,
and make them be obeyed.

--
Cheers, Carlos.

On 2024-01-26 09:44, Frankie wrote:
> On 26/1/2024, VanguardLH wrote:
>
>>> Then why do you need the net to use contacts already on the phone?
>>
>> Guess you completely missed synchronizing contacts between devices, and
>> why I wondered how Andrew did it. Here we go again.
>
> You're making this about a million times harder than it really is.
> Have you never used Microsoft Office not even once in your life?
> How much trouble can you have synchronizing a simple MS Office file?

I don't use MS Office, ever.

--
Cheers, Carlos.

Carlos E.R. wrote on Sat, 27 Jan 2024 22:30:50 +0100 :

>> The people who take your contacts make it very convenient to upload them.
>> Did you ever stop to wonder why they make it so easy to get your contacts?
>
> I don't upload them.

Google does.

> And WhatsApp doesn't upload them either, AFAIK.

How does WhatsApp know who in your contacts is a WhatsApp subscriber?

> I can not have one contact list for phones, another for street
> addresses, another for whatsap, another for mail addresses. I don't do
> it, and I refuse to do it, period.

I agreed that it's too much work for people like you to be private.

> You have a problem with that, then design some other ecosystem different
> than Android, cheap and popular. Or change the laws, internationally,
> and make them be obeyed.

It's easier than that as I've already designed it & explained how.

1. Don't store your contacts in the default Android contacts database.
2. Use (good) apps that respect that.

There are plenty of those app which we've already discussed in this thread.

On 27/1/2024, Carlos E.R. wrote:

>> You're making this about a million times harder than it really is.
>> Have you never used Microsoft Office not even once in your life?
>> How much trouble can you have synchronizing a simple MS Office file?
>
> I don't use MS Office, ever.

What kind of absurd argument do you have which is that you have to upload
your contacts to Google servers because you don't know how to sync files?

On 2024-01-27 22:54, Andrew wrote:
> Carlos E.R. wrote on Sat, 27 Jan 2024 22:30:50 +0100 :
>
>>> The people who take your contacts make it very convenient to upload them.
>>> Did you ever stop to wonder why they make it so easy to get your contacts?
>>
>> I don't upload them.
>
> Google does.
>
>> And WhatsApp doesn't upload them either, AFAIK.
>
> How does WhatsApp know who in your contacts is a WhatsApp subscriber?

That has been explained before in this forum.

For example.

When somebody registers to WhatsApp, that phone is added at
headquarters. Only that phone number.

Later, phone numbers on your contact list is compared to list and
headquarters, and it tells you which phones are subscribers. Then your
query is deleted.

You don't believe this? Prove it.

>
>> I can not have one contact list for phones, another for street
>> addresses, another for whatsap, another for mail addresses. I don't do
>> it, and I refuse to do it, period.
>
> I agreed that it's too much work for people like you to be private.

It is not my problem.

>
>> You have a problem with that, then design some other ecosystem different
>> than Android, cheap and popular. Or change the laws, internationally,
>> and make them be obeyed.
>
> It's easier than that as I've already designed it & explained how.
>
> 1. Don't store your contacts in the default Android contacts database.
> 2. Use (good) apps that respect that.
>
> There are plenty of those app which we've already discussed in this thread.

No, I will not do it.

--
Cheers, Carlos.

On 2024-01-27 22:54, Andrew wrote:
> Carlos E.R. wrote on Sat, 27 Jan 2024 22:30:50 +0100 :
>
>>> The people who take your contacts make it very convenient to upload them.
>>> Did you ever stop to wonder why they make it so easy to get your contacts?
>>
>> I don't upload them.
>
> Google does.

So?

--
Cheers, Carlos.

On 2024-01-27 22:58, Frankie wrote:
> On 27/1/2024, Carlos E.R. wrote:
>
>>> You're making this about a million times harder than it really is.
>>> Have you never used Microsoft Office not even once in your life?
>>> How much trouble can you have synchronizing a simple MS Office file?
>>
>> I don't use MS Office, ever.
>
> What kind of absurd argument do you have which is that you have to upload
> your contacts to Google servers because you don't know how to sync files?

I know how to sync files, I have been doing that for decades. I choose
not to and use the convenience of Google.

Your arguments are ridiculous to me.

--
Cheers, Carlos.

Andrew <andrew@spam.net> wrote:

> VanguardLH wrote on Fri, 26 Jan 2024 20:37:50 -0600 :
>
>> Thanks for the info on Syndoc. Don't yet need nor want a cloud
>> storage consolidator. Encrypt/decrypt looks to be through their web
>> UI. Only AES-256 is supported, but that's still pretty good. I'd
>> look more into Syndoc if I need another 10 GB of cloud storage to
>> add to my existing mix.
>
> Thanks for looking at it as the reason I pointed it out is because if
> you really wanted to store your contacts encrypted on the cloud, that
> app would do it easily for you with more control than you would have
> otherwise.
>
> I found it because I use the best Google Play Store search engine in
> the world (which has been discussed many times on this newsgroup in
> the past).
>
> If it's out there, it will find it. Since you wanted freeware without
> ads that had been updated recently, I set the search filters on that,
> plus I noticed you wanted recent updates, so I had it sort by recent
> updates.
>
> That's where ZArchive showed up on top of the list for the encryption
> and decryption of 7-zip archives that Frank Slootweg was discussing
> with you.

I was looking at AxCrypt, because it is cross-platform: Windows,
Android, and iOS. Alas, a bit more reading shows you can view (read)
encrypted files, but to create them requires a subscription. No thanks.

Syndoc claims to do both encrypt and decrypt; however, that requires
using their web site. Yuck! They only have Android and iOS clients, no
Windows client. 10 GB of cloud storage is nice, but unneeded in my
scenario with 32 GB in a OneDrive, GoogleDrive, and Dropbox scenario
(all free). Syndoc's free version has limited features and throttled
bandwidth (so there is a lure to pay for their Pro version). No thanks
to Syndoc mostly from having to use their web site to do
encrypt/decrypt.

Zarchiver has no network access, so I would have to incorporate the use
of the OneDrive, Google Drive, or Dropbox clients to perform cloud sync
between devices. Zarchive doesn't list .pea as supported, but .7s is
supported, so perhaps the TOC can be encrypted, too. I didn't find
Windows or iOS versions of Zarchiver. I'd be using Peazip on my Windows
hosts, and Zarchiver on my Android phones.

..7z (7-Zip) can include encrypting the file and folder names in the
hierarchy of objects (TOC - Table of Contents) contained in the
compressed archive file. Filenames often reflect their content. A file
names "2012-01-27 Bahama vacation" is probably not about you having to
chainsaw a tree downed from your neighbor's yard during a tornado that
smashed your fence. A folder named "Credit cards" with files underneath
named "MasterCharge", "Visa", "Home Depot", etc would be something that
pique's the interest of an attacker. A file named "Contacts" would be
more intersting than your vacation pics. Showing file and folder names
(TOC) leaks info to an attacker. The only other archive formats I know
of that let you encrypt the TOC is .rar and .arc. RAR format requires a
license to RARlabs to create .rar archives which means free apps won't
create .rar files. There is a RAR Android app which can read and create
..rar archives, but then RARlabs doesn't have to license to itself. I
rarely run across .rar files. Their Android app can read and create
..rar files, but I'd need a matching archiver on other platforms, and I
haven't seen an archiver that was free and created .rar files. WinRAR
costs $30.

..pea (Peazip) and ZPAQ, by design, have the files and folders (TOC)
remain hidden until the correct password is used to open them. For that
added security, you would need a decrypter that supports .7z and .pea
archives. I've never used ZPAQ (incremental journaling backup utility
and archiver) which seems more oriented to saving [incremental] backups
in compressed archives, and never seen anyone using it.

It's been decades since I last looked at SEA's ARC format, and don't
relish having to open a command shell to run its SQ and LU programs.
PKARC and PKXARC from Katz are for Windows: no mobile versions.
Archivers highly popular on Windows don't seem to have variants
available on mobile platforms, so I'd likely end up with a mixed app
setup: using Peazip on Windows, and something else on mobile platforms.

I do use Microsoft's OneNote which can encrypt sections in a notebook.
It is available on Windows, Android, and iOS, but not Linux (might be
usable under WINE, but probably has lots of .NET dependencies), and is
free. Like Syndoc, I could access OneNote using a web client on any
platform, but I'd rather not. While it integrates with OneDrive, files
could also be saved in folders monitored by the Google Drive and Dropbox
clients for cloud sync. However, OneNote uses AES 128 for encryption.
AES 128 is still secure, efficient, and fast, but AES 256 is more
resilient against brute force attacks. I was surprised, thought, that
Microsoft only used AES 128 encryption in their OneNote product.
Hackers would have to get past my online account's password, and then
past the encryption of protected sections in a OneNote notebook.

https://www.clickssl.net/blog/128-bit-ssl-encryption-vs-256-bit-ssl-encryption
Key size Time to crack
56 bit 399 seconds
128 bit 1.02 x 10^18 years
192 bit 1.872 x 10^37 years
256 bit 3.31 x 10^56 years

Then add the time to crack my account login password (13+ chars with no
words, just random chars, digits, and punctuation chars to avoid
dictionary attack), along with sites that throttle access on too many
failed password attempts. However, remember that the first guess in a
brute force attack could match the key. It could happen.

So, with OneNote available on multiple platforms, I have both a note
organizer (more than just text) and a decrypter on each platform. As
for my phones, I don't leave them unlocked. I use them, then lock them,
or rely on the 1-minute timeout to lock.

> There were 70 other apps which showed up in my search of a free
> archiver without ads and without any in-app purchases so there are
> too many of them.
>
> Some were special purpose archivers, such as this one which shares
> files.
> https://play.google.com/store/apps/details?id=shareit.lite

"We transfer absolutely without mobile data usage." So what's left?
Wifi, Bluetooth, and NFC. My phone is configured to prefer wifi over
data, but that's mostly for when I'm at home and the phone connects to
the wifi router. While there are lots of open wifi hotspots, I rarely
use those except when at a resort while on vacation. They say their app
doesn't use cellular data, but they don't say what it uses instead.
Maybe it parallels Tesla's attempt to pass electrical power through the
Earth. From https://www.ushareit.com/help/, file transfers are by wifi.
That severely limits when and where I can do transfers. I'd need access
to an open/public wifi hotspot.

> Others were file managers, such as this one which handles encrypted
> zips.
> https://play.google.com/store/apps/details?id=com.lenovo.FileBrowser2

Just a file manager that adds .zip support (and only .zip format). No
network access to do file transfers, so I'd have to incorporate with
cloud clients (OneDrive, Google Drive, Dropbox). With having to
integrate parts into a total solution, I'd probably go with Zarchiver
that supports more archive formats, the cloud clients, and the file
manager already bundled on the phone.

> There were quite a few zip decryptors/encryptors but with only a few
> downloads, and sensing you are risk adverse, I didn't mention them,
> such as
> https://play.google.com/store/apps/details?id=com.extractor.easyextractfile.zipper.filezipper

Says it is free, but also says it can create .rar files. Either they
didn't pay the license fee to RARlabs, or they're misleading with a
claim to create RAR archives. App pages says "Prep Apps" is the author,
but the description says "KGapps". No web site to get further info.
Their telephone number is in Pakistan. Calls itself Easy Unzip,
Unzipper, Easy Unzipper, Unzipper Master. No network access, so another
offline app that could be integrated in my cloud setup; however, I don't
trust this app.

> That app does what I think Frank Slootweg had asked it to do, which is:
> "Easy Unzipper enables archived content display without decompression."

That could be simply looking at the TOC showing files and folders. Most
archive formats don't hide that info. .7z, .pea, and ZPAQ will hide the
TOC, by design. Some archives add the option to hide/encrypt the TOC,
but they don't do anything unless one of the above archive formats.

I'm still looking, so thanks for the suggestions.

Frank Slootweg <this@ddress.is.invalid> wrote:

> <https://play.google.com/store/apps/details?id=com.rarlab.rar>
>
> While the app is *named* "RAR", it can handle many other archive
> formats, including ZIP, which was the topic of this subthread.

Yep. I was surprised it was free since they license their lib/tool to
create .rar files; however, they don't need to license to themself.
That one went on my short list of candidates.

Alan <nuh-uh@nope.com> wrote:

> Apple let's you upload your contacts...

This is an Android newsgroup.

> ...but they're encrypted:
>
> 'End-to-end encrypted data can be decrypted only on your trusted devices
> where you’re signed in with your Apple ID. No one else can access your
> end-to-end encrypted data — not even Apple'
>
> <https://support.apple.com/en-us/102651>

The only Apple product I have is an iPad that was free from my HMO with
tons of pre-loaded health apps. It's locked down (managed by HMO), so
of little other use. I can use it for more than the health stuff, but I
really don't care for Apple stuff. It does have an Apple ID assigned to
it (that I created for myself), but I don't do e-mails from it. Not
much point in having contacts there for now, but maybe I can unlock the
iPad so it is no longer managed. It mostly sits around collecting dust.
I've asked them about returning the iPad to them to eliminate wasting
it. It's probably getting trashed.

Can contacts from an Apple ID account (assuming contacts are stored
there in the cloud) be accessed by non-Apple products? I would think
without an Apple ID assigned to the device that end-to-end encryption
was not available.

Andrew <andrew@spam.net> wrote:

> Carlos E.R. wrote:
>
>> And WhatsApp doesn't upload them either, AFAIK.
>
> How does WhatsApp know who in your contacts is a WhatsApp subscriber?

WhatsApp claims end-to-end encryption: from client to client, and what's
on the server remains encrypted (in-situ on server). However, while
they do end-to-end encryption on messages, I cannot find specific
reference to encrypting contacts at the server. Also, even with
end-to-end encryption, that doesn't mean the data is encrypted at an
endpoint (client device). Malware or a hacker can still get at your
data if they get on your phone. End-to-end encryption is in-transit
protection, not necessarily in-situ protection at the clients, but it
looks like the WhatsApp server sees only encrypted data.

There is the Whatsapp.com web site, but you cannot log into an account
to look at your contacts. I didn't see a Login button or web form to
enter login credentials. Seems you must use their apps which employ
end-to-end (in-transit) encryption. The server would have the encrypted
data. However, I don't know their clients keep the data encrypted
in-situ. In-transit encryption, and no means to decrypt at the server
using a web site, means your data is as secure as how well you secure
your phone.

VanguardLH wrote on Sat, 27 Jan 2024 16:43:41 -0600 :

> I was looking at AxCrypt, because it is cross-platform: Windows,
> Android, and iOS. Alas, a bit more reading shows you can view (read)
> encrypted files, but to create them requires a subscription. No thanks.

I was about to test AxCrypt when you mentioned it, but not if it's that.
https://play.google.com/store/apps/details?id=net.axcrypt.axcrypt2x
> Syndoc claims to do both encrypt and decrypt; however, that requires
> using their web site. Yuck!

Yes. But. You said you wanted your contacts even if you lose the phone.
And you wanted contacts stored encrypted plus decrypted on the phone.
Plus you said you didn't want to have to set up the NAS drive to do that.

> They only have Android and iOS clients, no Windows client.
> 10 GB of cloud storage is nice, but unneeded in my
> scenario with 32 GB in a OneDrive, GoogleDrive, and Dropbox scenario
> (all free). Syndoc's free version has limited features and throttled
> bandwidth (so there is a lure to pay for their Pro version). No thanks
> to Syndoc mostly from having to use their web site to do encrypt/decrypt.

Yes. But. You said you wanted access to contacts if you lose the phone.
And you wanted contacts decrypted on the phone while stored encrypted.
Plus you said setting up your own NAS drive to do that was too much work.

You kept throwing up hurdles and I kept solving them in an easy way.
I'm not expecting you to all of a sudden start NOT storing your contacts in
the default Android database, nor to all of a sudden NOT be uploading them
to every server out there that asks for them.

I'm just expecting you to understand my point of view which is simple:
1. It's simple not to store your contacts in the default location.
2. And it's simple to do whatever it is you want to do with them afterward.

A person only need 2 things, which, unfortunately, most people don't have.
A. They have to be wise enough to know _why_ they don't want to store
their contacts in the default Android database & uploaded to servers.
B. They have to be intelligent enough to create their own solution
when they don't store their contacts in the default Android location.

That other guy who said that doing anything that Google didn't tell him to
do hurt his brain, for example - won't have either one of those two things.

> Zarchiver has no network access, so I would have to incorporate the use
> of the OneDrive, Google Drive, or Dropbox clients to perform cloud sync
> between devices.

I did give you a few other apps that do both archival and network access,
but ZArchiver solves a _different_ problem set. I mentioned ZArchiver
mostly to solve all the problems that Frank Slootweg said he wanted solved.

Frank hasn't responded, but I think ZArchiver solved all his stated needs.
https://play.google.com/store/apps/details?id=ru.zdevs.zarchiver

> Zarchive doesn't list .pea as supported, but .7s is
> supported, so perhaps the TOC can be encrypted, too.

What does "TOC" mean in this context. I see you mean "Table of Contents",
so I guess you mean what Frank meant by looking inside the
password-protected encrypted archive but without decompressing it first?

> I didn't find
> Windows or iOS versions of Zarchiver. I'd be using Peazip on my Windows
> hosts, and Zarchiver on my Android phones.

That's a completely different problem set, which wasn't stated, AFAIK,
until now, where cross-platform tools will mostly be the open source apps.

That's a completely different set of search filters which I didn't run.

> .7z (7-Zip) can include encrypting the file and folder names in the
> hierarchy of objects (TOC - Table of Contents) contained in the
> compressed archive file. Filenames often reflect their content. A file
> names "2012-01-27 Bahama vacation" is probably not about you having to
> chainsaw a tree downed from your neighbor's yard during a tornado that
> smashed your fence. A folder named "Credit cards" with files underneath
> named "MasterCharge", "Visa", "Home Depot", etc would be something that
> pique's the interest of an attacker. A file named "Contacts" would be
> more intersting than your vacation pics. Showing file and folder names
> (TOC) leaks info to an attacker. The only other archive formats I know
> of that let you encrypt the TOC is .rar and .arc. RAR format requires a
> license to RARlabs to create .rar archives which means free apps won't
> create .rar files. There is a RAR Android app which can read and create
> .rar archives, but then RARlabs doesn't have to license to itself. I
> rarely run across .rar files. Their Android app can read and create
> .rar files, but I'd need a matching archiver on other platforms, and I
> haven't seen an archiver that was free and created .rar files. WinRAR
> costs $30.
>
> .pea (Peazip) and ZPAQ, by design, have the files and folders (TOC)
> remain hidden until the correct password is used to open them. For that
> added security, you would need a decrypter that supports .7z and .pea
> archives. I've never used ZPAQ (incremental journaling backup utility
> and archiver) which seems more oriented to saving [incremental] backups
> in compressed archives, and never seen anyone using it.
>
> It's been decades since I last looked at SEA's ARC format, and don't
> relish having to open a command shell to run its SQ and LU programs.
> PKARC and PKXARC from Katz are for Windows: no mobile versions.
> Archivers highly popular on Windows don't seem to have variants
> available on mobile platforms, so I'd likely end up with a mixed app
> setup: using Peazip on Windows, and something else on mobile platforms.
>
> I do use Microsoft's OneNote which can encrypt sections in a notebook.
> It is available on Windows, Android, and iOS, but not Linux (might be
> usable under WINE, but probably has lots of .NET dependencies), and is
> free. Like Syndoc, I could access OneNote using a web client on any
> platform, but I'd rather not. While it integrates with OneDrive, files
> could also be saved in folders monitored by the Google Drive and Dropbox
> clients for cloud sync. However, OneNote uses AES 128 for encryption.
> AES 128 is still secure, efficient, and fast, but AES 256 is more
> resilient against brute force attacks. I was surprised, thought, that
> Microsoft only used AES 128 encryption in their OneNote product.
> Hackers would have to get past my online account's password, and then
> past the encryption of protected sections in a OneNote notebook.
>
> https://www.clickssl.net/blog/128-bit-ssl-encryption-vs-256-bit-ssl-encryption
> Key size Time to crack
> 56 bit 399 seconds
> 128 bit 1.02 x 10^18 years
> 192 bit 1.872 x 10^37 years
> 256 bit 3.31 x 10^56 years
>
> Then add the time to crack my account login password (13+ chars with no
> words, just random chars, digits, and punctuation chars to avoid
> dictionary attack), along with sites that throttle access on too many
> failed password attempts. However, remember that the first guess in a
> brute force attack could match the key. It could happen.
>
> So, with OneNote available on multiple platforms, I have both a note
> organizer (more than just text) and a decrypter on each platform. As
> for my phones, I don't leave them unlocked. I use them, then lock them,
> or rely on the 1-minute timeout to lock.

That's all very good information. Thanks for describing the issues.
You know this better than I do. I'm just trying to help you & Frank.

>> There were 70 other apps which showed up in my search of a free
>> archiver without ads and without any in-app purchases so there are
>> too many of them.
>>
>> Some were special purpose archivers, such as this one which shares
>> files.
>> https://play.google.com/store/apps/details?id=shareit.lite
>
> "We transfer absolutely without mobile data usage." So what's left?
> Wifi, Bluetooth, and NFC. My phone is configured to prefer wifi over
> data, but that's mostly for when I'm at home and the phone connects to
> the wifi router. While there are lots of open wifi hotspots, I rarely
> use those except when at a resort while on vacation. They say their app
> doesn't use cellular data, but they don't say what it uses instead.
> Maybe it parallels Tesla's attempt to pass electrical power through the
> Earth. From https://www.ushareit.com/help/, file transfers are by wifi.
> That severely limits when and where I can do transfers. I'd need access
> to an open/public wifi hotspot.

This special-purpose archiver was simply suggested to solve another hurdle
that you threw up which is how to transfer the encrypted files from one
place to another when you're not at home. That's all. It's another way.

VanguardLH wrote on Sat, 27 Jan 2024 17:25:27 -0600 :

>> How does WhatsApp know who in your contacts is a WhatsApp subscriber?
>
> WhatsApp claims end-to-end encryption: from client to client, and what's
> on the server remains encrypted (in-situ on server).

I know how WhatsApp says they do it but that wasn't his (Carlos) objection.
He said "And WhatsApp doesn't upload them either, AFAIK", which is wrong.

If you store your contacts in the default location, WhatsApp uploads them.
So do plenty of other apps (probably thousands but I don't know them all).

Just like you were doing, he was trying to find objections to why he was
doing exactly what Google told him to do (store contacts in the default
location and let any server that wants to upload them, upload them).

Privacy makes his brain hurt to even think about.
And he's like most people are.

You do the same things he does too.

The difference is his objections were absurd (and his statements wrong).
Your objections were based on you just being lazy (which is different).

> However, while
> they do end-to-end encryption on messages, I cannot find specific
> reference to encrypting contacts at the server. Also, even with
> end-to-end encryption, that doesn't mean the data is encrypted at an
> endpoint (client device). Malware or a hacker can still get at your
> data if they get on your phone. End-to-end encryption is in-transit
> protection, not necessarily in-situ protection at the clients, but it
> looks like the WhatsApp server sees only encrypted data.

As I understand how it works, unless you set the phone up like I do,
every time you run WhatsApp, it uploads your contacts to its servers.

Those contacts are encrypted & WhatsApp compares the hash to known hashes
of WhatsApp subscribers, which is the answer to the question I asked him.

"How does WhatsApp know who in your contacts is a WhatsApp subscriber?"

I knew the answer.
He didn't.

Your objections are because you don't want to do the work to remain
private. His objections are absurd as it made his brain hurt to think.

Specifically, he thinks his contacts are safe from WhatsApp but what he
doesn't know is there's a Venn-Diagram overlap going on that he missed.

So not only are his arguments absurd. They're wrong.

What he's trying to find a flaw in is my statement that started all this:
a. The safest place to store your contacts is NOT in the default location
b. And then to use (good) apps that respect that choice.

He can't find the flaw.
Neither can you.

All your objection were simply that you didn't want to have to think.
Because for every hurdle that you threw up, I gave you a simple solution.

> There is the Whatsapp.com web site, but you cannot log into an account
> to look at your contacts. I didn't see a Login button or web form to
> enter login credentials. Seems you must use their apps which employ
> end-to-end (in-transit) encryption. The server would have the encrypted
> data. However, I don't know their clients keep the data encrypted
> in-situ.

It's encrypted. And hashed. But why do you need to tell WhatsApp exactly
the Venn-Diagram overlap between their databases and _all_ your contacts?

> In-transit encryption, and no means to decrypt at the server
> using a web site, means your data is as secure as how well you secure
> your phone.

Most people store their contacts unencrypted in the default database.
And many (bad) apps habitually upload those contacts to their servers.

You lost control over them the instant that happened.

My statement still stands true that the safest way to prevent that (since
you won't know when it's happening) is to NOT store your contacts there.

That way there's nothing for misbehaving apps to upload to their server.

Andrew <andrew@spam.net> wrote:
[...]

> I did give you a few other apps that do both archival and network access,
> but ZArchiver solves a _different_ problem set. I mentioned ZArchiver
> mostly to solve all the problems that Frank Slootweg said he wanted solved.
>
> Frank hasn't responded, but I think ZArchiver solved all his stated needs.
> https://play.google.com/store/apps/details?id=ru.zdevs.zarchiver

For once, try to follow the discussion and try to read for
comprehension!

I don't have any problem. I was only giving information/suggestions to
*VanguardLH*, for encrypting/decrypting a contacts file *if* he wanted
to do that, which is *not* (yet) a given.

[...]

VanguardLH <V@nguard.lh> wrote:
> Frank Slootweg <this@ddress.is.invalid> wrote:
>
> > <https://play.google.com/store/apps/details?id=com.rarlab.rar>
> >
> > While the app is *named* "RAR", it can handle many other archive
> > formats, including ZIP, which was the topic of this subthread.
>
> Yep. I was surprised it was free since they license their lib/tool to
> create .rar files; however, they don't need to license to themself.
> That one went on my short list of candidates.

And - according to the 'About this app' pop-in - the "RAR" Android app
can also handle 7z archives, which you seem to prefer because it can
encrypt the TOC.

Carlos E.R. <robin_listas@es.invalid> wrote:
> On 2024-01-27 22:54, Andrew wrote:
> > Carlos E.R. wrote on Sat, 27 Jan 2024 22:30:50 +0100 :
> >
> >>> The people who take your contacts make it very convenient to upload them.
> >>> Did you ever stop to wonder why they make it so easy to get your contacts?
> >>
> >> I don't upload them.
> >
> > Google does.
>
> So?

Indeed. And "Google does" [upload your contacts] is also misleading,
because Google only does that if you - implicitly or explicitly -
tell/ask them to do so. You can select to not sync contacts or/and other
parts of your Google Accounts.

The wording also - dishonestly - implies that you give your contacts
to Google and that 'hence' Google can and does abuse/misuse/spread that
information. That's ofcourse nonsense, because Google would be sued to
bits.

*Fact* is that *if* you choose to upload your contacts to 'Google', it
only gets into *your* Google Account storage. Duh!

VanguardLH <V@nguard.lh> wrote:
> Andrew <andrew@spam.net> wrote:
>
> > Carlos E.R. wrote:
> >
> >> And WhatsApp doesn't upload them either, AFAIK.
> >
> > How does WhatsApp know who in your contacts is a WhatsApp subscriber?
>
> WhatsApp claims end-to-end encryption: from client to client, and what's
> on the server remains encrypted (in-situ on server). However, while
> they do end-to-end encryption on messages, I cannot find specific
> reference to encrypting contacts at the server.

Probably because WhatsApp does not store "contacts at the server"! :-)

I/we could point for the umpteenth time to what WhatsApp *does* do,
but where's the fun in *that*!? Better let 'Arlen' (or one of his
look-alikes?) dance around some more with all his urban legends, FUD,
innuendo, etc..

Sofar he's disparaged Google and WhatsApp without providing any
substance, proof, etc.. Why should he stop there!?

[...]

Andrew <andrew@spam.net> wrote:
> VanguardLH wrote on Sat, 27 Jan 2024 17:25:27 -0600 :
>
> >> How does WhatsApp know who in your contacts is a WhatsApp subscriber?
> >
> > WhatsApp claims end-to-end encryption: from client to client, and what's
> > on the server remains encrypted (in-situ on server).
>
> I know how WhatsApp says they do it but that wasn't his (Carlos) objection.
> He said "And WhatsApp doesn't upload them either, AFAIK", which is wrong.
>
> If you store your contacts in the default location, WhatsApp uploads them.

Nope, as Carlos correctly said, WhatsApp does *not* upload your
contacts! (Umpteenth repeat of clue-by-four: WhatsApp Legal)

If you think otherwise, *prove* it, with a cite from a *reputable*
source (complete with URL).

[...]

On 2024-01-28 16:32, Frank Slootweg wrote:
> Carlos E.R. <robin_listas@es.invalid> wrote:
>> On 2024-01-27 22:54, Andrew wrote:
>>> Carlos E.R. wrote on Sat, 27 Jan 2024 22:30:50 +0100 :
>>>
>>>>> The people who take your contacts make it very convenient to upload them.
>>>>> Did you ever stop to wonder why they make it so easy to get your contacts?
>>>>
>>>> I don't upload them.
>>>
>>> Google does.
>>
>> So?
>
> Indeed. And "Google does" [upload your contacts] is also misleading,
> because Google only does that if you - implicitly or explicitly -
> tell/ask them to do so. You can select to not sync contacts or/and other
> parts of your Google Accounts.
>
> The wording also - dishonestly - implies that you give your contacts
> to Google and that 'hence' Google can and does abuse/misuse/spread that
> information. That's ofcourse nonsense, because Google would be sued to
> bits.

Indeed!

> *Fact* is that *if* you choose to upload your contacts to 'Google', it
> only gets into *your* Google Account storage. Duh!

Exactly.

And to the NSA and the CIA, but such is life. My Google Account is
backed up on the cloud, but that doesn't mean that Google gives or sells
it to Meta, for instance.

Proof being that when I get a call from some new phone number, Google
doesn't display the name unless it is in *my* phone book. Google may
show the business name of some phone numbers, but that is a different
information that google gets by different methods. Not by reading phone
books of clients, and this is an information that could be found there
easily.

--
Cheers, Carlos.

Andrew <andrew@spam.net> wrote:

> VanguardLH wrote on Sat, 27 Jan 2024 16:43:41 -0600 :
>
>> Syndoc claims to do both encrypt and decrypt; however, that requires
>> using their web site. Yuck!
>
> Yes. But. You said you wanted your contacts even if you lose the
> phone. And you wanted contacts stored encrypted plus decrypted on the
> phone.

Web site access to contacts is a backup method. Be nice to get them
from there as a last resort, like if I lost my phone (lost, damaged,
stolen). However, my statement wasn't about whether or not the
contacts, or any file, was available at the server, but that you were
stuck using their web site to encrypt/decrypt rather than using their
client app. It was about where I could do the encrypt/decrypt that
dropped Suncoc as a candidate. Not even their $3/mo Syndoc Pro has
encrypt/decrypt in their client. Encrypt/decrypt at the client end is
mandatory for me, and web site encrypt/decrypt would be a backup feature
should I no have my client devices available.

> Plus you said you didn't want to have to set up the NAS drive to do that.

Not as easy as you mention. I've setup other servers on my intranet,
like VNC. The setup is not intuitive.

- Run the NAS or VNC server inside a DMZ (often a subnet off the
router).
- Punch a hole in the router's to allow inbound connections. You define
a rule to point at the server for inbound connections on a designated
port.
- Get an account with a DNS provider who supplies a DDNS (Dynamic DNS)
redirect service, like OpenDNS (they make finding their free service
hard to find).
- Install their IP updater client (*) which reports to your account with
the DNS provider what is your current IP address. I get a dynamic IP
from my ISP. A static IP would cost me money.
- In my OpenDNS account, define a hostname. I use that hostname to
reach OpenDNS who then looks up my account to see what is my current
IP address, and OpenDNS then redirects the connection to the WAN-side
of my router, which has a rule to punch through its firewall to
connect to the intranet server host (NAS or VNC).
- Obviously the intranet server host must be left powered on 24x7, and
the same for the router.
- Hope you aren't discovered violating your ISP's TOS on a personal-use
(non-business) service tier regarding operation of publicly accessible
servers on your intranet.

https://en.wikipedia.org/wiki/Dynamic_DNS
https://support.opendns.com/hc/en-us/articles/227987767-Using-Dynamic-DNS-with-OpenDNS
https://support.opendns.com/hc/en-us/articles/227987867-What-is-the-OpenDNS-Dynamic-IP-updater-client

I recall No-IP (https://www.noip.com/) was another similar DDNS service.
Been too long to remember why I chose OpenDNS over No-IP. Perhaps
because OpenDNS has categories (of censoring) of who would get blocked
through their redirection service.

Wouldn't need DDNS if I got a static IP address assigned to the WAN-side
of my router from my ISP's DHCP server, but that costs money. There are
free methods of transferring or accessing files across hosts or networks
without having to pay for a static IP address, like cloud sync.

Yes, for always-on cable Internet setups, IP addresses do not often
change. In fact, after the bind's expiration, and after losing the bind
(powering down your router, or resetting it), often the ISP's DHCP
server will assign a new bind using the same IP address. It's held in
limbo for a while. But once you lose the bind, there's no guarantee
you'll get the same IP address. That's why it's called dynamic IP.
Dynamic IP addressing is included in my service tier with my ISP. I
would have to upgrade to and pay for a business account to get a static
IP address. A business account would also allow me to run publicly
accessible servers on my intranet hosts. Doing so with a personal-use
service tier violates their TOS.

Note when you speak of NAS, I assumed you means a NAS drive sitting on
your intranet, not cloud NAS storage which, for me, would provide
nothing more than cloud storage services already provide to me (e.g.,
OneDrive, Google Drive, Dropbox) and which can be access via web browser
or, more preferrable, local sync clients.

>> They only have Android and iOS clients, no Windows client.
>> 10 GB of cloud storage is nice, but unneeded in my
>> scenario with 32 GB in a OneDrive, GoogleDrive, and Dropbox scenario
>> (all free). Syndoc's free version has limited features and throttled
>> bandwidth (so there is a lure to pay for their Pro version). No thanks
>> to Syndoc mostly from having to use their web site to do encrypt/decrypt.
>
> Yes. But. You said you wanted access to contacts if you lose the phone.

Again, the statement was about having to use their web site to do
encrypt/decrypt. Granted I would have access without an endpoint
device, but remember we were discussing how to protect those contacts.
You mention using apps that don't upload contacts anywhere, but mention
somehow toting or transferring a file full of contact records, so then
it became how to protect those contacts wherever they are stored. That
the apps don't upload them still meant you had to protect wherever you
had them.

> I'm just expecting you to understand my point of view which is simple:
> 1. It's simple not to store your contacts in the default location.

True. As noted by someone else, I can save contacts on the phone in its
storage which is still accessible by pointing the app there. They don't
get synchronized from there. Works okay for a single device, but
cumbersome when managed multiple devices. Then you mentioned importing
into the app (which presumably means the app is configured to save
contacts in local storage only). Then 2 points came up: how to protect
the contact records you import (via encrypt/decrypt), and how protecting
your contacts list protects all your contacts defined in your e-mails.
Got some info on how to supply encrypters/decrypters on each device, but
keeping the e-mails protected in-situ on the mail server was never
addressed (and I've only found 1 solution, so far, using ProtonMail,
that will still work with local e-mail clients).

> 2. And it's simple to do whatever it is you want to do with them afterward.
>
> A person only need 2 things, which, unfortunately, most people don't have.
> A. They have to be wise enough to know _why_ they don't want to store
> their contacts in the default Android database & uploaded to servers.
> B. They have to be intelligent enough to create their own solution
> when they don't store their contacts in the default Android location.

Yep, increased security is often not easy. However, I'm not wasting
time protecting my contacts if the e-mails are not protected. I might
consider the scenario where I transport an encrypted file to my devices,
decrypt it on the device, and import into an app configured to store
contacts on local-only storage. However, as ancient as it sounds to
you, however the mode of transport (file transfers, cloud storage, USB
drive), we're still back to the old Sneakernet scenario. Instead of
toting around a drive, you're toting around a file. In fact, since I
have to be physically present with the device to do the import into an
app that stores local-only, all that setup with cloud storage, NAS, FTP,
or whatever other electronic means is more difficult than toting around
a USB drive. After all, you claim you only modify your contacts maybe
once per year. All other setups take more effort than bringing a USB
drive to each device. You can have a smart-door on your house where you
wave your hands around to gesture an opening action, or you can just
stick a key in the lock to open. Sometimes folks come up with the most
convoluted (Rube Goldberg) schemes to peform a simple task.

>> Zarchiver has no network access, so I would have to incorporate the use
>> of the OneDrive, Google Drive, or Dropbox clients to perform cloud sync
>> between devices.
>
> I did give you a few other apps that do both archival and network access,
> but ZArchiver solves a _different_ problem set. I mentioned ZArchiver
> mostly to solve all the problems that Frank Slootweg said he wanted solved.
>
> Frank hasn't responded, but I think ZArchiver solved all his stated needs.
> https://play.google.com/store/apps/details?id=ru.zdevs.zarchiver

Since I already have the cloud sync clients (OneDrive, Google Drive,
Dropbox) on my devices, that solves the deficiency of Zarchive, or any
other archive app, of not having network access. So I'd get the
convenience of cloud sync across devices, the security of encrypted data
transfer, but I could also tote along a USB drive without anything going
across a network or stored online. No network solution is going to be
as secure as requiring a physical device.

>> Zarchive doesn't list .pea as supported, but .7s is
>> supported, so perhaps the TOC can be encrypted, too.
>
> What does "TOC" mean in this context. I see you mean "Table of Contents",
> so I guess you mean what Frank meant by looking inside the
> password-protected encrypted archive but without decompressing it first?

Frank Slootweg <this@ddress.is.invalid> wrote:

> VanguardLH <V@nguard.lh> wrote:
>> Frank Slootweg <this@ddress.is.invalid> wrote:
>>
>>> <https://play.google.com/store/apps/details?id=com.rarlab.rar>
>>>
>>> While the app is *named* "RAR", it can handle many other archive
>>> formats, including ZIP, which was the topic of this subthread.
>>
>> Yep. I was surprised it was free since they license their lib/tool to
>> create .rar files; however, they don't need to license to themself.
>> That one went on my short list of candidates.
>
> And - according to the 'About this app' pop-in - the "RAR" Android app
> can also handle 7z archives, which you seem to prefer because it can
> encrypt the TOC.

It can create .rar and .zip archives. It can only read/extract from .7z
archives, and others. I've decided to use Zarchive on Android which can
create .7z, .zip, and read other archive formats. Although I've run
into .rar files from which I needed to extract, I've never needed to
create .rar files. The cloud sync clients (OneDrive, Google Drive,
Dropbox) overcome Zarchiver's lack of network support.

While encrypt/decrypt is mentioned for the Zarchiver app, the algorithm
is not mentioned, like if AES 128, 256, TwoFish, Whirlpool, Serpent, or
what. From a screenshot (http://zdevs.ru/en/za/user_guide.html), looks
like AES 256, but there is a down chevron indicating there are other
choices; however, the other choices might only be ZipCrypto which is the
old PKZIP encryption algorithm that has long been vulnerable, but is
compatible across all Zip archivers.

I already have OneNote on my Android and Windows hosts, and it can
encrypt (AES 128) sections of a notebook, and each page in a section can
have attachments, like files, images, etc, so I could use the setup I
already have for transferring contacts, or any other data across
devices. Funny to see how some users so negatively react to Sneakernet.
I don't need to use all that cloud sync setup with a USB drive. I can
use whichever transport method that's most convenient or available at
the time (what, never heard of Internet outages?).

I still remember the age-old analogy of a truckload of magnetic tapes
having a far higher bandwidth than any electronic communication
technology. A truckload of 1000 16-TB magnetic tape media hurdling down
a highway that takes 30 minutes to move from the vault to onsite is 7.1
Tb/s bandwidth. I only have 945 Mb/s downstream, and 18 Mb/s upstream
for my always-on cable Internet connection at home. An encrypted file
on a USB flash drive in my pocket is far more secure than the encrypted
file accessible on any network or server.

Andrew <andrew@spam.net> wrote:

> VanguardLH:
>
>>> How does WhatsApp know who in your contacts is a WhatsApp
>>> subscriber?
>>
>> WhatsApp claims end-to-end encryption: from client to client, and
>> what's on the server remains encrypted (in-situ on server).
>
> If you store your contacts in the default location, WhatsApp uploads
> them.

To where? Everything on the server is encrypted. It was encrypted by
the clients, some of it is stored on the server, but the majority of
traffic is end-to-end encrypted between the clients. I have not yet
found out where WhatsApp stores contact data.

That a service operates over a server in the cloud does not mandate
anything is stored in the cloud. Take Team Viewer for example. It
facilitates connections between clients. They do not participate in the
data transfer and that is client to client.

Since the WhatsApp clients are connecting to each other facilitated by a
server, why does anything need to be stored on the server? In the same
way you mention using clients that do not upload their contacts to a
server, but keep them local, why can't WhatsApp clients store contacts
local only? This would be exactly your scheme where the contacts app on
the phone stores contacts in a local file (that is not synchronized to
any server). Those in-storage contacts are available ONLY to the app on
the phone. They aren't up on the server. In fact, if you configure
your Contacts app to store local only, none of those contacts are
visible when you use the web browser to your online account. Those
local-only contacts remain hidden on the phone. Well, if you claim
contact apps can store contacts local only, why can't WhatsApp, too?

I'd have to see a technical paper describing just where contacts are
stored when using the WhatsApp service. Are they local only, or are
they up on the server? What would be the point of storing them on the
server if you cannot log into an account to look at them? I didn't see
a way to log into the whatsapp.com web site to look at an account. From
what I've read so far, WhatsApp doesn't maintain a contacts list. It
gets that list from your phone's address book. Well, we've already been
over how contacts can be kept local instead of synchronized to a server.

https://faq.whatsapp.com/345939311073077

> As I understand how it works, unless you set the phone up like I do,
> every time you run WhatsApp, it uploads your contacts to its servers.

Not what I read on how the WhatsApp operates.

> So not only are his arguments absurd. They're wrong.

So far, I think you're wrong about how WhatsApp handles contacts.

> It's encrypted. And hashed. But why do you need to tell WhatsApp
> exactly the Venn-Diagram overlap between their databases and _all_
> your contacts?

Because you register your phone number with WhatsApp, and so do other
WhatsApp users, and the WhatsApp client checks your contacts in your
phone's address book (wherever it might be stored locally) to see if
another WhatsApp client is online with that phone number.

Uploading your contacts to WhatsApp is *optional* to have them validate
your list against those who have registered with their service.

https://faq.whatsapp.com/1191526044909364/?helpref=hc_fnav

Well, just like you chose to store your contacts local only, you could
choose NOT to upload your contacts to have WhatsApp verify them.

I don't think either of us has full knowledge regarding the security of
contacts used with WhatsApp. Are you a WhatsApp user? I'm not. You're
making guesses based on how other apps operate, and I'm guessing from
what they say.