Bugzilla

Thanks. I've done some further testing and came up with peculiar results that possibly point to a different problem with storing rounds in the legacy db being at the root of my slowness here.

I tested this on NSS with these patches in.
Setting it to 500 rounds, opening the legacy password manager (which is the one present in our browser) with about 800 logins stored takes ~ 6 seconds on my hardware. Peculiarly, an unpatched NSS gives about the same access time which is what I got confused about. Of note it's likely a bit faster with the patch since my temp build was 32-bit and my release version I compared against is 64-bit.

Now, changing the rounds to 5000, the time increases to around 21 seconds _without_ (!) re-keying the database. Since the rounds are stored with the records, shouldn't that remain the same? I think it might be using the rounds for a bogus calculation somewhere for each record, because I don't really see how else this would suddenly become significantly slower.
Then, re-keying the database to the new value by changing the MP, the access becomes predictably slower, increasing to almost a minute. If memory serves, unpatched NSS would actually choke harder on higher rounds like this to the point of breaking.

So, I think this what's going on here:
1. The low level caching does seem to make a difference because I don't think 5000 rounds would have been usable before on my size db
2. dbm rounds storage, rekeying and using of the rounds seems to work as-intended, BUT
3. For legacy db, there seems to be a superfluous hashing operation that uses the default rounds set for each access of a login (regardless of what is stored in the db for rounds); that's likely a bug/oversight in the dbm routines using more than one round, somewhere, that causes a big perf issue beyond what would potentially be influenced by db type.

Thanks. I've done some further testing and came up with peculiar results that possibly point to a different problem with storing rounds in the legacy db being at the root of my slowness here.

I tested this on NSS with these patches in.
Setting it to 500 rounds, opening the legacy password manager (which is the one present in our browser) with about 800 logins stored takes ~ 6 seconds on my hardware. Peculiarly, an unpatched NSS gives about the same access time which is what I got confused about. Of note it's likely a bit faster with the patch since my temp build was 32-bit and my release version I compared against is 64-bit.

Now, changing the rounds to 5000, the time increases to around 21 seconds _without_ (!) re-keying the database. Since the rounds are stored with the records, shouldn't that remain the same? I think it might be using the rounds for a bogus calculation somewhere for each record, because I don't really see how else this would suddenly become significantly slower.
Then, re-keying the database to the new value by changing the MP, the access becomes predictably slower, increasing to almost a minute. If memory serves, unpatched NSS would actually choke harder on higher rounds like this to the point of breaking.

So, I think this is what's going on here:
1. The low level caching does seem to make a difference because I don't think 5000 rounds would have been usable before on my size db
2. dbm rounds storage, rekeying and using of the rounds seems to work as-intended, BUT
3. For legacy db, there seems to be a superfluous hashing operation that uses the default rounds set for each access of a login (regardless of what is stored in the db for rounds); that's likely a bug/oversight in the dbm routines using more than one round, somewhere, that causes a big perf issue beyond what would potentially be influenced by db type.