lists.openwall.net   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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 29 Dec 2016 20:41:07 -0800
From: Tim <tim-security@...tinelchicken.org>
To: Erik Auerswald <auerswal@...x-ag.uni-kl.de>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] [RT-SA-2016-001] Padding Oracle in Apache
	mod_session_crypto


Hi Erik,

Thanks for backing me up on a number of things.  Only one response below.


> > 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
> 
> That is wrong. CBC mode allows attacks such as "Sweet32"
> (https://sweet32.info/), which is not possible with CTR mode.

The site you linked mentioned 64bit block ciphers are vulnerable, even
in CTR mode.  Obviously the birthday "paradox" applies. Regardless of
how right or wrong you are about Sweet32, this far from the most
important thing *implementors* should be worried about.  Obviously if
they start with AES, then the birthday paradox issues are vastly
reduced.  Any new system should be avoiding the likes of 3DES,
Blowfish, etc.  So it seems moot.


On the flip side, tell me what the impact is of these two scenarios
where a developer follows *some* of our advice:

(A) They use AES in CBC mode and apply an HMAC to the cipehrtext.
    They actually validate that HMAC before decrypting.  However, they
    fail to use a unique IV for every message.

(B) They use AES in CTR mode and apply an HMAC to the cipehrtext.
    They actually validate that HMAC before decrypting.  However, they
    fail to use a unique IV for every message.


Which is worse?  Obviously (B) fails pretty catastrophically.  (A) is
not great, but at least the plaintext isn't nearly as easy to expose
(usually only minor block-level information leaks).  In the real world
I see these kinds of mistakes all of the time.  So be careful of
steering people toward a mode that doesn't degrade as gracefully when
developers make mistakes.  They invariably will do so, unless they've
spent as much time with crypto as you and I.

tim


PS- And to re-iterate, we shouldn't ask them to use any particular
    cipher mode, but instead to use something off the shelf.

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists