Hmmm. forgot to respond to this part in my earlier mail.
--On Monday, November 13, 2006 11:56:13 PM +0100 Andreas Jellinghaus
<[EMAIL PROTECTED]> wrote:
so if t=1 shouldn't be a problem and cryptoflex does both
t=0 and t=1 I think
I do not think cryptoflex supports T=1. certainly, its ATR does
Chaskiel M Grundman wrote:
--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 us
--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 pro
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
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 proc
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).
Wh
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 r
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 wo
Peter Stuge wrote:
On Sat, Nov 11, 2006 at 05:53:00PM +0100, Andreas Jellinghaus wrote:
if limiting all readers to 248 bytes doesn't hurt anyone, then this
is the best way from my point of view.
But it does hurt. In my case the readers need to go to 256 bytes of
data. Its the old card t
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 fine,
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
--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
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 don
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
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
/usr/home/alex/freeb
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
240
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 s
17 matches
Mail list logo
