Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behaviour of sqleet library if call to entropy function fails #24

Open
utelle opened this issue Jun 12, 2019 · 1 comment
Open

Behaviour of sqleet library if call to entropy function fails #24

utelle opened this issue Jun 12, 2019 · 1 comment

Comments

@utelle
Copy link
Contributor

utelle commented Jun 12, 2019

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.

@resilar
Copy link
Owner

resilar commented Jun 13, 2019

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants