http://events.ccc.de/congress/2012/Fahrplan/attachments/2235_29c3-schinzel.pdf
No, a random delay is not sufficient. Or, write yourself an extension and mirror the implementations of all these functions. pecl/ts_string or something like that and provide ts_bin2hex() and/or have the extension override the built-in versions if you really want to slow down every instance of these. That's a rather extreme reaction to trying to patch string operations that real-world frameworks use to handle crypto secrets, don't you think? On Wed, Nov 26, 2014 at 9:51 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/25/2014 07:37 AM, Scott Arciszewski wrote: > > I would like to, at the minimum, suggest making the following > > functions run in constant time: > > > > * bin2hex() * hex2bin() * base64_encode() * base64_decode() * > > mcrypt_encrypt() -- requires delving into libmcrypt, which has > > been collecting dust since 2007 and probably doesn't support > > AES-NI * mcrypt_decrypt() -- ditto > > > > This is only the ones I'm aware of; there are probably many others > > that may be used that could benefit from similar enhancements. > > That seems like a lot of functions to artificially slow down. Many of > these exist in code that is quite performance sensitive and not > timing-attack sensitive in any way. If we start down this path then > eventually every string-handling function in PHP would need to run in > constant time and there we would slow down every PHP application in > existence artificially. I don't see this happening. You will need to > find another solution. > > Perhaps it is a naive solution, but as long as you have a crypto-safe > source of entropy, why can't you insert a random delay into the flow > that is vulnerable to a timing attack. I suppose the attacker could > average over many runs to try to account for this added randomness, > but if the potential magnitude of the random delay was far greater > than the magnitude of the operation being shielded then it would take > a lot of observations before the attacker would have any chance of > picking the signal out of the noise. > > Or, write yourself an extension and mirror the implementations of all > these functions. pecl/ts_string or something like that and provide > ts_bin2hex() and/or have the extension override the built-in versions > if you really want to slow down every instance of these. > > - -Rasmus > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iEYEARECAAYFAlR16NYACgkQlxayKTuqOuAh+gCfcFW5mIPYOONp7WV6umwg1Tu1 > r8IAn20lcVHHaBkn9gxKAfYikJAz56Py > =wqOS > -----END PGP SIGNATURE----- >
