I want to use ALG_HMAC_SHA1 method from javacard.security.Signature class. But my javacard framework version is 2.2.1 so Signature class does not include this method for this version.
it includes this method after 2.2.2. Is it possible to use this method without upgrading framework version?
You could always just use the value that you find in the 2.2.2 framework for the constant ALG_HMAC_SHA1 (= (byte)24) and pass it to the Signature.getInstance() method. So using the value is not a problem. However, the smartcard hardware on which you want to run your applet needs to support this algorithm in order for you to be able to use.
So if your smartcard hardware supports JC 2.2.1, calling the getInstance() method with the value of ALG_HMAC_SHA1 will typically cause a CryptoException with reason (CryptoException.NO_SUCH_ALGORITHM) indicating that the algorithm is not supported and JC 2.2.1 does not support any HMAC algorithms). Using the public constant directly will likely result in upload or installation failure.
Just to be clear here, I'm not suggesting that compiling for a different framework version might suddenly solve your problem. I'm rather suggesting that you can not simply upgrade the functionality that is available on your card.
The HMAC algorithm is not a big deal. As long as your card supports SHA-1 you can simply implement the algorithm on your own.
See RFC2104 for details and RFC2202 for test vectors.
BTW: You can not "upgrade the framework version" of a JavaCard - the Card OS and the JavaCard framework is usually not changeable (stored in ROM). You can only buy a different card...
Related
I'd like to learn how to use the OpenCL API, however I am a bit confused about how to "install" OpenCL for development. The various articles on Google are conflicting and I suspect some are obsolete.
My understanding is that Khronos group provides the specification and then various companies provide an SDK that complies with that specification.
As I understand it you need:
The OpenCL headers, which can be downloaded from the Khronos site
The OpenCL library, which comes with the various SDKs
Is there a difference between the different SDKs? From what I can tell the options are Intel, AMD or Nvidia. I've read conflicting information about whether it matters what SDK you use - some sources say that the SDK is just for the developer and the binaries that are produced will work on any hardware that supports OpenCL while other sources say that using a particular SDK locks your application into one vendors hardware. Which is it? Does it matter which SDK I choose to use and is there a non-vendor specific OpenCL library that I can link to?
OpenCL SDKs are different. They provide tools to ease the developing, additional functions, samples, and documentation.
Every manufacturer will include what it suits best their hardware, but they all should be compatible when the app is compiled.
The ".lib" ".a" OpenCL library that gets linked into the app (the one that comes in the SDK) is the same in all the cases (except if they have different versions, 1.1, 1.2, 2.0).
This is because the library is not really a library, but only a stub to the real functions in the real driver. This also explains why the headers are all the same, they all link against the same library.
All the apps, no matter what SDK should be the same after compiling.
In the case of nVIDIA, additionally to their OpenCL.lib, they provide some functions to ease the platform acquisition (oclGetPlatformID() in oclUtils.h) and so on, that are not available on other drivers, and it is recomended NOT to use them unless you want to end up having to pack another nVIDIA propietary library to your app.
But if you really want to be generic, then you should go for dynamic library loading (dload(), LoadLibrary()). Which will make your app work even in situations where the system does not even have OpenCL installed.
You are correct, all SDKs use (or should use) the Khronos headers. You could also just use the Khronos headers yourself.
On Windows, you'd link to OpenCL.lib, which is just a static wrapper around OpenCL.dll (installed by your graphics driver in \Windows\System32). Everyone's wrapper should be similar for the same version of OpenCL. It is also supplied by Khronos (the ICD is open source) but it is easier to use one from an SDK.
OpenCL.dll uses the ICD mechanism to load the runtime(s) installed by each driver. If you have multiple runtimes installed, they each show up as a cl_platform.
If you are targeting OpenCL 1.1 (due to NVIDIA) I suggest using the version 1.1 header to ensure you don't accidentally use newer API.
While the OpenCL aims to abstract code from hardware, there are several different types of GPU architectures. These differences force writing specific code for specific hardware. Hence it is not easy to write a portable code. IMHO, you are better off selecting one hardware and utilize developer friendly SDK for that platform.
What is the use case you are trying to solve?
The binaries can be compiled at runtime (at least in Java). Therefore a OpenCL-C-runtime (?) is needed, but the compiled kernel are mostly hardware-dependent.
When we try to debug application on device (iPhone 5) get error
MT2002: Failed to resolve "System.Linq.Expressions.BlockExpression System.Linq.Expressions.Expression::Block(System.Type,System.Collections.Generic.IEnumerable`1)"
This bug marked as solved don't help us.
https://bugzilla.xamarin.com/show_bug.cgi?id=14765
There are a few things to consider if you use, even indirectly, System.Linq.Expressions (SLE).
This requires code generation and that's not something possible under iOS. This feature is not supported on Xamarin.iOS. SLE is part of the Dynamic Language Runtime (DLR);
There is partial support for SLE using an interpreter. That has been shipped with Xamarin.iOS for long time - but it only provide a subset of the features. Sadly the existing API is not 100% identical to the one used by MS and it can
cause issues when building (e.g. using PCL assemblies). This is why you're getting those MT2002 errors (your assembly tries to override an non-existing member).
A maintenance release of Xamarin.iOS (7.2.1+) includes a better (more features) and API-compatible SLE interpreter.
You need to change your Linq statement that is causing this. I faced this problem once (I was using a third party DB), Unfortunately the actual devices don't support JIT but the simulator does. Do your Linq statement differently.
What is the difference between an SDK that is "deprecated" and one that is "unsupported"?
I am asking in the context of developing javascript applications for Rally - I was fixing up an old application when I noticed the SDK will become unsupported in under 2 months. Does this mean the app will no longer work at all when the SDK becomes unsupported? Thanks
As I know, unsupported means that a function has thrown away and now it is not available. Deprecated, it means that a function is available but at the future will become unsupported. For unsupported/deprecated "things" almost always exists a new version of this with a different name( and maybe different parameters). You must not use deprecated functions or other staff.
Therefore, check for available updates and upgrades for your SDK, to make sure that your app will keep running and check for other implementations of the things that you are using.
How to create a class dynamically in a Blackberry project that uses Eclipse plugin?
My requirement: Suppose on click of a button a new class with a given name should be created. Methods and fields should be added and
then I should make use of that class
object. Is this possible in Blackberry?
Below are the steps I have done.
Get third party jars like ASM, javassist
Try to use them in project
but, I am getting verification errors when deploy to the device. So, is there a native api in RIM or any other alternative?
BlackBerry Java does not support the full set of reflection capabilities that you would expect in Standard Java (J2SE).
So, you won't be able to dynamically create a class, add methods, and then call them.
For the most part, BlackBerry is Java 1.3. If you tweak your development environment, you can get access to some newer features at compile time. But, in terms of the runtime code, you're limited to 1.3.
Javassist is based on Java APIs that don't exist in the 1.3 runtime that BlackBerry has, so it won't be of much help :(
Hopefully, someone else will chime in, but I don't know that this is something that's possible on BlackBerry Java.
When i compiled my application in blackberry it shows the following error.
generics are not supported in -source 1.3
(use -source 5 or higher to enable generics)
how to solve this
Java 1.3 is barbaric and no one should ever have to suffer its indignities. Fortunately, there is a solution!
Generics, enums, changing return signature in overrides, and pretty much everything that makes java usable was introduced in java 1.5. (see http://en.wikipedia.org/wiki/Java_version_history). Fortunately, most of java 1.5 was designed to be backwards compatible and not require JVM / bytecode changes. (or maybe this was unfortunate, as it lead Java's implementation of generics to be much weaker than C#. just try creating a generic class with static methods / fields that use the generic parameter)
This IBM article does a good job of explaining the background:
http://www.ibm.com/developerworks/java/library/j-jtp02277.html
But this JVM similarity allowed for creation of tools such as:
http://retrotranslator.sourceforge.net/
This is the section from my Ant buildfile that calls retrotranslator:
< java jar="${transformer.jar.exe}"
fork="true"
classpath="${epic-framework.dir}/tools/retrotranslator-runtime13-1.2.9.jar:${epic-framework.dir}/tools/retrotranslator-runtime-1.2.9.jar"
args="-srcjar ${build.dir}/classes5.jar -target 1.3 -destjar ${build.dir}/classes5to3.jar"
/>
Run the converted jar through preverify.exe and then give it to rapc.exe and you will have a working Blackberry app written with Java 1.5.
Edit: I missed a key detail in my original post. In addition to being Java 1.3, the Blackberry class hierarchy is missing many classes that would normally be a part of a Java SE 1.3 JDK. The one you will hit first is StringBuilder -- javac transforms ("string" + "otherstr" + "blah blah") into StringBuilder.append("string").append("otherstr").append("blah blah"). That class doesn't exist on BB, so you break. However, BB has StringBuffer, so writing an adapter between the two is pretty easy. The one catch is that BB disallows apps from adding classes into java.*. This can be very effectively fixed in the build process: 1) build your app against Java 1.5 w/ java.lang.StringBuilder on the classpath, 2) string transform java.lang.Stringbuilder (and everything else in your compat shim) to live in com.mycorp.java.lang.StringBuilder and build it into a JAR file. 3) Use that JAR file w/ retrotranslator and retrotranslator will update all bytecode references to java.lang.StringBuilder so that they now point to com.mycorp.java.lang.StringBuilder. Now you have a java 1.3 compatible bytecode that can be run on a Blackberry.
If anyone is interested in this stuff, contact me. I could look into open sourcing the compat library I have.
This is a limitation of J2ME, which uses a subset of the J2SE (no collections, reflection, etc.) and a Java language level of 1.3. Any code written for J2SE will most likely need to be manually ported.
It seems the JDK5 is not yet supported.
Same question was asked on the blackberrry forum but about enum support:
Sadly, the BlackBerry api is very behind in terms of Java versioning. There's no Generics, no Maps, no Enums - it's based around JDK 1.3.
I believe there is no way of enabling this feature within your BlackBerry app. If you find one, I'd be very interested to hear about it.