Improve opening performance

[J-Jamet]

Optimize unlocking code and decipher implementation to be faster.

Requires refactoring of the code. It is planned to make a module dedicated to encryption with implementation of more advanced unit tests.

[J-Jamet]

I studied this feature and there are two things:

• ~With a better implementation of the Argon2 KDF per native C library, the decryption time is 3 times less than the current one. This is very good news, it will be necessary to test again because some devices may not be compatible.~ It was a difference of emulator, the performances are the same for argon2 with the old code
• Despite my efforts to implement better native C code for AES KDF, I can't get better performance when I know it's clearly possible with other languages (GO for example). But I don't want to implement Go in this Android project because I don't think F-Droid supports its compilation. (Tell me if I'm wrong). So I might do some tests to convert Go code to C but it's clearly experimental). If you are skilled in cryptographic code optimization, don't hesitate to write a message.

[J-Jamet]

I created a Go library to compare and the results are amazing :

• AES KDF with 5000000 iterations, the program goes from 1min20s to 30s on my device.
• Argon2 with 20000 iterations it is less significant, 40s -> 30s but there is a gain

I also improved the code for better encapsulation.

Here is a package compiled with the method of the historical C libraries and the Go library that I designed especially for the derivation methods.

KeePassDX_2.9.15_beta01.zip

Feel free to do a comparison on your devices and tell me if you have any changes. The big problem with the Go library, it is experimental and the compilation cannot be done for F-Droid. But if you don't have any bug, I can implement it for the Play Store versions.

[ghost]

I had the opposite results on my device (Google Pixel 3a). C version is faster than Go version in many cases.

• AES KDF with 50,000,000 iterations, 11s -> 26s.
• Argon2d (Memory:1MiB, Parallelism:2) with 20000 iterations, 86s -> 57s.
• Argon2d (Memory:64MiB, Parallelism:2) with 200 iterations, 28s -> 26s.
• Argon2d (Memory:64MiB, Parallelism:8) with 200 iterations, 13s -> 13s. (C version is slightly faster than Go version)
• Argon2d (Memory:1024MiB, Parallelism:8) with 20 iterations, 14s -> 19s.

[J-Jamet]

Mhhh OK, good to know, thank you for the feedback, I'm going to keep the C version for now. These performance differences are weird, it must depend on the type of processor (ARM / 64 ...) and optimization of the compiler I only tested with a parallelism of 2. I will modify this code later, it is low level so it is not obvious.

[shadow00]

Please make sure that whatever crypto implementation you end up using runs in constant time. Last thing you want is a side-channel vulnerability in a password manager, and rolling your own crypto is the quickest way to get there :cold_sweat:

[J-Jamet]

For the moment I just refactored the code in a module for better visibility and C code is still the method used. I wanted to test the Go to see what would be the gains or losses but there are too many side effects. So don't worry, the proven methods are still the ones used.

Compiling the Go code into machine language is done with a proven open source compiler and uses the JNI to be launched from the JVM. If you have a vulnerability in mind, explain it precisely, it will be useful for the go mobile community.

[J-Jamet]

If you are interested in the Go code, it is very simple and uses only the methods of the libs : crypto/aes crypto/sha256 github.com/aead/argon2

[shadow00]

Oh ok good, I thought you wanted to rewrite the actual crypto implementation.

There are many side-channel vulnerabilities that can affect some cryptographic algorithms. Earlier I was referring to a timing attack: an external process could try to guess the contents of the encrypted data by looking at how long an AES encryption/decryption operation is taking (I mean each single calculation step).

To mitigate this, you have to make sure that the crypto code runs in constant time: each calculation will always take the same amount of time regardless of the content of the data you're encrypting. This can be tricky because compiler optimizations can sometimes introduce this vulnerability even if your code is supposed to be safe.

[chpio]

Somewhat related: can we improve the opening speed for advanced unlocking by storing the result hash/actual encryption key (instead of the password)? Im assuming that it's calculating the password hash via argon2 (or something like that) while "Retrieving database key..." is displayed on the screen, is my assumption correct?

Is there a reason why it's better to store the unhashed password over the hashed password/key? Security wise it should be the same. We already know that the stored password is correct, so it doesn't have a benefit against brute forcing, it just adds a constant delay to each open.

[J-Jamet]

@chpio The advantage of linking only the password to the fingerprint is that it is possible to put a second factor completely untethered. For example, if I have a key file on a USB stick, I have to put the second factor and the fingerprint is not enough.