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