Search

Heather

I did as you said, but the error is still there.

Heather

Thanks for all the help. It's due to overlap problem, indeed.

Heather

mabel wrote:You don't need to check the data. The problem is that input and output used the same buffer.

You can create a temp buffer. input uses apdu buffer and output uses the temp buffer. Then have a try.

Oops, that's it. I did as you said, it works.

Heather

Danieken wrote:Could you provide the data?

Among the result data, some blocks' data are same, but the subsequent data is inconsistent.
I used jcop/A22CR and JC30M48CR to do the test.

Heather

Whats landing contact card reader? Is there any card reader called this?

Heather

chico0609 wrote:Your problem is just because bytes are signed. Any byte in the 0x80-0xFF range will be signed extended to int and printed as a negative integer in range -127...-1.

Thanks for your help. If the problem is due to sign extension, how can I modify my code?

Heather

Generally speaking, your card will support ALG_ECDSA_SHA256 as well. But it really depends on the implementation.

Heather

You can write the applet in Java, Python and so on. The program language just depends on your own situation.

Heather

Check here

Heather

You can write one applet, and have a test. I have written an applet. Here is the code: package GR_TEST; import javacard.framework.*; import javacardx.apdu.ExtendedLength; public class GR_TEST extends Applet implements ExtendedLength { byte[] a = null; public GR_TEST() { a = new byte[(short)1000]; f...

Search found 11 matches: re:

Re: javax.crypto.BadPaddingException

Re: The different results with DES algorithm

Re: The different results with DES algorithm

Re: The different results with DES algorithm

Re: Does feitian have landing contact card reader?

Re: Problem of DER bytes

Re: java card- ECDSA signature

Re: write an application program which can access java card

Re: How to save the key in RAM?

Re: Confused about Get Response command

Board Disclaimer