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.