Thanks for answer. >1 You say you must use RSA-PKCS1 without padding? > I don't understand what you mean by RSA_NOPAD.
Analyzing the muscle source code we can choose 2 algorithm of encryption : RSA-NOPAD (0x00 it means that data to be encrypted must be k length where k is the module of the key used to encrypt and returns k byte encrypted ) RSA-PkCS1 (0x01 it means that data to be encrypted must be at most k-11 length where k is the module of the key used to encrypt and returns k byte encrypted) >2 // Process with public key 02 > > b0 36 02 03 13 01 00 10 01 02 03 04 05 06 07 08 09 01 02 03 04 05 06 07 >What are you really trying to do here? >It looks like take 16 bytes and encrypt it using the public key on the card >but what is the 01 00 at offset +5? >Rather then start with a public key operation, start with a private >key operation to decrypt. 01 is the data location of the data to be encrypted (01 means data will be in APDU) The following 00 10 means the data size. >Are you sure the Muscle applet can do public key operations? Most >public key operations are usually done in software, not on a card. Yes we are. Thank anyway for your support. -----Messaggio originale----- Da: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-boun...@lists.opensc-project.org] Per conto di Douglas E. Engert Inviato: martedì 3 maggio 2011 21.15 A: opensc-devel@lists.opensc-project.org Oggetto: Re: [opensc-devel] Help MuscleApplet encrypt/decrypt RSA-Pkcs1 not RSA-NOPAD On 5/3/2011 2:33 AM, Piero Marte wrote: > Hello, > > We are three interns in a software company, we are studying the > > project "MUSCLEAPPLET" and we got problems while encrypting a message according to the RSA-PKCS1 algorithm. > > Premise that we can fully encrypt and decrypt with keys to 1024 using RSA_NOPAD, but we must use RSA_PKCS1. You say you must use RSA-PKCS1 without padding? I don't understand what you mean by RSA_NOPAD. Using PKCS#11 terms do you mean CKM_RSA_X_509 also know as RAW mode? > > Could you please give us help? > > Our tests were done on a kona25 card and JCWDE / CREF simulator in eclipse with version 0.9.11 of muscle. (I don't know anything about muscle, or you cards... and other may not either.) > > Here follows our APDU'S list to verify that we are not to be wrong: > > select > > 0x00 0xA4 0x04 0x00 0x07 0x0B 0x0B 0x0B 0x0B 0x0B 0x06 0x01 0x00 > > Answer: 90 00 > > //setting default ACL-s and memory size. > > b0 2a 00 00 28 08 4d 75 73 63 6c 65 30 30 04 01 04 31 32 33 34 04 31 > > 32 33 34 03 02 04 31 32 33 34 04 34 33 32 31 00 00 27 10 00 02 01 > > Answer: 90 00 > > // Login user > > b0 42 01 00 04 31 32 33 34 > > Answer: 90 00 > > //Rsa key generation with size 1024 in p1 there's private key and in > > p2 public key b0 30 01 02 10 01 04 00 ff ff 00 02 00 02 00 00 00 02 00 > > 02 00 > > Answer: 90 00 > > //init with mode 0x01= RSA_pkcs1 with public key 02 > > b0 36 02 01 05 01 03 01 00 00 > > Answer: 90 00 > > // Process with public key 02 > > b0 36 02 03 13 01 00 10 01 02 03 04 05 06 07 08 09 01 02 03 04 05 06 > 07 What are you really trying to do here? It looks like take 16 bytes and encrypt it using the public key on the card but what is the 01 00 at offset +5? Are you sure the Muscle applet can do public key operations? Most public key operations are usually done in software, not on a card. Can you phrase the question in PKCS#11 terms? Rather then start with a public key operation, start with a private key operation to decrypt. > > Answer: 6f 00 > > Thanks in advance for your help. > > ---------------------------------------------------------------------------- -------------------------------------------------------------------- > > Hello, > > On Mon, May 2, 2011 at 10:49, Piero Marte <ma...@compunet.it <mailto:ma...@compunet.it>> wrote: > >> Premise that we can fully encrypt and decrypt with keys to 1024 using > >> RSA_NOPAD, but we must use RSA_PKCS1. > > You can add/remove the padding in software. > >> Answer: 6f 00 > > 6f00 usually means an uncought exception. You have the source code of the applet, so you should be able to debug it further. > > We already debugged that, and we discovered that the exception was "Index Array Out Of Bounds exceptions" at the line ciph.doFinal(src_buff, (short)(src_base + 2), size, mem.getBuffer(), > (short)(dst_base + 2)); (line 722/723) > > We did the same operation by encrypting with RSA NOPAD, the only difference is that for RSANOPAD we need to insert exactly K byte to encrypt, where K is the module of the key, and everything works fine. > > Using RSA-PKCS1 we fed a number of bytes that is < k-11 (as the standard impose). But we got this status word 6f00 (Index array out of bound on the code) so we began to wonder whether there's some > kind of bug in the muscle code. > > Furthermore on the net we did not find any clue about that kind of problem, but every example we found uses encryption RSANOPAD, and this sounds strange. > > We know that we can form manually the byte array [00 02 RANDOMDATA 00 MSG] (like PKCS1) and then encrypt with RSANOPAD, but we'd like to know if there's something wrong with our APDUs. > > Are we forgetting something? Like some initialization about random number or something like that? > > Thanks in advance again. > > > > _______________________________________________ > 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 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
