[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2165: use bigger random one-time keys, rename to "timing_safe_compare"

[Tahoe-LAFS]

#2165: use bigger random one-time keys, rename to "timing_safe_compare"
-----------------------------+-------------------------------------
     Reporter:  zooko        |      Owner:  daira
         Type:  enhancement  |     Status:  closed
     Priority:  normal       |  Milestone:  1.11.0
    Component:  code         |    Version:  1.10.0
   Resolution:  fixed        |   Keywords:  cleanup security timing
Launchpad Bug:               |
-----------------------------+-------------------------------------

Comment (by warner):

 BTW, looking back at it, I don't believe the os.urandom is necessary at
 all. {{{hash(X) == hash(Y)}}} is sufficient, as long as the attacker only
 gets to submit "X" and not {{{hash(X)}}}. To learn the first byte of
 {{{hash(Y)}}}, they must create 256 Xs (where each one has a {{{hash(X)}}}
 that begins with a different value), at a cost of about 256 trials. Then
 they can do the usual timing attack with these 256 strings. But, once
 they've learned the first byte of {{{hash(Y)}}}, then to learn the second
 byte, they must build a new set of 256 Xs (where they care about both the
 first and second bytes) at a cost of {{{256^2}}} trials. This gets
 exponentially worse as they try to test more bits, because they can't
 cheaply control the output of {{{hash(Y)}}}.

 Of course these days I'd use {{{HKDF(X)}}} instead of {{{SHA256(X)}}}, or
 maybe HMAC or SHA256d.

 I believe there's a different construct in which the random value is
 important, but not hash-vs-hash.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2165#comment:11>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage