Oddbean

Yes it does, but specific to nip44 at the moment. And yes links to the secp256k1 library https://git.vaughnnugent.com/cgit/vnuge/noscrypt.git/tree/include/noscrypt.h#n435 This is a higher-level api that handles the nip44 message structure and MAC https://git.vaughnnugent.com/cgit/vnuge/noscrypt.git/tree/include/noscryptutil.h

i just need the first, and it's not specific to nip-44, it's a standard pub/priv ECDH just that it's X only i will amend my version so i have access to it i already determined that one-shot sender secrets can get 8mb/s throughput on the btcec library, if the math is much the same as the signatures then it's gonna be 32mb/s possible throughput on a noise-protocol style of symmetric encryption (just to repeat, that is with generating a new secret to send with, and deriving the ECDH shared secret to use with whatever (i was using AES-CTR at the time because i was using the schnorr signature of the one-time generated secret as the HMAC)

My ecdh functions are not exposed in the ABI (marked as static) so you won't be able to link to them if that's what you were thinking. I just confirmed that the symbols are unreachable by ld even though they're in the text.

i can literally copy that into my own code in cgo comment blocks and use it that way... i will do this later, thanks for pointing me to it also just maybe to mention, ECDH is an essential function for writing such as a custom noise protocol suite i started poking at making one that uses the SIMD sha256 and x-only signatures a while back, removing the AES and not using chacha20 or whatever, a custom CTR style block cipher stream

> i started poking at making one that uses the SIMD sha256 and x-only signatures a while back, removing the AES and not using chacha20 or whatever, a custom CTR style block cipher stream I'm interested, but I really need to learn more about how to fully test it. If I ever write custom cryptography code, I'd like to get it audited and heavily 3rd party reviewed.

well, they all work the same way, i think... you have your nonce, your shared secret, and there can be another thing... i forget just now... some code that "namespaces" the keystream by protocol... i was using something, i forget now, disregard and anyway, so you hash the concatenation of your nonce and secret, and that is block 0, and then hash that, you get block 1, and that's a feedback cipher oh yes, and then if you do a counter mode, like CTR style, you just hash the nonce and secret with bytes of a counter of some kind (potentially could be a hash chain, for fun, but idk, maybe just 8 bytes of a straight count-up is enough difference between these two styles is the first you have to derive the stream ahead of the messages, and if you get a tx failure midstream, it's gone counter mode can tolerate transmission errors, if you have added an error correction scheme to your data encoding there's really nothing more to it than that, as far as i can tell, and if you can detect a mistake in my procedure, i'm most interested to hear it, but i'm pretty sure that's how it works, and the whole thing is AES uses the Rijndael cipher, which won the competition at the time to become the official AES it's not broken yet but neither is SHA256 and i figure since i have access to a SIMD version i can make a CTR mode with SHA256, using x-only schnorr signatures as the HMAC on each packet, and done, there's your basic sketch of my bitcoin/nostr noise protocol suite

as far as i can understand it, Galois Counter Mode (GCM) which is very popular, despite having repetition after 4gb is a variant of straight Counter Mode (CTR), and then you can add on AEAD which is some bullshit that gives you some kind of hash based signature that "authenticates" the data (via some random new key, usually, sent at the beginning of a transmission or so) and note that when i say "transmission error" with the case of feedback ciphers, where the ciphertext of a block is hashed to generate the next ciphertext, this only applies within the context of a transmission unit, ie, about 1500 bytes or so... so if your data stream has its own error correction then a dropped packet is the same as a mangled packet so long as there is a stream sequence number

ah yes, what i was going to say was GCM differs from CTR in that CTR just uses a set of bytes, 4 or 8 or so, that just counts upwards, in addition to the secret and the nonce GCM changes this up by using a hash chain instead of a simple sequential counter, which spices it up some more, but AES-GCM only uses a 4 byte counter

yeah, i think if i am gonna do an impossible to crack ECDH based encryption scheme it will use a 256 bit GCM style based on the hash of the secret and nonce, so it will have zero repeats within the realms of our current bandwidth requirements, and a 32 bit nonce all of those short bits, like GCM-AES 32 bit counter and CTR's 64 bit counter the ideal is GCM, and the strongest hash we know of to date is SHA256 the others that are trendy these days, like Blake2/2b/3 and ChaCha20 etc make compromises to make them more performant, but if performance is no issue, as it isn't for most hardware now, 64 bit AMD architecture or ARM, or even RISCV, they all have now got SIMD capabilities that mean these hash functions are now cheap and all those bit shavings are not essential sure, support teh old style, for old stuff and low power stuff, i mean really low power stuff, where security is zero if the thing goes dark, but for everyone else...

not sure if you understand how hash chains work... yes, a GCM style cipher you have to generate hash chains, so for message block 10000 you have to do 10000 hashes on the seed GCM is the best design, but the shitty AES standard limits a stream of data on one nonce/secret to 4gb, and i think that should be bigger by now

there is a lot of mystification around the subject of how this stuff works for the most part "finite field" literally means the number sequence of a hash chain, as in Galois Field The hash function is really centrtal to the security of it all, and then second to that is how hard it is to trivially inject a substantial fraction of the seed of a cipher such that you can break the rest, this is a problem both with feedback and counter mode ciphers, but a greater problem with feedback and code book style, and i think the purpose of a GCM style my inclination is to just crank it all up to 256 bits, make 32 byte nonces, to go with the 32 byte shared secret, and use a 32 byte galois field that is derived from the hash of the nonce and secret, i don't see how you can manipulate that, it's way too big numbers, and trivial for most modern hardware to do it