| Newsgroups |
gmane.comp.mozilla.crypto |
| Message-ID |
<[email protected]> |
On 2/19/26 6:31 AM, Andrew Cagney wrote:
> On Wed, 18 Feb 2026 at 16:32, 'Robert Relyea' via
> [email protected] <[email protected]> wrote:
>
>> 2) reusing keys and session objects. After you free a key or session
>> object, that object is placed on a free list because a number of things
>> that you create with the object (like the session or the locks), could
>> be fairly expensive and key creation/destruction can happen quite
>> frequently. This can of reuse can be capped, though we may need to add
>> some machinery to allow applications to cap them.
>>
>> How many freed key structures that are kept around is determined by the
>> maxKeyCount variable in the slot. Unfortunately we currently have no way
>> to set it from the application. It's set based on the token's
>> maxKeySessionCount in it's tokenInfo structure. Typically it's '0',
>> which sets maxKeyCount to 800. Sounds like you would like a call that
>> will set that value to 0 for your tests. That will change the timing of
>> things (since PK11_SymKeyFree() and creating new keys will both take
>> longer), but it would reduce the noise of reuse... particularly lock reuse.
> Thanks for the pointer! I'll just hack my local buil
>
> The code is also churning through a lot of temp symkeys, I wonder if
> it hits the 800 limit.
The 800 is how many keys stay on the free list before NSS starts freeing
the keys. It would take quite a feat to hit that limit. You need to
create over 800 symkeys and then free them all to hit the limit. Doing
800 cycles is unlikely to hit the limit if you are just creating a
freeing the keys as you go, you just keep reusing that key structure.
bob
>
--
You received this message because you are subscribed to the Google Groups "[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/d4cf759b-ca42-45a5-b242-783774571f90%40redhat.com.