library import

[johnnytshi]

Does anyone have any experience turning this into "jar / exp" files, and integrating into an existing applet project?

I understand I can copy the source files into my project, but that's a bit messy. Wondering if there's a better way

Thanks!

[petrs]

Hi Johny, I think making this separate library is possible, but you would then need to also upload it separately to card. Would this be an option you would like? BTW: There is single file version fo the whole library - so you need insert this single file into your project. I'm also interested to learn in what context you woudl like to use JCMathLib (to make it better suited) - if you are willing to discuss, please DM me.

[petrs]

Hi @johnnytshi, was any of the options of help to solve your problem with import of the library? I plan to close this issue so it would be good to learn what worked for you

[YoHidden]

Hi there, I'm interested in using the single file option for the whole library in order to import it in my project. But, where's that single file ?

I'm looking to this library as an optional work-around to avoid an error that KeyAgreement object keeps producing every time I try the multiplication (generateSecret function) in my card based on the Infineon SLE78 and with JCK 3.0.4 (...an undocumented error code 4015 hex). But I've read that this library makes use of this KeyAgreement object precisely for this operation. Is this so? Because in that case, I guess that the use of this library will not avoid my problem.

Thanks.

[petrs]

Hi @YoHidden, the library as single file can be found here: https://github.com/OpenCryptoProject/JCMathLib/releases/download/v1.0.1/jcmathlib.java. It was created with simple utility I created (https://github.com/petrs/JavaPresso) so you can rerun it on the newest code.

Regarding the multiplication - we (primarily) do use KeyAgreement.getSecret to recreate behaviour of ECPoint object (which is missing in open API). To make it reasonably fast, we use underlying implementation in KeyAgreement. You can likely avoid it completely and use "schoolbook" implementation, but that would be terribly slow - so I don't know if that would be good solution for your issue. Have you tracked down the reason for the error you are getting? Is it for some very specific input parameters, or the method call always fail? You may also try https://github.com/crocs-muni/JCAlgTest/ to scan if your card is really supporting KeyAgreement version you like to use

[YoHidden]

Thanks @petrs for the single file lib and the compression tool (this one is awesome).

Regarding the multiplication, I've had used the JCAlgTest tool and found that algorithm _ALG_EC_SVDP_DHPLAIN for javacard.security.KeyAgreement was tested as OK.

I have tried with different values for the private key, and always got the answer 4015, which is an error code that I can not find documented anywhere. I even tried the Satochi Applet implementation (https://github.com/Toporin/SatochipApplet). Same result when sending APDU with INS 0x35 which yields to execution of getPublicKeyFromPrivate(...), which use the keyAgreement.generateSecret(...) function. This execution, as in my code, produces the 4015 answer.

I'll give a try to your library even by using the schoolbook implementation. How can I use this schoolbook version ?

Thanks.

[petrs]

If getPublicKeyFromPrivate() in Satochip fails as well, then the issue is likely lower in implementation. To use schoolbook multiplication, FLAG_FAST_MULT_VIA_RSA must be false. It is set to true in Bignat_Helper.initialize() if card likely faster multiplication via RSA engine. But I'm not sure this is the problem within your card as exception is raised in KeyAgreement.generateSecret(), not in multiplication itself

[petrs]

@YoHidden @johnnytshi I think we can close this issue - feel free to reopen if necessary