multipart encryption when, for example, the data is too big to fit in
one APDU. It basically calls the Cipher.update() method until all data
has been processed. However, the Java Card API documentation advises
against using update():
"This method requires temporary storage of intermediate results. In
addition, if the input data length is not block aligned (multiple of
block size) then additional internal storage may be allocated at this
time to store a partial input data block. This may result in additional
resource consumption and/or slow performance. This method should only
be used if all the input data required for the cipher is not available
in one byte array. If all the input data required for the cipher is
located in a single byte array, use of the doFinal() method to process
all of the input data is recommended."
As the card's JVM was returning an internal exception when using
OP_PROCESS, it was decided to implement an msc_crypt_final_object()
function in OpenSC that uses the msc_object_*() functions to read/write
all the data from the card. This way, it is possible to transmit/receive
"arbitrarily" large data chunks to/from the card and use doFinal(). This
is the fallback method when, for example, using 2048 bit keys and the
card doesn't support extended APDUs.
Thanks to Joao Poupino for the patch
http://www.opensc-project.org/pipermail/opensc-devel/2009-March/011978.html
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3673 c6295689-39f2-0310-b995-f0e70906c6a9
martin
ludovic.rousseau
aj
vtarasov
sth
nils