10 ms·

It does seem very low. However, you shouldn't be passing million-digit numbers around as (decimal) text. Even if you're not at risk of DOS attacks, there's st

It does seem very low. However, you shouldn't be passing million-digit numbers around as (decimal) text. Even if you're not at risk of DOS attacks, there's still the issue that it's very, very slow: $ python3 -m timeit -s "s='1'*1000000" "i=int(s)" 1 loop, best of 5: 5.77 sec per loop A ValueError alerting you to that fact could be considered a service. Contrast and compare: $ python3 -m timeit -s "s='1'*1000000" "i=int(s,16)" 200 loops, best of 5: 1.45 msec per loop

adgjlsfhk1 4y ago
python being slow isn't news. that's not a reason for an error.
nomel 4y ago
> However, you shouldn't be passing million-digit numbers around as (decimal) text This is about numbers that are thousands of digits, not millions. Regardless, why not? What's the alternative that supports easy exchange? If you stick it in some hexified representation, you still have to parse text, and put it into some non-machine-native number container. It's going to be slow no matter what.
- munch117 4y ago
  No, it's not going to be slow no matter what. Didn't you see my example? The hexadecimal non-machine-native textual representation was 4000 times faster than the decimal ditto. On a number that was much larger, I might add. Hex number parsing is linear time.
  - schoen 4y ago
    I could imagine people overlooking that little "m" in your example's output!
    - nomel 4y ago
      Indeed I did!
- blibble 4y ago
  you can convert hex into binary directly without any multiplications
sidewndr46 4y ago
If you're doing cryptography in Python, performance is most definitely not a concern.
- munch117 4y ago
  Sure it is. It's a concern that's addressed by using efficient libraries written in Rust or C. Mostly. One time I implemented RSA in Python. I needed it to read some legacy data with the wrong padding, something which the libraries couldn't (wouldn't) do. It performed just fine. The ternary pow() that does the heavy lifting is not quite as fast as the dedicated crypto libraries, but it was close enough.
  - sidewndr46 4y ago
    In that case, you aren't doing cryptography in Python. You're using cryptography in Python. I'm not just saying that to be pedantic, I've seen some crypto implemented in Python and it is awfully slow. This is the case of most Python code & is why many attempts to compile Python to native code results in slower overall performance.
    - munch117 4y ago
      > In that case, you aren't doing cryptography in Python. You're using cryptography in Python. One of the great things about the Python community is that we don't have these kinds of artificial hangups. You just solve the problem, and if part of the solution involves something that someone wrote in a different programming language, that's fine. Earlier this year, I implemented ECIES in Python. Not a very complicated algorithm, but it still needed to be done. So there is C involved in the underlying EC and AES implementations, big deal, I don't see how that should disqualify my ECIES work from being "doing cryptography".

adgjlsfhk1 4y ago

python being slow isn't news. that's not a reason for an error.

nomel 4y ago

> However, you shouldn't be passing million-digit numbers around as (decimal) text This is about numbers that are thousands of digits, not millions. Regardless, why not? What's the alternative that supports easy exchange? If you stick it in some hexified representation, you still have to parse text, and put it into some non-machine-native number container. It's going to be slow no matter what.

munch117 4y ago
No, it's not going to be slow no matter what. Didn't you see my example? The hexadecimal non-machine-native textual representation was 4000 times faster than the decimal ditto. On a number that was much larger, I might add. Hex number parsing is linear time.
- schoen 4y ago
  I could imagine people overlooking that little "m" in your example's output!
  - nomel 4y ago
    Indeed I did!
blibble 4y ago
you can convert hex into binary directly without any multiplications

sidewndr46 4y ago

If you're doing cryptography in Python, performance is most definitely not a concern.

munch117 4y ago
Sure it is. It's a concern that's addressed by using efficient libraries written in Rust or C. Mostly. One time I implemented RSA in Python. I needed it to read some legacy data with the wrong padding, something which the libraries couldn't (wouldn't) do. It performed just fine. The ternary pow() that does the heavy lifting is not quite as fast as the dedicated crypto libraries, but it was close enough.
- sidewndr46 4y ago
  In that case, you aren't doing cryptography in Python. You're using cryptography in Python. I'm not just saying that to be pedantic, I've seen some crypto implemented in Python and it is awfully slow. This is the case of most Python code & is why many attempts to compile Python to native code results in slower overall performance.
  - munch117 4y ago
    > In that case, you aren't doing cryptography in Python. You're using cryptography in Python. One of the great things about the Python community is that we don't have these kinds of artificial hangups. You just solve the problem, and if part of the solution involves something that someone wrote in a different programming language, that's fine. Earlier this year, I implemented ECIES in Python. Not a very complicated algorithm, but it still needed to be done. So there is C involved in the underlying EC and AES implementations, big deal, I don't see how that should disqualify my ECIES work from being "doing cryptography".