Hi! > > Are your key sets relevant to the encoding of the APDU? If not, then > > you could see key sets as part of the crypto layer. > > The block size of the cipher is relevant for padding. So it actually > depends on the notion of key set you decide to implement. If you keep > the specific block size out of the key set, it is not relevant.
Correct, I forgot about that. In my implementation I simply stored the block size in the encoding layer. But this is the only thing that overlaps, I think. > (On a related note: if I understand correctly 7816-4 allows, but does > not mandate, to use block chaining across different APDUs in a > session, so that you have to keep some state across different commands > in order to recover the initialization vector.) > > > I agree. But you have to keep in mind that ISO-7816 subsumes multiple > > cards, which only differ in crypto. > > This might have some small variations in the implementations. For > instance, the Italian CNS (national almost-eID card) seems to follow > 7816-4 where, when using SM authentication, the first block contains > CLA, INS, P1, P2 + padding. But the padding is not 80 followed by as > many 00's are needed to complete the block; rather, it is only 00's. I > think that these quirks could be best handled by flags, if they are > reasonably few. Could you check if thats consistent with 7816-4 6.2.3.1? I think the sequential stage also defines the behavior which you are describing. Cheers, Frank.
pgpZZGKYL6ThA.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
