Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Jun 2011 16:42:11 +0400
From: Solar Designer <>
Cc: "Steven M. Christey" <>
Subject: Re: CVE request: crypt_blowfish 8-bit character mishandling

Steve -

Can I have a CVE id, please?  ASAP, or I am releasing without referring
to a CVE id.

On Mon, Jun 20, 2011 at 03:43:20PM +0000, The Fungi wrote:
> No, I agree your proposed approach lends a more general solution
> which could be applied to the use cases I was considering. I saw you
> mention it over on the crypto list as well, but it sounded like you
> were trying to find ways to avoid a new hash encoding identifier in
> the wild which could conflict with something OpenBSD might consider
> assigning for some other purpose at a later date (though assuming
> this workaround makes it onto their radar, that seems an unlikely
> situation anyway).

Of course, I need to inform them that we're taking "$2x$" for our
backwards compatibility feature.

Here's how I am dealing with the issue in code:

Bug fix, plus a backwards compatibility feature:;r2=1.10

8-bit test vectors added, for both modes (correct and buggy):;r2=1.10

These are only used by "make check", which I felt was not enough - many
people are taking just the main C file and use it in their programs.
Obviously, my "make check" would not exist in their source code trees.
So if those programs are ever miscompiled or otherwise broken, it might
not be detected.  To deal with this, I added:

Quick self-test on every use:;r2=1.11

I am likely to go ahead and release this.


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.