Hi Renato,
On Mon, Feb 11, 2008 at 03:52:12PM -0200, Renato da Silveira Martini wrote:
> But, if my card does not have an on-board key generation
> facilities, if my card is no-PKI,
If your card can't do public key crypto OpenSC isn't very useful.
> the OpenSC's pkcs15-init send to us some "war
Alessandro Premoli wrote:
>> Yes, this is what I mean: they *must not* be encoded, so that the
>> shortest possible representation results that still allows to
>> differentiate between positive and negative numbers.
>
> Ok, we agree. Sorry if my first message seemed a bit rude.
>
>> P.S. A coup
Hi All--
Many apologies for sending this message to the list, but I'm
looking for help unsubscribing and other avenues have failed. I've
tried to unsubscribe via the web page at:
http://www.opensc-project.org/mailman/listinfo/opensc-devel
5 times, each time getting the confirmation ema
> Yes, this is what I mean: they *must not* be encoded, so that the
> shortest possible representation results that still allows to
> differentiate between positive and negative numbers.
Ok, we agree. Sorry if my first message seemed a bit rude.
> P.S. A couple of years ago I did an analysis of M
Hi,
I found in the pkcs15-init man page:
"By default, pkcs15-init will try to use the card's on-board key genera-
tion facilities, if available. If the card does not support on-board
key generation, pkcs15-init will fall back to software key generation."
But, if my card does not have an on
ASN.1 integers are encoded as two's complement numbers. This
means that the most significant bit of a positive number must be zero
and the most significant bit of a negative integer must be set to one.
Additionally prepended 0x00 octets for positive and 0xFF octets for
negative numbers, respectivel
Yes, this is what I mean: they *must not* be encoded, so that the
shortest possible representation results that still allows to
differentiate between positive and negative numbers. This is what
my examples show.
Andreas
P.S. A couple of years ago I did an analysis of Microsoft's
Kerberos pr
Andreas Steffen ha scritto:
> Additionally prepended 0x00 octets for positive and 0xFF octets for
> negative numbers, respectively are discarded.
If with "discarded" you mean that they will not appear in the encoded
form, yes. If you mean the decoder should ignore them, then no.
--
Alessandro Pr
Andreas Steffen ha scritto:
> Additionally prepended 0x00 octets for positive and 0xFF octets for
> negative numbers, respectively are discarded.
No, this is false. Even the relaxed ASN.1 BER encoding *requires* that
integer values be always encoded in the smallest possible number of
octets. See
Ludovic Rousseau ha scritto:
> Do we have ASN.1 experts on this list?
Yes. You are right, these are the rules:
If the contents octets of an integer value encoding consist of more than
one octet, then the bits of the first octet and bit 8 of the second octet:
a) shall not all be ones; and
b)
Hello,
It looks like the functions asn1_encode_integer() and
sc_asn1_decode_integer() from src/libopensc/asn1.c are not correct.
For example the integer 128 is encoded 0x80 but should be encoded 0x00
0x80. 0x80 is the encoding of -128
-128 is encoded FF FF FF 80 but I don't know if that is a vali
On Feb 9, 2008 5:36 PM, Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
> Hello Again,
>
> I reverted the last change... Th dependency of xsl-stylesheets is
> required for svn checkout.
>
> Please test it out.
OK for me
Thanks
--
Dr. Ludovic Rousseau
___
open
12 matches
Mail list logo
