Topic: Nested ECC - A new hash algorithm with tremendous benefits? (Read 86 times)

Do you mean Cebulka forum?



Yes, it uses GPG for signing in, but I don't know if the code for that extension is available anywhere. I guess it may be their custom code, even if it uses common tools, like GPG, which are Open Source, the whole integration with phpBB may be proprietary.

Congratulations, you just invented brainwallet. And it is easy to break, see: https://privatekeys.pw/brainwallet/bitcoin/1
And if you have x-only-pubkey, then you can basically use P2TR as your address type.

I wonder, what this topic is really about. Because after reading that sentence, I thought about something like "mining vanity public keys".

Well, you can store public keys in the database, and users can sign in by signing a specific message (or better: post signed messages directly, without dealing with the "sign in" concept at all). However, those keys should be randomly generated, and not just some brainwallets. Or: you can have a random key with a passphrase, stored on your local computer, if you really need any "password" field.

Why don't you just use existing implementation from Bitcoin Core or Electrum? There is a way to set the password, and from a single seed, you can create all keys. So, the only thing you need, is to export your public key, and use it to handle "The Regular Website" by using even classical "Bitcoin Signed Message" (or better: handle BIP-322 properly; but it is the song of the future, since even Bitcoin Core is missing the full GUI-based implementation there). In the past, I even saw some pages in Tor, which used GPG keys with RSA to do that, so some implementation for existing forum engines like phpBB is probably somewhere, and it may be a matter of just switching the algorithm from RSA into ECDSA.

A new hash algorithm?

All right, this may be more cryptography than Bitcoin, but bear with me. Doin' some thinkin'.

After one new huge public release after the other, we see salts and many rounds of hashing using good old hashing algorithms such as PBKDF2-SHA512; NIST even promotes some of the methods.

Got half an hour to kill? Read this straight from the mouth of the horse, the scientific primary literature.

Nested Elliptic Curve Cryptography (NECC) - My suggested solution

Pick a random number. That's you private key. Rather: have a computer pick one for you, as we human suck as large numbers.

According to Secp256k1, the large integer can be anything between 1 and 115792089237316195423570985008687907852837564279074904382605163141518161494337. It is a very large number indeed.

I prefer Python to do it for me, and I don't mind hexadecimal annotation:


You could produce the same end-result with a one-liner in bash:

.
No need to go online at any state of keypair or wallet generation!

The use case I had in mind was not cryptocurrencies, but I'd love your comments on it.

"The Regular Website" need a database with both usernames and passwords hashed. The problem with SHA1, SHA-256 or even fancier stuff like bscryp, script or PBKDF2-SHA512 so secure store use and store user credentials - and hope and pray these are never leaked. Not good for "The big website" nor for the user, as we have seen in numerous hacsks over the past years. (More that 97% in "haveibeenpwnd" has been reversed. Not good.

So, what is a cood hashing method in 2024? SHA256 for storing passwords is Stone Age.

• It should be "expensive" for both CPU and memory
• It should be intrinsically slow; the fastest rigs in the universe should be able to check one (1) in a second); not millions per second               
  
• No immediate gains when using GPU (clusters)

So, allow me to introduce Nested ECC! Pseudocode below:


Repeat the last steps as needed; a trade-off between computational demands and user experience. n(lopp)=1,024 is where I would begin.

See what I'm doing there?
1. Using one cryptographically secure RNG to roll the dice
2. Treating the random number as a private key; all as defined by Secp256k1
3. Looking up its corresponding public key coordinate (X,Y), discarding everything that's not X (yes, Y is wholly omitted, even its sign)
4. Backfeeding the new "X only" to step 3 in a loop (1,000 rounds?)

Since ECC is so much more CPU and memory-intensive than the good old SHA family, I think we have something for future webmasters and TLS-issues (to begin with). Instead of nesting SHA256 or the like, we are jumping back a fort between private and public keys on Secp256k1—until we, and only we, know where we started.
,
You could (should?) be perfectly open about what cryptographic methods you use. Let's say the worst happens, and your user/pass database is in the wild. How bad is it? It's not like a bot army could fire up Hashcat and have a stab and your ned mystery hashes.

Let me hear from you, crypto-wizards! Something in me that got you thinking of one or two ideas in crypto design. Am I right?