4 ms·

I would argue there would still be value in offering simple to use APIs/hard to misuse APIs and separate advanced APIs. If the calls to RNG are becoming a bottl

by lawl 8y ago

I would argue there would still be value in offering simple to use APIs/hard to misuse APIs and separate advanced APIs. If the calls to RNG are becoming a bottle-neck, you can still switch to the advanced API. To me that seems like premature optimization.

zrm 8y ago
Calls to the symmetric encryption function typically are the bottleneck. It's optimizing the thing known to actually be the bottleneck in the majority of cases. Moreover, RNGs require internal state to prevent giving the same random numbers twice, so in this context it's just a slower counter that would still introduce locking.
- lawl 8y ago
  They might be the bottleneck in things where the load is crypto heavy sure. I was more talking about a case where a developer would like to add crypto to their chat application or whatever where the amount of crypto being done is so low it shouldn't really matter.
  - zrm 8y ago
    That's always the trouble. Nothing is optimal for everything but you don't want a different API for every possible combination. Particularly in a case like this, you would end up with two APIs, one that takes an immutable state plus a nonce and the other that takes a mutable state that is really the immutable state plus the nonce which it increments for you, with the separate question of whether it handles the locking for you or not (note that not all platforms even have threads). They're so similar that having both is confusing, but if you're to have only one then the applications that need good performance (which are common) want the one where the caller supplies the nonce, as does anything else that may need visibility into that, e.g. if messages are sent from more than one process or device. Moreover, the performance implications creep up on you. You don't expect it to matter for your chat app until you start letting users attach files to messages and suddenly you're encrypting 10GB files instead of 10 byte messages. Then you start losing users to apps that use faster encryption, or worse, no encryption.

by lawl 8y ago

zrm 8y ago

Calls to the symmetric encryption function typically are the bottleneck. It's optimizing the thing known to actually be the bottleneck in the majority of cases. Moreover, RNGs require internal state to prevent giving the same random numbers twice, so in this context it's just a slower counter that would still introduce locking.

lawl 8y ago
They might be the bottleneck in things where the load is crypto heavy sure. I was more talking about a case where a developer would like to add crypto to their chat application or whatever where the amount of crypto being done is so low it shouldn't really matter.
- zrm 8y ago
  That's always the trouble. Nothing is optimal for everything but you don't want a different API for every possible combination. Particularly in a case like this, you would end up with two APIs, one that takes an immutable state plus a nonce and the other that takes a mutable state that is really the immutable state plus the nonce which it increments for you, with the separate question of whether it handles the locking for you or not (note that not all platforms even have threads). They're so similar that having both is confusing, but if you're to have only one then the applications that need good performance (which are common) want the one where the caller supplies the nonce, as does anything else that may need visibility into that, e.g. if messages are sent from more than one process or device. Moreover, the performance implications creep up on you. You don't expect it to matter for your chat app until you start letting users attach files to messages and suddenly you're encrypting 10GB files instead of 10 byte messages. Then you start losing users to apps that use faster encryption, or worse, no encryption.