On 12/13/2010 3:53 AM, Martin Paljak wrote: > Hello, > > I'm somewhat confused by how OpenSC interprets the different algorithm > flags in PKCS#11 [1] and in the generic libopensc PKCS#15 code[2]. > Could somebody explain your view or what I get wrong. > > - SC_ALGORITHM_RSA_RAW (CKM_RSA_X509) - card is capable of raw RSA, > meaning it is willing to take in any data up to the modulus size and > encrypt/decrypt it, without additional processing (caller needs to > take care of details) > - SC_ALGORITHM_PAD_PKCS1 (CKM_RSA_PKCS) - card will take the input, > pad it with PKCS#1 and give the encrypted/signed result or decrypt, > remove padding and return the data.
> - SC_ALGORITHM_RSA_HASH_NONE - Signals "the input is not a hash" ? I think this says no hash can be done by the card, so if a PKCS#11 caller wants a digest, it must be done in software (OpenSC can do this if built with OpenSSL for many digests) or the PKCS#11 caller must have done the hash, and is using a raw method to indicate it has done the hash. > - SC_ALGORITHM_RSA_HASH_MD5_SHA1 - (SSL) - This should probably not > exist at all, SC_ALGORITHM_RSA_HASH_NONE should cover this. Unless there is some card that is expecting the 36 byte hash, vs the 16 or 20 byte hash. > - SC_ALGORITHM_PAD_NONE - ? Same as RSA RAW? Who will deal with > necessary padding? The define is for SC_ALGORITHM_RSA_PAD_NONE. This brings up a good point as SC_ALGORITHM_PAD_NONE would be a better name, as it is RSA dependent. Having just added the ECDSA which does not use PKCS padding... But ECDSA can use many hashes. One problem I ran into was how to define all the hashes in the 32 bit flags. I did this by overloading SC_ALGROTHIM_RSA_HASH* by using the same bits. See comment opensc.h:113 > - SC_ALGORITHM_HASH_SHA1|SC_ALGORITHM_PAD_PKCS1 (CKM_SHA1_RSA_PKCS) - > input is a SHA1 hash and card returns a PKCS#1 padded signature > - what about DigestInfo header? SC_CARD_CAP_ONLY_RAW_HASH and > SC_CARD_CAP_ONLY_RAW_HASH_STRIPPED, card flags for D-trust, should > control exactly this, but this is not a generic mechanism. Shouldn't > this be part of the algorithm specification, it is not a card > capability IMHO? > > If a card claims support for only _PAD_PKCS1 and _HASH_SHA1 only > (meaning it would like to sign SHA1 hashes and pad the result with > PCKS#15 and remove the PKCS#1 padding itself when decrypting), > sc_pkcs15_compute_signature will strip the DiggestInfo header if the > card does not claim SC_ALGORITHM_RSA_RAW and send the raw hash to the > card (similar to SC_CARD_CAP_ONLY_RAW_HASH_STRIPPED? I don't have > CardOS, so I don't know the cardos tricks.) Is it supposed to be so? > I'm confused. > > I would like it to be very explicit, without "surprises" or too much > automagic adjustments done by OpenSC (eventually the caller should > know almost exactly what is the input and the expected output what the > card supports, without much automagic transcoding in OpenSC), but I'm > not sure if I understand something basically incorrectly or the code > in pkcs15-sec.c and padding.c (sc_get_encoding_flags) is smarter than > I can manage. I agree it is "automagic" So three of the complicating factors I see are: When reading the code, SC_ALGORTHIM_RSA_PAD_NONE is 0 so when two of the card drivers OR this into the flags, it is meaningless. But SC_ALGORTHIM_RSA_HASH_NONE is 0x0000010 and has some meaning. The code was written for RSA only, but now has GOST and ECDSA, both of which can use many hashes. There are not enough bits in the flags to hold all the combinations. The comment in opensc.h 92: If the card is willing to produce a cryptogram with the following hash... Is now complicated as it should now read if the card or OpenSSL is willing to do the hash... > > > [1] > http://www.opensc-project.org/opensc/browser/trunk/src/pkcs11/framework-pkcs15.c#L2511 > [2] > http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-sec.c#L294 > > -- > @martinpaljak.net > +3725156495 > > I'm moving! martin.paljak.pri.ee -> martinpaljak.net > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
