Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Mar 2014 02:15:25 -0400 (EDT)
Subject: Re: When is broken crypto a vulnerability?

Hash: SHA1

> We know that people want (at least) data confidentiality when they opt
> to use an "encryption" feature.

Actually, there are multiple contexts in which people use the ZIP
encryption feature when they're not looking for confidentiality.
Here's a sample help page from a university IT department:

  Our filters are unable to scan files within a password
  protected .zip archive. When the filters encounter a protected
  .zip file, a warning message is appended to the original
  message and is passed through with the attachment in tact. If
  you need to send or receive a file type on the blocked list,
  you can protect the .zip file with a password and supply the
  password in your message in order for your recipient to open
  the file. If you need to receive one of these files, you can
  forward instructions for your sender to do the same.

Because the password is included in the message, this is obviously not
a solution to address confidentiality. (In general, some mail systems
intentionally allow encrypted ZIP files for this functionality reason.
Some mail systems intentionally block encrypted ZIP files because they
are, on the whole, more likely to be malicious than unencrypted ones.)

Other references about essentially the same approach:
  "If you block say .exe files ... if someone really wants to send the
   file, they can in almost all cases just zip the file instead in an
   encrypted zip file we couldn't scan"
  "Our organization needs to be able to send and receive otherwise
   banned content (exe,bat,dll, etc...) via a password encrypted ZIP

We previously mentioned the use case of sending virus samples to
anti-virus vendors. This still occurs and was discussed in some blogs
last month:

Again, the password is well known, and thus the goal isn't
confidentiality. Some major vendors recommend or support this, e.g.,

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.