Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 31 Mar 2014 09:10:20 -0700
From: Tim <>
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

So depending on the context, it is clear that this could qualify for a
CVE in a well-defined way.


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.