libgcrypt 1.7.0 segfault (libcrypt-gcrypt-perl)

[NIIBE Yutaka]

On 04/22/2016 01:53 AM, Andreas Metzler wrote:
> libcrypt-gcrypt-perl triggers a segfault in libgcrypt 1.7.0. This does
> not show with libgcrypt 1.6.

Thank you for the report.  Err..., yes, it's a regression.

Nevertheless, I ask you to change the use of libcrypt-gcrypt(-perl) so
that it always call setkey before encryption, while libgcrypt will be
fixed.

Here is the detail...


>  % perl -MCrypt::GCrypt -e '$c=Crypt::GCrypt->new(type=>"cipher",algorithm=>"aes");$c->start("encrypting"); $c->encrypt("a").$c->finish'
> 
> which gets a SIGSEGV in libgcrypt. Backtrace below.
> 
> Adding a $c->setkey('whatever') before calling encrypt() makes it go
> away. The test isn't trying to do anything meaningful at that point,
> it's just checking that it gets a warning when not calling $c->finish()
> or something like that. Later tests of actual encrypting pass.

I see the scenario.  Libgcrypt 1.7 assumes setkey is called before
encryption.

Let me explain the situation of libgcrypt.  In the modification of
libgcrypt 1.6 to 1.7, performance improvement with SSSE3 was
introduced.  Internally, it now has ctx->encrypt_fn.  When setkey is
called, ctx->encrypt_fn is configured at runtime.  When setkey is
not called, it will get SEGV at encryption as it's not initialized.

> Is this something to be fixed on the libgcrypt side?

I think it is better that segfault should be fixed.  And documentation
should be fixed to explicitly explain expected call sequences (the
condition: setkey is required before encryption).

For me, easier fix on the libgcrypt side would be:

    at encryption, let it return an error for not-initialized key (no
    setkey called before encryption).

I don't think modification for encryption by ZERO (which was done in
older libgcrypt) should be done to keep (undocumented?) backward
compatibility.

How do you think?
--