What are "transform rounds" in KeePassXC?
What are "transform rounds" in KeePassXC?
I apologize in advance if this is the wrong community for this post. If so, please point me in the right direction of where I should post this.
I'm thinking of trying out KeePassXC, and, when creating a new database, I came across the following settings:
Some of this is somewhat self explanatory to me ("Encryption Algorithm", and "Key Derivation Function"), but some of it not so much -- namely, "Transform Rounds" (I'm assuming that "Memory Usage", and "Parallelism" are more specific, not to the database on the whole, but, instead, to the decryption itself within the app, or, maybe, even just for the benchmark). What exactly is "Transform Rounds"? Does it mean that the passwords are encrypted over, and over again, in attempt to protect against dictionary attacks? I haven't been able to find any concrete information.
Those last three input boxes are all parameters to fine tune the operation of the key derivation function, they control the performance and hardware usage characteristics of how to derive the actual database encryption key from your password in order to make it harder to brute force.
The Transform Rounds input essentially controls how much sequential processing power is needed by repeating a specific part of the KDF more or less often, and thus allows you to determine how long the key derivation will take every time. That's why there's a Benchmark button next to it - it will automatically test on your CPU and determine how many rounds are needed to produce a 1 second delay on your hardware. Which is an acceptable time to wait for your database to unlock, but bad news for someone trying to brute force your password, as it limits how many different passwords they can test in a given time.
Memory usage controls the amount of memory the KDF needs, and Parallelism controls how many parallel threads are used, both limiting how many parallel attempts at brute forcing your password a potential attacker can run on any given hardware.
Disclaimer: I'm not a security expert, just a software developer who has come into contact with KDFs quite a bit. If I misrepresented anything above, happy for correction!
Great answer, it is similar to the cost parameter for bcrypt/scrypt and iterations for PBKDF2.
Considering the API/experience is quite different (with its own nuances) in the fediverse, the idea to create an app from scratch was a good idea. Copying and pasting UI code and framework from Sync aside. Especially when the platform is being improved to handle some meaningful load/traffic right now and is clearly needing further development - he's got time. We are already week 4 of a 3-6 week estimate, and he's teasing us with some very nice screenshots already. Reddit gave very short notice of the API changes, and they then carried them out. Ultimate subscribers leaving in droves, sadly. Even with the choice he was just making about usernames, it's clear to me that he's been putting a lot of attention to detail in the first appearance of Sync for Lemmy. Everything is important when it comes to being a class leader, there is nothing more important than setting the example that others follow or copy. When other developers come into your Lemmy community and try to snipe users so blatently as what has happened - is it any wonder he's wanting perfection!
It's about sending a message. He's clearly wanting to show these other android developer noobs how it's done.