[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140310224809.452703fe@hboeck.de>
Date: Mon, 10 Mar 2014 22:48:09 +0100
From: Hanno Böck <hanno@...eck.de>
To: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: When is broken crypto a vulnerability?
On Mon, 10 Mar 2014 17:37:50 -0400 (EDT)
cve-assign@...re.org wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
Yes, that's exactly what I meant.
One product, it's already disclosed to the vendor and I will publish
details shortly. So we agree this one gets a CVE.
> > 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").
I have seen such misrepresentations, however I don't know exactly which
product it was. But I'd probably find it again.
> > 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.
Well, winzip-type aes-encryption has pretty wide support. I think
roughly 80%, the main exception being the linux commandline zip
(info-zip).
> > 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.
I think this is a different issue, because nobody says "encryption"
anywhere here.
It ultimately comes down to this: Do we consider "encryption" to be a
term that means "secure encryption" (something like AES) or would we
also consider a vigenere cipher "encryption"?
I'd vote that calling a well-known broken cipher "encryption" is a
misrepresentation and a possible risk.
But I get it you tend to disagree on that.
--
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.
