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

Hash: SHA1

> Now there are all kinds of applications doing one of the following
> things:

> b) Provide an option to use AES, but they don't use it and still
> create legacy "encryption".

> I think it should be noncontroversial that b) is a vulnerability and
> thus should get a CVE. Any disagreement here?

It's not completely clear what you mean. If it were a logic error in
the code, e.g., menu choice 2 of "AES encryption" is selected but the
code calls the function intended for menu choice 1 of "standard
encryption," then a CVE could be assigned to the specific codebase
that has that logic error.

There may be some types of UI issues that would not have CVE
assignments. For example: "AES encryption" is grayed out because the
product actually doesn't yet contain an implementation of AES, but the
grayed-out status is not as prominent as it could be.

> I could accept it if applications provide this as a compatibility
> option when there's a clear sign to the user that it's not secure

There's also the question of whether the security properties are well
known, and the product does not contain any direct misrepresentation
(e.g., stating that standard ZIP encryption is "equivalent to PGP" or
"uses 2048-bit keys").
suggests that the security properties have been known outside the
research community since 2005, and probably the security properties
have been widely known for much longer than that. Anyone making a
reasonable effort to determine whether standard ZIP encryption was
suitable for their use case could find applicable information.

As a side issue, one common use case for ZIP encryption is exchanging
files (such as virus samples) that would otherwise trigger unwanted
content detection by a mail system's scanner. In other words, a use
case does not necessarily have anything to do with confidentiality.

> c) Default to legacy "encryption"

Sometimes there are CVE assignments based on a general concept of "an
insecure option should not be the default" but here there's the
complication that only the insecure option has widespread cross-vendor
compatibility. One needs to consider the support costs of changing the
default. It's a usability decision for each vendor, based in part on
what they know about whether their customers use encryption for
confidentiality or for a different reason.

"It would be better for everyone if every vendor changed to a good
algorithm" isn't equivalent to "there should be a CVE for every vendor
who hasn't changed."

> calling it "ZipCrypto(insecure)" or "insecure crypto" or something alike

It doesn't seem appropriate to make CVE assignments on the basis that
a UI omits information that is arguably well known, and is not
specific to that one product. As an extreme example, every occurrence
of an http URL in a web browser could have a tooltip stating
"http(insecure)" or "insecure http," and a subset of web users would
then be safer. There is some subset of ZIP users who have dangerously
incorrect expectations about what encryption means, and one may want
to start an outreach effort toward ZIP product vendors who could
attempt to address that within their UIs. This does not necessarily
mean that the CVE project has a role in that outreach effort.

- -- 
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.