Yes, I use ChaCha8 rather than ChaCha20 because it has much higher throughput and it's still more than strong enough for the use case of probabilistic memory corruption mitigations:
github.com/GrapheneOS/har
ChaCha8 is the same code as ChaCha20 with 8 rounds instead of 20 rounds.
Conversation
Replying to
ah. I'm looking for a cipher fast enough for a 8051. ChaCha20 is just a little bit too slow... though even making it 2x faster would probably not help. all the 32-bit ops really kill the performance
2
1
2
Replying to
I don't think you'll be able to do much better than ChaCha8 or ChaCha12 while still retaining security right now. eprint.iacr.org/2018/720.pdf source.android.com/security/encry is the new disk encryption algorithm for low-end Android devices without AES acceleration based around using ChaCha12.
1
1
Replying to
My understanding is Speck performance is comparable to ChaCha when using a comparable security margin. There was interest in it for Android because it's a block cipher which is easier to use for disk encryption but due to the controversy they figured out how to make ChaCha work.
1
Replying to
but that's on a load-store architecture, right? not on some shitty micro that can only do 8-bit adds against the accumulator and so out of 2k ChaCha20 expands to, 1k is just movs
1
Replying to
Speck has a variable block size and with 32-bit blocks, it uses 16-bit word operations, so maybe that would work better for you. It's going to do half the work compared to using 64-bit blocks with 32-bit word operations though. I'm unsure if that's really going to help you much.
1
1
Replying to
thanks. I'm not sure if it's going to help either. I might just have to actually implement it.
1
it doesn't help that sdcc only does peephole opts so you have to do stupid things like loop reversing manually.
1
Replying to
My biggest frustrating is with hashing. SipHash is too slow for most of the use cases I have for it. ChaCha works for me in hardened_malloc thanks to being able to batch the operations by caching keystream output. SipHash is similar but without having a nice loop doing a batch.
For long keys, SipHash has decent performance. For short keys, especially a single 64-bit integer or a couple of them, performance is horrible. Even for typical strings such as in a hash table keyed by strings, it's horrible. It'd be nice to use it for things like canaries too.