[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140331161019.GG2642@sentinelchicken.org>
Date: Mon, 31 Mar 2014 09:10:20 -0700
From: Tim <tim-security@...tinelchicken.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVEs, Crypto and "vulnerabilities"
> I understand CVE guidance as "security issue in CVE sense, when
> assumptions for code are not met by the implementation"
>
> It is not clear what the assumption is here, what should be the result of the encryption
> and where should it be stored?
>
> Is it mostly obfuscation? Or secure storage of content?
This is a good way to frame the question.
It isn't clear to me, in this specific instance, how the tokens are
used or how an attacker could mess with the ciphertext. This is
simply because I'm too busy to read up on the issue.
However, in general, here's the typical assumptions developers make
about encryption (with ECB mode) and how the implementation fails to
meet those:
1. ECB mode encryption provides secrecy
- Partially fails this assumption since repeated plaintext blocks
result in repeated ciphertext blocks
2. ECB mode encryption provides integrity
- Badly fails this assumption since ciphertext blocks can be
duplicated/swapped, rearranged at will. If due to the context of
the encryption, if an attacker can conduct a partial
chosen-plaintext attack, typically whole ciphertexts can be
forged.
So depending on the context, it is clear that this could qualify for a
CVE in a well-defined way.
tim
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.
