You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the implementation of the functions entropy and read_urandom you chose to call system function abort in case of failure to provide random data.
I don't know under which exact conditions a failure might happen. However, for a library I find it inappropriate to abort the process/application. The application should at least get a chance to handle this situation and to gracefully shut down the application. Yes, it is possible to implement a signal handler, but the library behaviour should be at least documented, so that a developer is aware of this.
Personally, I would prefer a solution where some sort of fallback function would be called in case the system function fails. For example, one could provide an own PRNG - yes, maybe slightly less secure, but certainly better than aborting the process. In addition, a warning message could be written to the log.
The text was updated successfully, but these errors were encountered:
I agree that the current behavior is non-ideal. A better approach is to return an error and prevent accessing encrypted databases if entropy generation fails. Maybe also spam error messages to stderr given the critical security implications of the failure. In practice, entropy generation should never be broken except maybe on emulators or early in the boot of embedded systems.
In my opinion, the best solution would be to avoid pseudorandom number generation altogether by switching to deterministic nonces based on counters or hashes. However, maintaining persistent counter(s) in a simple and efficient way is an unsolved problem in the context of SQLite3 encryption extensions. Hashing the plaintext contents of a database page incurs a small performance hit but would be easy to implement. Replacing the hash algorithm with keyed BLAKE2 (or other HMAC) would be nice as the result could serve as a MAC and nonce for ChaCha20 at the same time (allowing removal of Poly1305, but that would break compatibility).
Anyway, I will modify the code to return errors on failing entropy generation. And maybe consider the fancy HMAC nonces for the next major version of sqleet (if there ever will be one).
In the implementation of the functions
entropy
andread_urandom
you chose to call system functionabort
in case of failure to provide random data.I don't know under which exact conditions a failure might happen. However, for a library I find it inappropriate to abort the process/application. The application should at least get a chance to handle this situation and to gracefully shut down the application. Yes, it is possible to implement a signal handler, but the library behaviour should be at least documented, so that a developer is aware of this.
Personally, I would prefer a solution where some sort of fallback function would be called in case the system function fails. For example, one could provide an own PRNG - yes, maybe slightly less secure, but certainly better than aborting the process. In addition, a warning message could be written to the log.
The text was updated successfully, but these errors were encountered: