Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Mar 2014 13:19:46 -0700
From: Alex Gaynor <>
Subject: Re: When is broken crypto a vulnerability?

When thinking about this issue, I like to refer to:
time the behavior of the program violates the users intent in a way
which compromises their security, that's a security issue. To that end, any
of a-d, IMO, ought to quality for a CVE, the only acceptable way to expose
functionality like this is LegacyObviouslyBrokenZipEncryption.


On Mon, Mar 10, 2014 at 11:58 AM, Hanno Böck <> wrote:

> Hi,
> I'm currently looking into the issue of ZIP encryption and I'm asking
> myself what should be considered a vulnerability.
> Quick summary: The situation is rather horrible. There is a "legacy"
> ZIP encryption that has been broken since 1994. There are two competing
> standards for AES encryption on ZIP files, one by PKWARE, the other by
> WinZip (although the WinZip one is used by pretty much everybody and
> the PKWARE one only by PKZIP).
> The 1994 attack is a known plaintext attack. There's an improved
> attack since 2001 that works in many cases without a known plaintext,
> however there's no public source implementing that. Some commercial
> tools implement this attack.
> Now there are all kinds of applications doing one of the following
> things:
> a) Just support the legacy "encryption" without any indication that
> it's broken.
> b) Provide an option to use AES, but they don't use it and still
> create legacy "encryption".
> c) Default to legacy "encryption" without any indication that
> it's broken, provide an option for AES encryption.
> d) Default to AES encryption, provide legacy "encryption" under various
> names like ZipEncrypt, ZIP 2.0 or similar that give no indication that
> it's broken.
> I think it should be noncontroversial that b) is a vulnerability and
> thus should get a CVE. Any disagreement here?
> What do you think about the others? IMHO it's always inacceptable to
> provide an "encryption" option that doesn't really encrypt. 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 (like calling it
> "ZipCrypto(insecure)" or "insecure crypto" or something alike).
> Although I'd prefer if at least enduser oriented apps wouldn't support
> insecure encryption at all.
> However, are these vulnerabilities? Should they get CVEs? I'm not sure,
> but I'd tend to give at least the a) and c) case also CVEs. We have to
> keep in mind that we're not talking about "theoretically broken/weak"
> crypto, we're talking about "you can buy software that will give you
> the password"-broken.
> Opinions wanted.
> (I'm sending this to oss-security, it affects all kinds of opensource
> applications, but it obviously also affects non-opensource applications)
> cu,
> --
> Hanno Böck
> mail/jabber:
> GPG: BBB51E42

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ