As per the conversation on this Pull Request
https://github.com/php/php-src/pull/909#issuecomment-71077928
What functions are involved in real world PHP applications (frameworks,
popular CMSes, etc) that operate on encoded encryption keys that might
benefit from having a timing-safe implementation?
So far, I can identify:
-
bin2hex()
-
hex2bin()
-
base64_encode()
-
base64_decode()
-
json_encode()
-
json_decode()
-
parse_ini_file()
I think it would be great to compile a master list of which functions are
commonly used to store long-term encryption keys (random bytes that could
cause parse errors).
Also, would it be better to use a prefix (e.g. ts_*), a class with static
methods (e.g. TimingSafe::bin2hex()), or functions in a namespace (e.g.
\TimingSafe\bin2hex())?
Scott
P.S. At this point, I'm also withdrawing my participation of this
discussion. If you don't think it's worthwhile to fix this, that's your
decision. I've had some major life events happen and I no longer have time
to debate this. Thanks for understanding.
Hi all and Scott,
This mail is for all mostly.
On Fri, Jan 23, 2015 at 10:37 AM, Scott Arciszewski scott@arciszewski.me
wrote:
As per the conversation on this Pull Request
https://github.com/php/php-src/pull/909#issuecomment-71077928What functions are involved in real world PHP applications (frameworks,
popular CMSes, etc) that operate on encoded encryption keys that might
benefit from having a timing-safe implementation?So far, I can identify:
bin2hex()
hex2bin()
base64_encode()
base64_decode()
json_encode()
json_decode()
parse_ini_file()
I think it would be great to compile a master list of which functions are
commonly used to store long-term encryption keys (random bytes that could
cause parse errors).Also, would it be better to use a prefix (e.g. ts_*), a class with static
methods (e.g. TimingSafe::bin2hex()), or functions in a namespace (e.g.
\TimingSafe\bin2hex())?
To perform timing based attacks based on conversion functions, attacker
must
be able to get correct secret timing for statistical analysis.
(I'm assuming key comparison is constant. PHP user must use hash_equals()
to achieve this)
This situation may seem unlikely, but attacker can observe HTTPS
request/response
time (i.e. wiretap) and guess which one is the request that has secret.
(request size is useful for this, for example.) Then attacker sends guessed
secret
to server. Attacker may analyze guessed secret candidates locally since
algorithm is known to attacker. It's better guess than without clue.
Users may eliminate the risk by not having conversion at all or mitigate
the risk by
having large random variable length secret, I suppose. (Please correct me
if I'm wrong)
-
bin2hex()
-
hex2bin()
-
base64_encode()
-
base64_decode()
-
json_encode()
-
json_decode()
These are candidates to be timing safe. mb_convert_encoding()
may be
used to base64 encode/decode, so it's a candidate also. There are others
like uu encode,
url encode, etc.
-
parse_ini_file()
I'm not sure if it is vulnerable. Aren't values copied simply? (i.e.
constant time)
It may not be timing safe due to parse.
There are many conversion functions, some of them are complex. Why don't we
make time safe bin2hex/hex2bin only and advocate users to use them for
secret
data conversion? All of these are better to be timing safe, but it is not
feasible, is it?
Please note that we need timing safe binary to text/text to binary
conversion function
for better security because crypto algorithm like AES has binary key. If
text is used,
it reduces effective bits unnecessary.
BTW, compression can help guessing secrets (even worse). It also should be
noted somewhere.
Scott
P.S. At this point, I'm also withdrawing my participation of this
discussion. If you don't think it's worthwhile to fix this, that's your
decision. I've had some major life events happen and I no longer have time
to debate this. Thanks for understanding.
That's too bad.
Thank you for the timing safe bin2hex patch.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net