In the exported JSON there is "n: 32768" which I assume is the number of KDF iterations? Why not increase it to 100k+?
There is no need to make assumptions. This is all documented.
How did you come up with 100k? N is the work factor of scrypt. It must be a power of 2, so the closest to 100k would be 2^17. With that value, key derivation would use at least 128 MiB of RAM. Most Android devices set a JVM heap size limit that's lower than that, so we can't increase N currently. That may change if we start using libsodium instead of the Java implementation of scrypt.
No response, so closing this issue. I think @aliatiia assumed we were using PBKDF2, and thus recommended a number of iterations suitable for that algorithm.
The KDF parameters we're using are fine. If there is an opportunity to increase the work factor (without also causing crashes on low-end devices, see #114), we'll take it. We may be able to do so after #302.
Most helpful comment
There is no need to make assumptions. This is all documented.
How did you come up with 100k? N is the work factor of scrypt. It must be a power of 2, so the closest to 100k would be 2^17. With that value, key derivation would use at least 128 MiB of RAM. Most Android devices set a JVM heap size limit that's lower than that, so we can't increase N currently. That may change if we start using libsodium instead of the Java implementation of scrypt.