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