[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Mar 2014 19:58:01 +0100
From: Hanno Böck <hanno@...eck.de>
To: oss-security@...ts.openwall.com, cve-assign@...re.org
Subject: When is broken crypto a vulnerability?
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
http://hboeck.de/
mail/jabber: hanno@...eck.de
GPG: BBB51E42
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
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.
