Bug 524403 Comment 66 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

OK, I've been on vacation, so I didn't have a chance to short-circuit a lot of the performance issues. 
I had performance in mind when I did the initial patch. It does a couple of very deliberate things that mitigate the performance costs:
1) null passwords are encrypted with a small iteration count.
2) when we check for a null password, we fail if it doesn't have a small iteration count.
The pbe generated by the password is cached as long as you are logged in, so you only pay the price on login.

This means in Firefox, the only time you should see the slower performance is when you have the password prompt. There will be a longer delay between the time you check the password and Firefox 'does something else'. For startup, even those of use with a password on our data base, the first page loads without a password prompt.

This does effect the NSS automated tests because they run lots of small tests that all need a password to continue. This means a huge cost when running the tests. (so it makes sense that we would use a small count just for the tests, with maybe a could tests without the small count to make sure the basic code is working correctly)

> Kai, Bob, is there any hope of moving to PBKDF2? I don't care about the triple-DES part as much, but that isn't superb either.
I need to look at that anyway for FIPS. The basic code is there, but we do need to make some tweaks to make it work. I think I had the same issue where I could make sql forward compatible, but not dbm (though that's a smaller patch). I think we should handle that as a separate bug to this one, though.

bob
OK, I've been on vacation, so I didn't have a chance to short-circuit a lot of the performance issues. 
I had performance in mind when I did the initial patch. It does a couple of very deliberate things that mitigate the performance costs:
1) null passwords are encrypted with a small iteration count.
2) when we check for a null password, we fail if it doesn't have a small iteration count.
The pbe generated by the password is cached as long as you are logged in, so you only pay the price on login.

This means in Firefox, the only time you should see the slower performance is when you have the password prompt. There will be a longer delay between the time you check the password and Firefox 'does something else'. For startup, even those of use with a password on our data base, the first page loads without a password prompt.

This does effect the NSS automated tests because they run lots of small tests that all need a password to continue. This means a huge cost when running the tests. (so it makes sense that we would use a small count just for the tests, with maybe a could tests without the small count to make sure the basic code is working correctly)

> Kai, Bob, is there any hope of moving to PBKDF2? I don't care about the triple-DES part as much, but that isn't superb either.

I need to look at that anyway for FIPS. The basic code is there, but we do need to make some tweaks to make it work. I think I had the same issue where I could make sql forward compatible, but not dbm (though that's a smaller patch). I think we should handle that as a separate bug to this one, though.

bob

Back to Bug 524403 Comment 66