2 minutes 56 seconds to do a single ECDSA verification using busybox bc.

I'm not complaining, just demonstrating that elliptic curve cryptography is *slow*. We don't notice its sluggishness because someone already implemented it in the lowest-level languages available for the platform. We take the underlying complexity for granted and don't even think of what's going on under the hood.

By the way, the fact that OpenBSD's bc does this in under 4 seconds shows that it could be done differently. I wish 95% of programmers were forced to return to CPUs like 6502 or Z80, so they could learn to think in terms of not wasting computational resources.

Reply to this note

Please Login to reply.

Discussion

An elliptic curve has no speed. BC is evidently not the right tool for performing encryption operations directly, _it_ is slow. As you said, it's best implemented in something else and then applied from bc.

I think you're missing the point. Of course, by "ECC is slow" I meant "ECC requires too many elementary mathematical operations to be adapted to existing computer architectures". How many elementary operations are required depends on how well the underlying platform implements bigints and whether or not it also implements modular exponentiation on those bigints.

I naturally thought that, among all the tools listed in POSIX, bc _might_ be the right tool for performing these operations exactly because bigint/arbitrary precision numbers are native to it.

And my point is, whatever requires less operations with bigints or just not requires them at all will be naturally faster on any platform. Busybox bc is just an extreme example to prove this point.