lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 27 Dec 2016 09:01:49 -0800
From: Tim <>
Subject: Re: [FD] [RT-SA-2016-001] Padding Oracle in Apache

>  > res = apr_crypto_passphrase(&key, &ivSize, passphrase,
>  > strlen(passphrase), (unsigned char *) (&salt), sizeof(apr_uuid_t),
>  > *cipher, APR_MODE_CBC, 1, 4096, f, r->pool);
> CBC. Again.
> The earliest mention of CFB which I know is dated 1989.
> The earliest mention of CTR which I know is dated 1990-ies.
> But there still are people who use CBC...
> Please, PLEASE, PPLEEEEAASSSE don't use it. Instead, use either
> Blowfish in CFB mode or at least Rijndael (AES) in CTR (or GCM)
> mode - both are available, for example, in the OpenSSL library.

All traditional modes that lack integrity protection are vulnerable to
chosen-ciphertext attacks in these kinds of scenarios.  CFB isn't
immune and CTR is catastrophically weak.  All traditional modes need a
MAC or similar integrity protection.  In light of that, there's
nothing particularly wrong with using CBC, if it is implemented well.
At least, using it is not *more* wrong than using OFB, CFB, or CTR
without integrity protection.

GCM is fine if the implementation is sound and the IVs never repeat,
but there are pitfalls.  We should instead be pointing developers in
the direction of using something off-the-shelf, such as libsodium.
Much less room for error.


Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists