Bytes-like object support #143
Conversation
tomato42
added
bug
tomato42
force-pushed
the
bytes-support
branch
from
1463495 to
ece7cab
Compare
tomato42
force-pushed
the
bytes-support
branch
2 times, most recently
from
f6b1e7c to
0b39122
Compare
also stop copying diff-instrumental.py, it's now in master so it will be present when we checkout the base commit
Document what inputs don't work in which python versions
make the bytearray work on pythohn2.6 make multi-byte array.array objects work on all versions
more test coverage for VerifyingKey.from_string, to verify that the alternative inputs can handle bytearray too
document what parameter types don't work for from_der()
and for VerifyingKey.from_public_key_recovery_with_digest()
add support for all bytes-like objects as input for SigningKey.from_der
this is repeating the s[x] three times for every element extracted, use a function for that also decreases number of tests needed for condition coverage
tomato42
force-pushed
the
bytes-support
branch
2 times, most recently
from
b06b4bd to
2f383de
Compare
as extra_entropy can be large, and different type than outputs from either bits2octets or number_to_string, do not concatenate them but rather push them to the hmac one by one don't use six.b(), not needed on py2.6 simplify the chained comparison and remove unneeded else after return in rfc5979.generate_k
tomato42
force-pushed
the
bytes-support
branch
from
2f383de to
e67c663
Compare
tomato42
force-pushed
the
bytes-support
branch
from
e67c663 to
cc5d5ae
Compare
| :return: tuple with decoded 'r' and 's' values of signature | ||
| :rtype: tuple of ints | ||
| """ | ||
| signature = normalise_bytes(signature) |
There was a problem hiding this comment.
In keys.py you didn't normalize the signature, but here you are. A comment about why this is a different case than when signature is passed to the verify function would probably be in order.
There was a problem hiding this comment.
this is because the signature object in keys.VerifyingKey can be any object that the sigdecode can handle. Here it's a byte string, but for sigdecode_strings signature will be a tuple or a list
there is also a comment in VerifyingKey.verify() function:
# signature doesn't have to be a bytes-like-object so don't normalise
# it, the decoders will do that
| sha1.update(data) | ||
| data_hash = sha1.digest() | ||
| assert isinstance(data_hash, bytes) | ||
| sig_raw = sk.sign(data, sigencode=sigencode_string) |
There was a problem hiding this comment.
Did you really want to sign data and not data_hash here (and following?).
There was a problem hiding this comment.
OK, never mind. sk.sign does it's own hashing while sk.sign_digest signs the digest. Not clear to me how sk.sign chooses the hash, but I think that's perl API and now a function you created.
There was a problem hiding this comment.
SigningKey includes the default that's set on object creation (either generation or import), it defaults to sha1, like here:
https://github.com/warner/python-ecdsa/blob/4c92d31dec71c5fe478744d57d332d5ceb255a33/src/ecdsa/keys.py#L221-L222
3 participants
Test for and fix the bugs in handling bytes-like objects in
VerifyingKeyandSigningKey.fixes #135
fixes #144