Repository navigation
crypto.timingSafeEqual is not really time safe? #17178
Description
Activity
See #3043, #3073 and #8040. The current behavior is the product of a stupefying amount of discussion. I think it's unlikely we'll revisit that.
As well, your suggestion is a subtle change in behavior. Too subtle, IMO - it might end up breaking applications in ways that go undetected until it's too late. That risk alone practically rules it out.
Reacted by Elay GliksbergGenerally a comparison function that is resistant to timing attacks is used to compare signatures or hashes, which should be the same length by virtue of being generated by a hash function. If you are accepting a user-provided signature and want to compare it in a safe way, it's OK to check the length first and return early, e.g.
return a.length === b.length && timingSafeEqual(new Buffer(a), new Buffer(b)). This doesn't reveal any information about the contents that would aid a typical attack.See https://codahale.com/a-lesson-in-timing-attacks/ for more details (which also does a length equality check).
Reacted by Nicholas Sherlock, Markan Patel, Linus Unnebäck, João Ferreira, David Perrenoud, Eli Grey, Jacob Hoffman-Andrews, Mitko, jaylattice, Anna Henningsen and 16 moreLength checks are timing safe, because they do not depend on time.
Reacted by Pedro Paulo Amorim and Gabriel PérezReacted by Pedro PedruzziReacted by Pedro Paulo Amorim and Gabriel Pérez
After trying to use
crypto.timingSafeEqualwith two buffers that have different length I've got an exception.I read the docs and realized that
crypto.timingSafeEqualis supporting only buffers with the same length which is contradicting the concept of timing safe compare.The comparison code:
node/src/node_crypto.cc
Line 6065 in 51e0948
Maybe it's worth to implement it like that: https://github.com/vadimdemedes/secure-compare/blob/master/index.js#L12