Andreas Jellinghaus wrote:
> lets test first, if it doesn't work...
test what ? If we globally restrict the buffer size we
certainly
will have problems with some tokens (etokens pro with 2048
bit keys,
note: cardos m4.2 doesn't have a GET RESPONSE command =>
every byte
that doesn't fit into the return buffer is lost).
>
> in opensc.conf I see we have max_send_size and
max_read_size
> already, but only in reader section. but the ctx.c code
looks
> generic, so we could copy that example setting to
reader openct
> section as well?
hmmm, isn't this a reader problem ... so the reader section
might
be appropriate. Btw: it would be nice to be able to set this
restriction for a certain reader only and not just for the
whole
reader driver.
>
> no further code changes are necessary to test lower
settings?
>
> muscle code needs to be fixed I guess: it sets
max_send/recv_size
> without looking at the old value. I guess most readers
won't like
> 64k transfers.
>
>> I don't like this ... for example the result of a
2048 bit rsa signature
>> generation returns a 256 byte signature and hence
restricting the max
>> receive size to 248 makes it complicated to read
the signature with T1
>> card.
>
> does our code already handle this? a number of cards
has max send size
> bellow 255 bytes, but not sure if they support 2048 bit
key sizes.
I already tested 2048 bit rsa signatures with an etoken pro
using openct so at least it seems to work for cardos.
Cheers,
Nils
_______________________________________________
opensc-devel mailing list
opensc-devel lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel
|