On 22/02/2011 15:41, Toni Sjoblom - Aventra wrote: > Sorry, the public key size for the 2K was missing from that value. That > explains the 320 bytes difference. > Public key file for a 2K bit key is 270 bytes. Also, some space is occupied > when new files are added as well. Ok.
So 32 2048bit keypairs, w/o certs, requires about 55K (32*(1296+270+180)), leaving about 5k for bookkeeping, labels, etc. This could be a "maxkeys" profile. A more balanced one could account for 14 private keys, 2 public keys and 18 certs (enough if all are issued by the same root CA and there aren't too many different intermediate CAs): (14*(1296+90) + 2*(270+90) + 18*(2048+90)) = 58608 14 private keys so that every key can have a different PIN. But that's a bit more "borderline". When creating more option profiles can I redefine only what's needed (inheriting from "default" the rest) or shoul I redefine all values? > Keep in mind that if you try to optimize the DIR file (CDF, PuKDF, PrKDF..) > sizes to the maximum, it means that you have no space left for other data > objects, e.g. images etc. Yup. That's the target, for now. :) > And also the time taken to read the card increases with large DIR files. This can be bad :( > This is due to the fact that the files are read in chunks over a somewhat > old and slow interface that the standard APDU protocol is. Yup. Chunks <=255 bytes, over a slow serial link. :( > Newer and improved interfaces exist, but are not widely supported/used. Shouldn't that be something taken care of by the driver? > My opinion is > that the profile should be tweaked for each use case, while at the same time > the default profile should be a reasonable compromise between using the > maximum space and no space. I agree that currently the MyEID profile has too > small file. This has historic reasons from a time when the memory size was > limited on javacards. Hope to see soon 1M cards w/ displays and keys :) Jokes apart (well... flexible displays and on-card buttons are already available... hint hint... what's missing is the "big memory"), having some specialized example profiles could greatly help who is tweaking a card for his specific needs, w/o the need to study in great detail how files are used. BYtE, Diego. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
