Closed PS6 closed 2 years ago
I don't experience this issue with my Ed25519 keys. I generated them with PuTTYgen.
I am not 100% sure, but I have a vague suspicion, the -a 123
may cause this slow down here. According to man page of ssh-keygen
this is a counter for the rounds a key derivation function (e.g. bcrypt
is applied to encrypt/decrypt the private_key with help of a password. This helps to slow down brute force attacks.
But the 100
does not seem to be the number of rounds, but more a cost factor - where the concrete rounds may be far higher than this. Compare https://security.stackexchange.com/questions/17207/recommended-of-rounds-for-bcrypt
Since the rounds will be applied on each single decryption, this feature has the potential to slow down KeeAgent. I'm not sure, how often KeeAgent decrypts the keys or if it has some means, to cache info like fingerprint, after first access. But the more keys are loaded, the more slow down will happen.
As written, this is just an yet unconfirmed assumption. Anyway it might help to not use the -a 123
and just rely on the implicit defaults.
Didn't notice the problem being my new ED25519 key but had the same problem myself and even falsely opened a bug with Keepass2-core. Just found out about it and yes, my new ed25519 key is also one with an additional "-a" parameter set (-a 100 I think it was).
My main problem was auto-typing slowing down to a crouch: every autotype had a 5-6s pause before starting and as I also updated Keepass with KeeAgent it never occured to me it could be the key that's the problem. Removing it from KeeAgents selection and loading speeds up the thing again.
I don't understand how/why KeeAgent is being triggered by an autotype event (why does that need to trigger keeagent and why does it "decrypt" the key again if it IS already opened an in RAM?) nor why it has to touch it at all as it's loaded into RAM and even with all options for removing it disabled (I checked it is still listed even after locking etc.) it still slows down everything. So somehow a ed25519 key with many more KDF cycles seems to drag down performance of the plugin significantly.
If there's anything to help, let me know. As far as I'm going to openssh doc of ssh-keygen, the default of "-a" is 16, so my 100 would be 6,25x of the default. If that one key with high KDF count drags it down so much, multiple ones could be a real PITA.
Cheers, Jens
I can confirm this issue. Since I added a few -a 64
keys, autotype is really slow. Observations:
.pub
file is attached.Probably, keepass iterates over all enabled entries enabled for autotype (potentially including keys) and "opens" each of them, i.e. gathering all data, including the pubkey / comments etc.
I have made some changes that should fix this specific issue as well as show progress bars while the keys are being decrypted. There isn't a proper beta release yet, but you can download the latest build from CI: https://github.com/dlech/KeeAgent/suites/6415298584/artifacts/234029997
Don't forget to backup your .kdbx file before trying this.
should be fixed in https://github.com/dlech/KeeAgent/releases/tag/v0.13.1
When using a Ed25519 key with KeeAgent autotype slows down by around 5 seconds per lookup. I created a new Ed25529 key with ssh-keygen -t ed25519 -a 123 -C "a-new-key" (in a docker) created long random string in new entry in KeePass and pasted this as passphrase for key added key in attachment with key.txt and internal editor activated KeeAgent on KeeAgent tab restarted KeePass and key became active however from that moment on all Global AutoTypes suddenly took around 5 seconds each longer deactivated KeeAgent for the entry and restarted KeePass and the autotype was back to normal