Am Sonntag 13 Dezember 2009 14:49:31 schrieb Ludovic Rousseau: > 2009/12/13 Andreas Jellinghaus <a...@dungeon.inka.de>: > > I tried all four combinations of old/new code for init and for signing. > > > > only cards initialized with old code and signing with new code is broken, > > so we could as quick fix revert the change. > > I remember doing this patch. > The problem was that the ASN.1 encoder/decoder routines were bogus. > Negative values and "special" values like 128 were not encoded > correctly.
can you explain how the encoding rules exactly are? I saw that the old code encodes 145 = 0x91 as integer as "02 01 91" (02 = integer tag, 01 = length byte), while the new code uses "02 02 00 91" (02 = integer tag, 02 = length byte, 00 91 = value 0x0091 = 145). do the encoding rules give us any clue, maybe "91" is an illegal payload? or does anyone know if for example keyReference needs to be a positive integer, so we can run a "fixup" later? we would need to check all integer in all asn.1 encodings I fear, as the same bug could be in all of them. hmm, not possible a grep shows 36 entries :( so I wonder how we can detect the problem and fix it. worst case: for starcos our "guess" is keyReference should be positive if it is set, so for every value from -2 to -128 we could simply add 128. (I'm no starcos expert, at least I hope that key Reference is a positive value) ah, SPK2.4 manual page 28, dummy values are 000xxxxxb, real values 100xxxxxb. So we can implement a hack for key ID, if we find no generic solution. any ideas for a generic one? Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
