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.

Successfully passed first two test vectors on ECDSA signing and verification using secp256k1 curve implemented in pure POSIX bc and driven by POSIX sh.

Yes, it is quite slow even on my nettop and even with GNU bc in the POSIX mode (bc -s): every sign/verify operation takes up to 40 seconds. I thought to maybe create an alternative path to include "native" non-POSIX modexp on the platforms that allow it, but I cannot find any explicit modexp in any bc manual except on FreeBSD.

An alternative path, of course, would be using OpenBSD's bc to compile this library into dc.

And the interesting part is, on OpenBSD's bc, these operations take 3 or 4 seconds at most... even on my slow ARM64 VPS.

My "emergency of emergencies" setup is Nokia T20 tablet + a Bluetooth keyboard + Termux. Not currently running any custom firmware there though. Yet.

9front, Syllable...

Although I'm thinking more of Uxn/Varvara paradigm, where personal computing remains personal and humanly manageable.

bc is surprisingly easy to deal with, even with all the POSIX limitations like one lowercase letter variable/function identifiers and strictly uppercase hex applied to everything if you have set the ibase=16 before.

The only *real* limitation is inability to return multiple values from functions, but come on, you've got arbitrary precision, nothing prevents you from just multiplying the first point coordinate by fucking 2^256 (or 2^100 in ibase=16) and then adding the second one and returning both as a single number...

Shmest

When I was installing OpenBSD on a new VPS and needed to edit resolv.conf before installation, I had no other option but ed. No problem with that.

My TinyECC is 105 SLOC of (bigint-supporting) JS. I wonder whether the bc version will be more or less than that. I lean towards "a bit less".

Ok, dug up my minimal ECC (ECDSA + ECIES) implementation in newer JS (the one with BigInt type support) written 1.5 years ago. Custom modexp implementation included. Now thinking of how to port it to POSIX bc (because bigints really are bc's/dc's specialization). The SHA256 requirement can be temporarily dropped for now, as I really can't think of any embedded system that has bc and doesn't have sha256sum. POSIX AWK can be a glue language for all this.

Just need to find some time to start rolling it.

Oh, and looks like IOTA stopped using Winternitz as well. Brave new fucking world.

No, I'm serious. Which currency is the easiest to implement a wallet from scratch?

According to this list (https://www.susanka.eu/coins-crypto/), only one of the top-20 cryptos, IOTA, uses Winternitz OTS (which is really simple and elegant) and thus only requires SHA-256 (+Keccak-384 for Kerl) to be implemented. All others use ECC. Even Nano is ed25519-based (with Blake2b).

So, for any crypto other than IOTA, looks like the minimum set is: secp256k1 or ed25519, SHA-256, SHA-512 and/or RIPEMD-160 and/or Keccak-256. And base58check for address encoding where it's applicable, of course.

See where the problem is? What would be the chances to put such a wallet onto a, say, Siemens CX75, Samsung B312E or another J2ME-enabled phone? As I said before, if a protocol cannot run on such hardware then it's flawed by design.

It does. https://hoi.st/posts/2024-02-05-busting-stereotypes-ed.txt

Bot farms have become pretty sophisticated and good at disguising fake users as real ones. And with the generative AI, they can even fill their timeline with non-repetitive normal-looking posts until the day X.

Although the big (govt-owned) bot farms usually hire real people and pay them several cents per post.

I wonder how hard would it be to implement all required crypto primitives with POSIX AWK and all networking with nc, optionally with openssl s_client or its substitutes like busybox ssl_client. Imagine a system where you have nothing, not even a working compiler, only a Linux kernel and busybox/toybox binary (so you do have e.g. vi, awk, bc/dc and non-SSL wget and nc). Yet you need to have a crypto wallet. Which currency would you choose to implement it from scratch using only the tools provided within busybox/toybox?

This is not the first extremely naive approach promoted by that particular developer.

Clearly you never had to deal with bot farms before.

One can coordinate multiple accounts to target one particular address to mute it or "report for spamming".

Interesting that busybox dc contains non-POSIX modexp operator | while OpenBSD's dc doesn't. Meanwhile, dc has been excluded from POSIX in favor of bc.

So, my top-5 of current POSIX standards is:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/bc.html

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/od.html

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html

First read as 1024B and thought "well, that's impressive". 1024KiB is easier to achieve.

I'd accept JS answers as valid if they also count the SLOCs required to implement all cryptographic primitives, not throw in a binding to libsodium or something and call it a day.

As someone who pays taxes in Ukraine directly, knowing for sure that I will get zero from the state retirement fund... Not because they go to war or something, but because they get stolen almost immediately. Simple as that. Everyone knows that, no one does anything. We have two enemies here: the state that attacked us from outside and the state that attacks us from inside.