why AA? why not just choose two random ascii salt chars at that point? or
since this is effectively a failure case encrypt a random ascii salt and
random string?
using AA will produce a usable result based on the original string.
encrypting a random string with a random salt means the failure r
I still don't understand.
This feels like fail-open.
> I would like to commit this fix. I tried to avoid the crash in
> libcrypto with least possible impact for the DES_fcrypt() API.
>
> ok?
>
> bluhm
>
> On Tue, Dec 05, 2017 at 05:20:49PM +0100, Alexander Bluhm wrote:
> > On Fri, Oct 27, 201
Hi,
I would like to commit this fix. I tried to avoid the crash in
libcrypto with least possible impact for the DES_fcrypt() API.
ok?
bluhm
On Tue, Dec 05, 2017 at 05:20:49PM +0100, Alexander Bluhm wrote:
> On Fri, Oct 27, 2017 at 01:50:26AM +0200, Jan Engelhardt wrote:
> > #include
> > int m
On Fri, Oct 27, 2017 at 01:50:26AM +0200, Jan Engelhardt wrote:
> #include
> int main(void) {
> char salt[3] = {0xf8, 0xd0, 0x00};
> char out[32];
> DES_fcrypt("foo", salt, out);
> }
This program produces a Segmentation fault in OpenBSD current.
> openssl 1.1.x has it fix
Thank you Jan. This is a good thing to fix, but I had a hard time envisioning a
security issue with it. Will see about backporting it though.
Regards
- Brent
> On Oct 26, 2017, at 6:50 PM, Jan Engelhardt wrote:
>
>
> libressl-2.6.2 is susceptible to an out-of-bounds read:
>
> #include
> in
libressl-2.6.2 is susceptible to an out-of-bounds read:
#include
int main(void) {
char salt[3] = {0xf8, 0xd0, 0x00};
char out[32];
DES_fcrypt("foo", salt, out);
}
Place in libressl's fcrypt.c:
x=ret[0]=((salt[0] == '\0')?'A':salt[0]);
Eswap0=con_salt[x]<<
