From: Ludovic R. <lud...@gm...> - 2020-02-09 17:37:13
|
Le dim. 9 févr. 2020 à 18:13, Marian Ďurkovič <md...@bt...> a écrit : > Thanks for the info - yes, ATR is exactly as mentioned above. > > It's quite strange, since there is very little difference in response times for common functions regardless of result size: > - C_GetAttributeValue for CKA_ID (i.e. just a few bytes) takes 571 msec > - C_GetAttributeValue for CKA_VALUE (2048 bytes certificate) takes 580 msec > - C_FindObjectsInit+C_FindObjects also takes 576 msec This indicates that the card/reader communication speed is not that important. > Any tips what to look for (on MAC)? I would have suggested to use PCSC API spy to get some timing information https://ludovicrousseau.blogspot.com/2011/11/pcsc-api-spy-third-try.html But that will not work on macOS. > The above is a serious problem with some applications - for example signing a document in Acrobat results in 2.5 minutes of waiting, since after C_Sign completes, Acrobat tries to verify the signature and pulls all 3 certificates from eID 6 times (once for each level in certification hierarchy). > > Perhaps I should try to modify pkcs11-spy.so into a caching library, serving repeated requests for static objects from memory cache and not from slow eID card... You can use pkcs11-spy to know what functions are used. Maybe pkcs11-spy could be updated to include the *duration* of each PKCS#11 call so it is possible/easy to identify the slow functions. Have you tried to play with the "use_file_caching = " parameter of OpenSC in /usr/local/etc/opensc.conf ? See opensc.conf manpage. Bye -- Dr. Ludovic Rousseau |