lets test first, if it doesn't work...
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?
no further code changes are necessary to test lower
Andrey Jivsov wrote:
First, it is unclear what number 248 represents. The lowest common
denominator? T=1 adds 4 bytes of headers+checksum, which gives us 252:
still smaller than 255 or 254 that one might expect to see...
if I remember the statistic ludovic did, all readers support at least
Andreas Jellinghaus ha scritto:
This new version only fixes a few minor bugs:
* implement usb reset (Andrey Jivsov)
Only for linux:
cc -Wall -O2 -fno-strict-aliasing -pipe -march=athlon-mp -D_THREAD_SAFE
-o .libs/ifdhandler ifdhandler.o -L/usr/local/lib ./.libs/libifd.a
Hello,
Our OCSP Responder is based on Apache's mod_ssl and uses openssl libraries
to perform crypto operations (i.e. signing the Responses). These days I've
been trying to implement HSM support with the PKCS11 DLL provided by the
crypto device manufacturer (Spain's RealSec).
When searching PKCS11
On 30/10/06, Martin Paljak [EMAIL PROTECTED] wrote:
Hi all,
Hello Martin,
I suggest we try to follow some bits from http://www.divmod.org/trac/
wiki/UltimateQualityDevelopmentSystem and I would like to make at
least two branches for such bigger improvements on opensc-projec.org
svn.
I
--On Monday, November 13, 2006 09:23:06 AM +0100 Andreas Jellinghaus
[EMAIL PROTECTED] wrote:
I have no clue: would that restrict them? i.e. take functionality away?
or would opensc only split one command into several smaller ones and thus
preserve functionality, but add more communication
Andreas Jellinghaus wrote:
+/* need to limit to 248 */
+if (card-max_send_size 248)
+card-max_send_size = 248;
+if (card-max_recv_size 248)
+card-max_recv_size = 248;
+
+
can we put something like this in the generic code for
all cards and drivers? or in the
Andreas Jellinghaus wrote:
Nils Larsch wrote:
well, it depends on whether this is card 'feature' or a limitation
of the card reader.
Card reader - the same card works fine in some readers, not in others.
unfortunatly it is not even detectable via the driver - some ccid
readers work
Alessandro Premoli wrote:
Andreas Jellinghaus ha scritto:
This new version only fixes a few minor bugs:
* implement usb reset (Andrey Jivsov)
Only for linux:
ouch, true. didn't think of that, and noone tested openct
except on linux :(
please test with attached patch and let me know if it
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
Jesus Luna wrote:
Hello,
Our OCSP Responder is based on Apache's mod_ssl and uses openssl libraries
to perform crypto operations (i.e. signing the Responses). These days I've
been trying to implement HSM support with the PKCS11 DLL provided by the
crypto device manufacturer (Spain's RealSec).
sorry guys, I realize I know a lot less than I should know about all
these subjects, so as a result I'm still very confused.
the start of my discussion with chaskiel was this
the scmscr3320 and hp-keyboard appear to have dwMaxCCIDMessageLength
less than 271 bytes. They therefore fail to
Nils Larsch wrote:
I already tested 2048 bit rsa signatures with an etoken pro
using openct so at least it seems to work for cardos.
it also works with openct + ccid driver + cryptoflex 32k egate.
but: only for some readers. for example all scm readers won't
work.
Regards, Andreas
--On Monday, November 13, 2006 11:20:11 PM +0100 Andreas Jellinghaus
[EMAIL PROTECTED] wrote:
currently ignore the first line,
as we don't select t=1 for cards that can do it, and thus run into
problems.
The only case that openct (in ifd_protocol_select) won't use T=1 is if the
default
14 matches
Mail list logo
