There's a single call to getrandom during init for the init CSPRNG. For efficiency, that's used to seed all the others, but it has no use after that and is unmapped. The reason getrandom is called again is regularly reseeding as a minor security boost: github.com/GrapheneOS/har.
Conversation
Originally I started out with caching the output of getrandom directly, but that's at least an order of magnitude too slow even with the system call cost amortized. Even the current optimized scalar ChaCha8 implementation with highly optimized random range generation is too slow.
1
Replying to
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.
2
3
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.
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
Show replies