I'm using 7Zip V22.00 to generate a brand new (ie not adding to an existing
file) ZIP file (archive format=zip). I fill in the Encryption | Password
field and select encryption method=ZipCrypto. Compression level = normal,
compression method = deflate

But if I use the built-in extraction capabilities of Windows 7 or 10, it
sometimes allows me to open files within the Zip file without asking me for
the password. Likewise for extracting using 7zip. I realise that even
without the password I will be able to see the *list* of filenames.

Sometimes Windows (or 7Zip) prompts for a password. Sometimes I doesn't.
Generating a 7z file always prompts for password on unzipping.

What am I doing wrong, that 7Zip sometimes generates files that don't need a
password, even when I supply one when compressing? I need to generate zip
format rather than 7z to avoid the decrypter (having received the file by
email) having to have 7Zip installed, and instead to use the built-in
capabilities of Windows or MacOS.

NY wrote:

> I'm using 7Zip V22.00 to generate a brand new (ie not adding to an existing
> file) ZIP file (archive format=zip). I fill in the Encryption | Password
> field and select encryption method=ZipCrypto. Compression level = normal,
> compression method = deflate
>
> But if I use the built-in extraction capabilities of Windows 7 or 10, it
> sometimes allows me to open files within the Zip file without asking me for
> the password. Likewise for extracting using 7zip.

I have literally never had this happen. Are you sure you're actually entering
a password each time? Are you sure that the extracted files are what they're
supposed to be? (I've seen encrypted files get "extracted" without the
password resulting in blank/empty files. Not under Windows, but still.)

> I realise that even
> without the password I will be able to see the *list* of filenames.

Yes, this is normal.

> Sometimes Windows (or 7Zip) prompts for a password. Sometimes I doesn't.
> Generating a 7z file always prompts for password on unzipping.
>
> What am I doing wrong, that 7Zip sometimes generates files that don't need
> a password, even when I supply one when compressing? I need to generate zip
> format rather than 7z to avoid the decrypter (having received the file by
> email) having to have 7Zip installed, and instead to use the built-in
> capabilities of Windows or MacOS.

Try the most recent version, 22.01. If it continues, go to the forums and ask
there; you're more likely to get a good response.

https://sourceforge.net/p/sevenzip/discussion/

--
You sought vengeance. But that is a road that has no ending.

"Auric__" <not.my.real@email.address> wrote in message
news:XnsAEFF63074E416auricauricauricauric@88.198.57.247...
> NY wrote:
>
>> I'm using 7Zip V22.00 to generate a brand new (ie not adding to an
>> existing
>> file) ZIP file (archive format=zip). I fill in the Encryption | Password
>> field and select encryption method=ZipCrypto. Compression level = normal,
>> compression method = deflate
>>
>> But if I use the built-in extraction capabilities of Windows 7 or 10, it
>> sometimes allows me to open files within the Zip file without asking me
>> for
>> the password. Likewise for extracting using 7zip.
>
> I have literally never had this happen. Are you sure you're actually
> entering
> a password each time? Are you sure that the extracted files are what
> they're
> supposed to be? (I've seen encrypted files get "extracted" without the
> password resulting in blank/empty files. Not under Windows, but still.)

I had normal behaviour for several times, then I had it not prompt for a
password and allow "free" access to files within the ZIP for several
consecutive attempts, and now it's consistently working again. Very odd.

I think all the failures were from the same invocation of 7ZIP - ie without
closing and restarting it - whereas I might have closed and restarted
between the last time it failed and the first time it worked. But I always
generated a brand new file (either same ZIP name but delete old file outside
7ZIP, or else new filename) and I always filled in the password field.

I'll remember to check in future each time I generate a ZIP with a password,
to make sure the password is actually required and that it hasn't started
misbehaving again.

NY <me@privacy.invalid> wrote:

> I'm using 7Zip V22.00 to generate a brand new (ie not adding to an existing
> file) ZIP file (archive format=zip). I fill in the Encryption | Password
> field and select encryption method=ZipCrypto. Compression level = normal,
> compression method = deflate
>
> But if I use the built-in extraction capabilities of Windows 7 or 10, it
> sometimes allows me to open files within the Zip file without asking me for
> the password. Likewise for extracting using 7zip. I realise that even
> without the password I will be able to see the *list* of filenames.
>
> Sometimes Windows (or 7Zip) prompts for a password. Sometimes I doesn't.
> Generating a 7z file always prompts for password on unzipping.
>
> What am I doing wrong, that 7Zip sometimes generates files that don't need a
> password, even when I supply one when compressing? I need to generate zip
> format rather than 7z to avoid the decrypter (having received the file by
> email) having to have 7Zip installed, and instead to use the built-in
> capabilities of Windows or MacOS.

Zip files, presented as folder, do not encrypt the file system within
the archive. That is, you can open an encrypted archive to see the
files. The encryption applies to the files contained therein, not to
the metadata, like filenames. Have you tried to open a file inside a
..zip archive. The original ZIP format does not allow encryption of the
Central Directory.

File names can give away what a file might contain. If you want the
..zip archive to also encrypt the filenames, use the "Encrypt File Names"
option when creating the .zip archive. If you just encrypt the .zip
archive, the files are encrypted, and you need the password to decrypt
them. If you also encrypt the directory, you have to supply the
password to see the list of files when you open the .zip file.

ZipCrypto is the original encryption algorithm used by ZIP. It is
insecure. There are lots of tools that will decrypt a ZipCrypto archive
file. ZipCrypto is weak and vulnerable; however, if you use AES-256,
recipients of your encrypted files may have to find an alternative
archive compression tool that also supports AES-256.

https://blog.devolutions.net/2020/08/why-you-should-never-use-zipcrypto/

As I recall, archiving into the .7z format uses AES-256 by default.
Obviously 7-zip supports its own file format, but I use Peazip which
uses 7-zip libraries, so it also supports ZipCrypto and AES-256, and the
..7z file format.

https://en.wikipedia.org/wiki/PeaZip
PeaZip supports encryption[21] with AES 256-bit cipher in 7z, and ZIP
archive formats. In PeaZip's native PEA format, and in FreeArc's ARC
format, supported ciphers are AES 256-bit, Blowfish, Twofish 256 and
Serpent 256 (in PEA format, all ciphers are used in EAX authenticated
encryption mode).

From a cursory online search, 7-zip just supports ZipCrypto and AES-256,
but it can encrypt just the files, or also encrypt the directory.

Alternatively, instead of having 7-zip include encrypting the directory
inside a .zip archive, zip up the archive twice. Create a .zip file
with no password. Then .zip the .zip file again, but this second time
include a password. The outer .zip won't have the directory metadata
included in the inner .zip file. There is just the .zip file inside the
..zip archive, and to open it would require entering the password to
decrypt the inner .zip file (you are opening the inner file, so a
password would be required).

NY <me@privacy.invalid> wrote:

> "Auric__" <not.my.real@email.address> wrote in message
> news:XnsAEFF63074E416auricauricauricauric@88.198.57.247...
>> NY wrote:
>>
>>> I'm using 7Zip V22.00 to generate a brand new (ie not adding to an
>>> existing
>>> file) ZIP file (archive format=zip). I fill in the Encryption | Password
>>> field and select encryption method=ZipCrypto. Compression level = normal,
>>> compression method = deflate
>>>
>>> But if I use the built-in extraction capabilities of Windows 7 or 10, it
>>> sometimes allows me to open files within the Zip file without asking me
>>> for
>>> the password. Likewise for extracting using 7zip.
>>
>> I have literally never had this happen. Are you sure you're actually
>> entering
>> a password each time? Are you sure that the extracted files are what
>> they're
>> supposed to be? (I've seen encrypted files get "extracted" without the
>> password resulting in blank/empty files. Not under Windows, but still.)
>
> I had normal behaviour for several times, then I had it not prompt for a
> password and allow "free" access to files within the ZIP for several
> consecutive attempts, and now it's consistently working again. Very odd.
>
> I think all the failures were from the same invocation of 7ZIP - ie without
> closing and restarting it - whereas I might have closed and restarted
> between the last time it failed and the first time it worked. But I always
> generated a brand new file (either same ZIP name but delete old file outside
> 7ZIP, or else new filename) and I always filled in the password field.
>
> I'll remember to check in future each time I generate a ZIP with a password,
> to make sure the password is actually required and that it hasn't started
> misbehaving again.

Make sure to exit 7-zip when done with it to prevent caching a password
during a session of 7-zip.

On 8/26/2022 11:52 AM, NY wrote:
> I'm using 7Zip V22.00 to generate a brand new (ie not adding to an existing file) ZIP file (archive format=zip). I fill in the Encryption | Password field and select encryption method=ZipCrypto. Compression level = normal, compression method = deflate
>
> But if I use the built-in extraction capabilities of Windows 7 or 10, it sometimes allows me to open files within the Zip file without asking me for the password. Likewise for extracting using 7zip.  I realise that even without the password I will be able to see the *list* of filenames.
>
> Sometimes Windows (or 7Zip) prompts for a password. Sometimes I doesn't. Generating a 7z file always prompts for password on unzipping.
>
> What am I doing wrong, that 7Zip sometimes generates files that don't need a password, even when I supply one when compressing? I need to generate zip format rather than 7z to avoid the decrypter (having received the file by email) having to have 7Zip installed, and instead to use the built-in capabilities of Windows or MacOS.

You can add unencrypted files to an encrypted ZIP.

Double clicking an encrypted file, requests the password.
Double clicking an unencrypted file, requests no password.

To add a loose file to an archive, right-click the loose file
and use 7ZIP "add to archive", then select the archive you're
about to add it to. Then, don't forget to select the crypto type
and enter the password, so the loose file added to the end of the
archive, is encrypted as strongly as the rest of the archive.
There is no "inheritance property" here -- when you add a file,
you have to spec all the details yet again, just like you did
with the original bulk archiving attempt.

You can tell kinda, from the sprinkling of "PK" letter
sequences in the file, that the archive is modular, and
new items can be bolted on. And the properties of each
file, are kept with the file. That, to a small extent, is
why the filenames are exposed in the archive.

Formats with streaming encryption, maybe the password protects
the entire archive, and once you enter the password, the tool
can trundle along and select a chunk you want to open.

As for the three platforms, they're all the same. Archive Managers
on each platform, implement a minimal set of capabilities and try
not to step on any proprietary toes or do something that involves
lawsuits and lawyers. Even Igor Pavlov is doing that -- the "missing"
features you would expect to be in there, are missing because
a lawyer would object if they were present. You could not, for example,
just "steal" someone elses SFX engine and copy/pasta into an archive
your tool was producing. Igors implementation for 7z is excellent,
while the other formats are "also included". Igor does not even
attempt to steal PIGZ and do multi-core GZIP compression. It's still
done with a single core.

*******

You might consider adding PGP or GPG to an email tool, and
handle the encryption phase with the email tool. Leaving the
payload to be exposed enough that any Archive Manager could
open it (once the email tool has removed the encryption).

But that of course, is just as much of a pain in the ass,
as adding 7Z capability.

*******

Igor only provides full-feature 7ZIP in Windows. There is a
library of stuff provided for Linux, which contains the
"basic algo" for compress and decompress. That library
runs on one core and is dog slow. Whereas the full feature 7ZIP
has multicore compression and multicore decompression of .7z only.

This means that the Macintosh could have some exposure to .7z,
via the same library and package that Linux uses. On Linux,
on the Archive Manager, there is a claim you have to "install
7ZIP support" (that library), so that the Archive Manager will
attempt to open a 7ZIP. The Mac may not use such a method,
of optional addition of support libraries to extend capabilities.
But if there is a command line exposed, they may have a command
line version of 7ZIP. And that might involve a recipient
installing such stuff. There's that word again, "installing..."

*******

Summary: What you're doing is a hard problem. No platform supports
this stuff in a totally seamless no-fuss way. Your recipients
will need a brain on their shoulders, to get this done.

If I was sending encrypted transmissions to relatives of mine,
it would be nothing but hair loss, and I'd be completely bald
in only a few days :-) "I clicked your thingy and nothing happened."
I'm sure you're familiar with the endless phone call thing. In
fact, I tried a little experiment like that (because who can
resist such things), and the test was a dismal flop (no response
equals "I don't care what was in there" :-) ). But at least they
did not disappoint me. As a means of calibration, I now
know "one more thing that WONT work".

Paul

NY <me@privacy.invalid> wrote:
> I'm using 7Zip V22.00 to generate a brand new (ie not adding to an existing
> file) ZIP file (archive format=zip). I fill in the Encryption | Password
> field and select encryption method=ZipCrypto. Compression level = normal,
> compression method = deflate
>
> But if I use the built-in extraction capabilities of Windows 7 or 10, it
> sometimes allows me to open files within the Zip file without asking me for
> the password. Likewise for extracting using 7zip. I realise that even
> without the password I will be able to see the *list* of filenames.
>
> Sometimes Windows (or 7Zip) prompts for a password. Sometimes I doesn't.
> Generating a 7z file always prompts for password on unzipping.
>
> What am I doing wrong, that 7Zip sometimes generates files that don't need a
> password, even when I supply one when compressing?

I had written a detailed response, but then I could not reproduce the
problem scenario.

So instead, let me keep this short:

Does it work - i.e. asks for a password - when the encryption password
is *not* the same as your Windows account/login password?

And does it not work - i.e. doesn't ask for a password - when the
encryption password *is* the same as your Windows account/login
password?

If so, that's 'normal' behaviour or a bug. (I think the latter,
because IIRC it used to work that way (i.e. wrong), but AFAICT doesn't
work that way anymore )i.e. works correctly) for a recent version of
7-Zip.)

Hope this helps.

"VanguardLH" <V@nguard.LH> wrote in message
news:tui0tf7slqw8.dlg@v.nguard.lh...
> Zip files, presented as folder, do not encrypt the file system within
> the archive. That is, you can open an encrypted archive to see the
> files. The encryption applies to the files contained therein, not to
> the metadata, like filenames. Have you tried to open a file inside a
> .zip archive. The original ZIP format does not allow encryption of the
> Central Directory.

Sorry, I thought my original description implied that while I would expect
to be able to see the list of filenames in an encrypted ZIP, I would expect
to be challenged for a password when I tried to open one of those files. I
was finding that if I added the same files to a brand new archive, filling
in all the same options each time (including supplying a password),
*sometimes* the ZIP file would allow the built-in mechanism of Windows or
7ZIP (depending on how I opened the ZIP file) to open the files within it,
even if most of the time I *was* challenged for the password.

There was something that was behaving inconsistently. I wonder whether 7ZIP
had got into a strange state where it was not encrypting even though the
password filed was not blank, and this was cured by me happening to close
(kill) 7ZIP and restart it.

"VanguardLH" <V@nguard.LH> wrote in message
news:17owrldhkvory.dlg@v.nguard.lh...
> Make sure to exit 7-zip when done with it to prevent caching a password
> during a session of 7-zip.

Ah, so 7ZIP *does* cache/remember a password... I *think* I may have tried
with several different passwords during my testing (without restarting 7ZIP
between each ZIP file) but I may have cycled through a sequence that I'd
already used.

Useful to know the 7ZIP caches passwords and that it's necessary to stop and
restart the program after each new ZIP file.

"Frank Slootweg" <this@ddress.is.invalid> wrote in message
news:tebcde.v6s.1@ID-201911.user.individual.net...
> NY <me@privacy.invalid> wrote:
>> I'm using 7Zip V22.00 to generate a brand new (ie not adding to an
>> existing
>> file) ZIP file (archive format=zip). I fill in the Encryption | Password
>> field and select encryption method=ZipCrypto. Compression level = normal,
>> compression method = deflate
>>
>> But if I use the built-in extraction capabilities of Windows 7 or 10, it
>> sometimes allows me to open files within the Zip file without asking me
>> for
>> the password. Likewise for extracting using 7zip. I realise that even
>> without the password I will be able to see the *list* of filenames.
>>
>> Sometimes Windows (or 7Zip) prompts for a password. Sometimes I doesn't.
>> Generating a 7z file always prompts for password on unzipping.
>>
>> What am I doing wrong, that 7Zip sometimes generates files that don't
>> need a
>> password, even when I supply one when compressing?
>
> I had written a detailed response, but then I could not reproduce the
> problem scenario.
>
> So instead, let me keep this short:
>
> Does it work - i.e. asks for a password - when the encryption password
> is *not* the same as your Windows account/login password?
>
> And does it not work - i.e. doesn't ask for a password - when the
> encryption password *is* the same as your Windows account/login
> password?
>
> If so, that's 'normal' behaviour or a bug. (I think the latter,
> because IIRC it used to work that way (i.e. wrong), but AFAICT doesn't
> work that way anymore )i.e. works correctly) for a recent version of
> 7-Zip.)
>
> Hope this helps.

No, none of the encryption passwords that I used were the same as the
Windows password. I did try several times using the one password, and then
several times using another password, and VanguardLH has referred to
password caching.

On 8/27/2022 6:08 AM, NY wrote:
> "VanguardLH" <V@nguard.LH> wrote in message news:tui0tf7slqw8.dlg@v.nguard.lh...
>> Zip files, presented as folder, do not encrypt the file system within
>> the archive.  That is, you can open an encrypted archive to see the
>> files.  The encryption applies to the files contained therein, not to
>> the metadata, like filenames.  Have you tried to open a file inside a
>> .zip archive.  The original ZIP format does not allow encryption of the
>> Central Directory.
>
> Sorry, I thought my original description implied that while I would expect to be able to see the list of filenames in an encrypted ZIP, I would expect to be challenged for a password when I tried to open one of those files. I was finding that if I added the same files to a brand new archive, filling in all the same options each time (including supplying a password), *sometimes* the ZIP file would allow the built-in mechanism of Windows or 7ZIP (depending on how I opened the ZIP file) to open the files within it, even if most of the time I *was* challenged for the password.
>
> There was something that was behaving inconsistently. I wonder whether 7ZIP had got into a strange state where it was not encrypting even though the password filed was not blank, and this was cured by me happening to close (kill) 7ZIP and restart it.

You could add files to the archive, each file with a different password,
purely for testing purposes regarding challenges.

A discussion of which crypto method you should be using, and minimum
password length, are addressed here. ZIPCrypto method is apparently
based on CRC32.

https://security.stackexchange.com/questions/214998/how-long-should-zip-encryption-password-be-for-it-take-10-years-to-crack

Paul