Products Openwall GNU/*/Linux   server OS Linux Kernel Runtime Guard John the Ripper   password cracker Free & Open Source for any platform in the cloud Pro for Linux Pro for macOS Wordlists   for password cracking passwdqc   policy enforcement Free & Open Source for Unix Pro for Windows (Active Directory) yescrypt   KDF & password hashing yespower   Proof-of-Work (PoW) crypt_blowfish   password hashing phpass   ditto in PHP tcb   better password shadowing Pluggable Authentication Modules scanlogd   port scan detector popa3d   tiny POP3 daemon blists   web interface to mailing lists msulogin   single user mode login php_mt_seed   mt_rand() cracker Services Publications Articles Presentations Resources Mailing lists Community wiki Source code repositories (GitHub) Source code repositories (CVSweb) File archive & mirrors How to verify digital signatures OVE IDs What's new

Message-ID: <20140310195801.1f0cd122@hboeck.de>
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.