Bugzilla

The reason is there are two password here. There a lightly obscured version of the UTF8 password created by a single hash. That password is cached after login. Then there's a password for each entry in the database. That password is a strong password based on a unique salt and iteration count in each entry.

There are good reasons for having each entry have it's own key. There may be arguments for making the cached password a strong pbe and using a weaker iteration count on each entry. That would really require a database update to a new version number since it would be impossible to do that in a way that older versions of NSS could still work.

That said, adding an API to separate getting the SDR key and then using it would be quite easy. In the SDR case, there is just one key (it's one database entry). Applications could then just hang onto the SDR key if they want and use it when they decrypt.

Even if we did that, the low level cache is actually a good idea because it not only speed up access to the SDR keys, but it also speeds up access to all encrypted or signed data in the database, so I wouldn't back out the previous change.

bob

The reason is there are "two" passwords here. There a lightly obscured version of the UTF8 password created by a single hash. That password is cached after login. Then there's a password for each entry in the database. That password is a strong password based on a unique salt and iteration count in each entry.

There are good reasons for having each entry have it's own key. There may be arguments for making the cached password a strong pbe and using a weaker iteration count on each entry. That would really require a database update to a new version number since it would be impossible to do that in a way that older versions of NSS could still work.

That said, adding an API to separate getting the SDR key and then using it would be quite easy. In the SDR case, there is just one key (it's one database entry). Applications could then just hang onto the SDR key if they want and use it when they decrypt.

Even if we did that, the low level cache is actually a good idea because it not only speed up access to the SDR keys, but it also speeds up access to all encrypted or signed data in the database, so I wouldn't back out the previous change.

bob