Jon Oberheide added the comment:
On a side note, it may be useful to follow the conventions that already exist
in OpenBSD for their timingsafe_bcmp(3):
http://www.rootr.net/man/man/timingsafe_bcmp/3
"timingsafe" may be a more reasonable naming convention that is a bit less
Jon Oberheide added the comment:
Wow, that escalated quickly. :-)
Nick, thanks for keeping things focused and on track.
To recap, the primary motivation here is two-fold. First, folks are using ==
pretty frequently in an unsafe manner when comparing digests, signatures, and
other fixed
Jon Oberheide added the comment:
Sounds good to me, Nick.
--
___
Python tracker
<http://bugs.python.org/issue14955>
___
___
Python-bugs-list mailing list
Unsub
Jon Oberheide added the comment:
Thanks for the feedback, haypo. I've updated the patch to use unicode-internal.
As long as the encode() of the expected non-attacker-controlled digest is not
dependent on the actual contents of the digest, we should be good.
--
Added file:
New submission from Jon Oberheide :
Hi all,
I was informed that the hmac.secure_compare() function added in 14532 is not
time-independent when processing unicode values:
"The function as given is probably not timing independent if the attacker can
provide unicode values. This is becaus
Jon Oberheide added the comment:
> You should explain what you already said: it is not a risk because the
> length of a HMAC is fixed.
Well, that's not entirely accurate. Exposing the length of the HMAC can expose
what underlying hash is being used (eg. HMAC-SHA1 has different
Jon Oberheide added the comment:
Ok, patch v4 uploaded. Only change is the rename to "secure_compare".
--
Added file: http://bugs.python.org/file25414/hmac-time-independent-v4.patch
___
Python tracker
<http://bugs.python.o
Jon Oberheide added the comment:
I have used the name "secure_compare" in the past for such a function. That
said, I don't have strong feelings either way about the naming, so I'll yield
to the others.
--
___
P
Jon Oberheide added the comment:
v3 patch, based on feedback from the review here:
http://bugs.python.org/review/14532/show
--
Added file: http://bugs.python.org/file25262/hmac-time-independent-v3.patch
___
Python tracker
<http://bugs.python.
Jon Oberheide added the comment:
Here's a v2 patch. Changes include checking the input types via isinstance,
test cases to exercise the type checking, and a note documenting the leak of
the input length.
--
Added file: http://bugs.python.org/file25197/hmac-time-independent-v2.
Jon Oberheide added the comment:
> You could rewrite:
>
> result |= x ^ y
>
> as:
>
> result |= (x != y)
You could, but it's best not to introduce any conditional branching based if at
all possible. For reference, see:
http://rdist.root.org/2009/05/
Jon Oberheide added the comment:
> This is not time independent. Is it an issue?
You're correct, the length check does leak the length of the expected digest as
a performance enhancement (otherwise, your comparison runtime is bounded by the
length of the attackers input).
G
Jon Oberheide added the comment:
Here's a v1. Works with both str and bytes types for Python 3.x.
Not sure I'm completely happy with the docs, but I'd appreciate any feedback on
them!
--
keywords: +patch
Added file: http://bugs.python.org/file25186/hmac-time-indep
Jon Oberheide added the comment:
Will do!
--
___
Python tracker
<http://bugs.python.org/issue14532>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jon Oberheide added the comment:
> One thing that could definitely be interesting is to look through the
> code base and example to see if a similar - but vulnerable - pattern
> is used, and fix such occurrences.
Based on some quick greps, I didn't see many internal users o
Jon Oberheide added the comment:
You call it obfuscating, I call it security correctness and developer
education. Tomayto, tomahto. ;-)
Anywho, your call of course, feel free to close.
--
___
Python tracker
<http://bugs.python.org/issue14
Jon Oberheide added the comment:
Ah yeah, I suppose it's not be exploitable in this case due to the challenge
nonce.
However, it might still be a good thing to fix for to set an example for other
hmac module users (internal or external) that might not have the same situ
Jon Oberheide added the comment:
In fact, it'd probably be useful to have a time_independenct_comparison()
helper function somewhere in general.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Jon Oberheide :
The multiprocessing module performs a time-dependent comparison of the HMAC
digest used for authentication:
def deliver_challenge(connection, authkey):
import hmac
assert isinstance(authkey, bytes)
message = os.urandom(MESSAGE_LENGTH
19 matches
Mail list logo
