Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Jun 2011 10:03:20 -0400 (EDT)
From: Josh Bressers <>
Cc: "Steven M. Christey" <>
Subject: Re: CVE request: crypt_blowfish 8-bit character

Please use CVE-2011-2483.

Sorry I missed this yesterday. I suspect I got caught up reading up on it.


----- Original Message -----
> 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:
> 8-bit test vectors added, for both modes (correct and buggy):
> 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:
> I am likely to go ahead and release this.
> Alexander

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ