weak key used for an Initial Vector

Denis Corbin dar.linux at free.fr
Thu Aug 6 22:33:58 CEST 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I need an advise on the following:

I've found googling that it was possible to disable the weak key warning
thanks to the PRIV_CTL_DISABLE_WEAK_KEY value given to gcry_cipher_ctl()
call.

My questions are:
1 - Is using weak blowfish key to generate an Initial Vector for another
key/algorithm is really a security issue?
2 - Will the PRIV_CTL_DISABLE_WEAK_KEY directive/feature stay available
for future evolution of libgcrypt? Or it this a pure debug temporary
feature?

For more details on the context in which I ask these questions:

A software I maintain is relying on libgcrypt to provide strong
encryption. The user provided password is hashed
(accordingly to pkcs #5). In the event this hash is reported as weak by
libgcrypt no problem, it's still possible to propagate the message to
the user, asking for a better password...

- From that hash of the user provided password a SHA1 digest (8 bytes)
is created to set a second key (using blowfish cipher).

The data to be ciphered/deciphered is provided associated with a number.
First this number is encrypted by the second key to setup an IV for the
first key.
Then the data is ciphered/deciphered with that first key.

Due to the exiguity of the SHA1 digest (8 bytes), sometimes libgcrypt
reports the digest as a weak key and fails. As there is possibly many
blocks of data already encrypted and more to encrypt, I cannot as the
user to change the password... possibly he has already produced several
terabytes of data and already waited for hours so far... where from my
questions.

Cheers,
Denis Corbin.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIVAwUBVcPEtQgxsL0D2LGCAQLIvw//fH9uN/l3sN2y+v2CjQlkejeqnt7A2C+9
wZgcs7lOvnS4kBDY4LN0iTWwNbiVGxmXasQpcuBlA/palDZRLxI+1ANZlgpWOs3H
OtdMR4HJhWqz3dTsWvbhkUmey9mqMsyIfPFnO3yV4txdBJoqLAA5hCrUQlG0Dl/P
nnQpZr8hPoJQcq6JGfkwGlGco+o71LPeab+irDKkNrqSdIFa66eZ54t//L/0+GGZ
l0Xct7m1xgze2fXqOhPJlJ8Bbc96FC3B/MBXaTy7E3Cgx4lERWKdMIIROfUsYp7d
qk8C5lOXNi2KRz9rlBNZNofe/hFzIAyr2COU/iVLFKt7SLn3qYVaVhu/EMgl9Ii1
AtWw3oB4WjDcgeGrBVJnOiQSOZL8sL1MYMv6tDirVewy+hS1BrSxkVH/Bu+bWxuO
X0F54STqIFESWy4ezFvAcagFxg0WRf/m5aDCpEw39nTEBfKZ9UiA62KnolLmp644
KOIl8F3aW0BIcxN1yPcNqQsdRwIUluhgYlRJdVmNjpKjQXGNQ1zlxiZNi3mdYyy5
pqI1gy14OZ1HFLD2RG9tYvJPGj+318t5XzmL/uxAVum+eeoUVpSWWEweisq6euoc
NrQCw251rU/bELT2O8/lzgRxABE9DctK1oCv/wx7kT0Djg5zMQ0V11e7Jk2LKtnI
SGeiIKGb+g4=
=fCh9
-----END PGP SIGNATURE-----




More information about the Gcrypt-devel mailing list