What is the difference between the PKCS#11 library provided by the libp11 and the OpenSC project. Are they mutually exclusive or do they depend on each other?
The Wiki pages of the two projects stated:
https://github.com/OpenSC/OpenSC/wiki
OpenSC implements the PKCS#11 API so applications supporting this API (such as Mozilla Firefox and Thunderbird) can use it. On the card OpenSC implements the PKCS#15 standard and aims to be compatible with every software/card that does so, too.
https://github.com/OpenSC/libp11/wiki
libp11 is a library implementing a thin layer on top of PKCS#11 API to make using PKCS#11 implementations easier.
So OpenSC is an implementation of PKCS#11 supporting PKCS#15 smartcards, while libp11 is a wrapper trying to make the PKCS#11 easier to use.
Related
Can boringssl work on ARMv8 bare metal platform? I tried build boringssl with aarch64-elf-gcc, but it refused to build.
If it does, any porting guide or suggestions?
Probably not out of the box. But you should probably not even try using it, mainly because, according to Google itself, it is not intended for general use.
This is never good to be on your own when using a library, more specifically a cryptographic one. This is usually synonym for no bug fixes, no support, no user forums among other things.
You could rather consider a library that was designed for this purpose, such as mbedtls (formerly known as PolarSSL).
It is being used on a wide range of systems, from bare-metal systems (FreeRTOS) to Linux (The Hiawhata web server does use it for example).
Update: Even if support for Armv8-a hardware crypto extensions is needed, you could still reuse BoringSSL Armv8-a optimized routines (ISC license) or the Cavium armv8_crypto library (BSD license), to replace mbedtls (Apache 2.0 lisense) equivalent routines: cryptographic functions usually have clean and small interfaces.
From my experience, this may still be faster than porting a library targeting a general purpose operating system if your target is a bare-metal one, but you ultimately have to evaluate the costs for both options in your specific case.
My guess would be that there is far less work involved for adding support for Armv8-a crypto extensions to mbedtls using already existing, supported code under the proper license, than attempting to strip-down openssl or boringssl for use on a bare-metal target.
There is a very good piece of documentation explaining how to add support for hardware-accelerated crypto to mbedtls here, this may help you evaluating your options.
Recently I have worked using WebRTC and I'm wondering if it would make more sense to implement a Real Time Communication open standard at a native level.
Let's say that instead of a web browser API we have a native API that any native app, including the browser can leverage.
Part of the promise of WebRTC is to have RTC on the browser without plugins but why stop there, why not have RTC on any device with media capabilities without plugins. There are many devices with media capabilities that will not run a web browser, e.g., wearables. It seems to me that the browser itself has become the plugin and I think we need to get rid of it as far as RTC is concerned.
It sounds like OpenWebRTC is going in a similar direction but so far they are only working inside the browser.
Are there open standards for native RTC? So far it looks like RTCWeb is only concerned about the browser.
Are there any projects/initiatives for native implementations of an open standard for RTC?
webrtc definition. webrtc is stuck into two parts, complementary but separated. the W3C consortium is standardizing a JS API for browsers named webRTC. The IETF is standardizing the underlying protocols and what happen on the wire for interoperability, it is named rtcweb.
the IETF's rtcweb group defines everything you need to interoperate with a browser, without being a browser yourself, i.e. for gateways, devices, .... It has been made explicit at the latest meeting in hawaii last november, and there is for example a corresponding draft.
On the client side, the implementation of webRTC JS API is done on top of c/C++ implementations. Those "native" (as in non-browser, C/C++) APIs can be use directly for servers, embeddable devices, gateway, ect, or can also be wrapped in different languages (obj-c, java) to provide "native" (as in mobile native) APIs.
Note that BOTH openWebrtc.io and webrtc.org have a full implementation of webRTC in C/C++ that you can use. openWebrtc provides iOS wrappers, and webkit wrappers (for safari), but do not provide data channel support, ORTC API support, nor compile under windows. webrtc.org supports all desktop OSes, and provide wrappers for both iOS and Android. The build tools are specific to google's chrome though, unlike openWebRTC which uses standard auto tools, github, ...
HTH
Currently there is no effort in this direction. The guys in the webrtc standardization committee have their hands full standardizing just the javascript API. As you know the current spec is not final and is currently still worked on. And now ORTC will generate even more work.
There are many reasons why no one is currently trying to standardize any form of native RTC. Here are some that come to my mind:
What exactly is native? Javascript is native for the browsers. The chrome version of webrtc is in C++ but the OpnWebRTC one is in C. Android developers use mostedly Java, iOS developers use ObjectiveC. Should there be standards for all these languages? That's going to take forever.
As I said standardization committee already have their hands full.
There is still quite a lot of experimentation that goes on with WebRTC. Standardization may prevent this.
The API of the native libraries tend to be very similar to the JS API.
I want to know how to enable the developers to create add-ons for my application like chrome, firefox, blender and VS?
I'm asking here about the concept how the made it? programmatically, what I need to provide in my application with to make this?
any references I may help me?
There is a number of options.
You can embed a scripting language (or an entire VM, like .NET or JVM) into your application, providing a decent API for all the internal functionality. If your application is built on top of such a VM already, chances are you don't need to do anything specific to enable an extensibility, just make sure your API is available and documented. Popular embedded scripting choices are Lua, Python, Guile and Tcl.
Alternatively, for a purely native code, you can provide your API as a separate dynamic linking library, and allow to load third party modules (linked to that library).
You can also make your application modular (split into separate processes), with the components talking to each other over a simple, text-based protocol via pipes or sockets. A very elaborate and powerful infrastructure is available for such an integration option, which is known as the "Unix way". In this case users will be able to choose any way of integrating their extensions with your core functionality.
Choose any, depending on a nature of your application.
How does software allow developers to make a plugin / extensions on top of its core? How is that related to object oriented programming? maybe with inheritance or interfaces? What kind of design pattern should one use?
For example, firefox extensions that enhance firefox, wordpress extensions, etc. Those systems sort of "recognize" plugins after being installed and work well and in some cases they perform safety checking, dependencies, and the like.
Anyone care to shed light on this?
Plugin models in real applications like firefox may be more complex than they are in general. In general you define some interface that a plugin should implement, and implement it in your plugins, that's it.
Modern frameworks contain plugin development facilities like MEF in .NET, mojo in Java, etc.
Java supports a basic plug-in mechanism through its SPI (Service Provider Interface). The main mechanism revolves around discovery and binding of the new provider. Below two articles will get you started
Replaceable Components and the Service Provider Interface
Creating Extensible Java Applications
There are open source frameworks that are more powerful than provided by JDK
JPF
JSPF
But OSGi is the standard and mother of all plugin frameworks in my opinion.
I'm writing software for a new hardware device which I want any kind of new third-party application to be able to access if they want to.
The software will be a native process (C++) that should be pollable by 3rd party games and applications that want to support the hardware device. Those 3rd party apps should also be able to receive events from the native process, on a subscribe basis. So aside from the native process, I'll also supply "connector" libraries to the 3rd party developers, for all platforms/languages that they might choose (Java, C++, Python etc.) to embed in their apps so they can easily connect to the device with hardly any extra code needing to be written by them. I want to target all desktop/laptop OS platforms, and have a pretty good idea of what functions I want to expose, but ideally I don't want to be too stuck (i.e. I want it to be elegantly scalable from both client and server perspectives).
I'm looking for reliability going forward, performance, maintainability going forward, and cross-platform/language flexibility going forward, and ease of development, in that order.
What should I use?
CORBA, MessagePack-RPC, Thrift, or something else entirely?
(I've omitted ICE because of it's licensing)
Thrift or Message Pack is the best option going forward. Both are sleek, light weight and do not add much latencies to your process. They have support for most of the common languages, and are in Active Development. At the current stage I would prefer thrift personally but message pack does seem to promise a lot of features.
Thought thrift might not be as windows friendly as we want but people are using it on windows.
This is a starter guide for thrift on windows.
http://wiki.apache.org/thrift/ThriftInstallationWin32
Only installing and getting the Thrift compiler can be troublesome on windows. Using the generated files depend on the language you choose and lot of the languages have good support to run the files by importing thrift libraries. (Java it is very easy, MAVEN artifact)
There is a discussion on the RPC frameworks available at RPC frameworks available?
CORBA according to me is old cumbersome and very heavyweight.
If ancient and heavyweight don't put you off, obsolete definitely should. Regardless, I can tell you what we've been using Google Protocol Buffers at work recently, and they're pretty easy to use.
From the developer's perspective, all you need to do is have a build of GPB (which really isn't that difficult), and then it will generate source files for you. The end result is a cross-platform binary message transport message passing interface (think XML and limited RMI, not MPI-like functionality).
We use it on Windows to talk to an Arm-based Linux system (TS-7200's from embedded arm) running the same software. to my knowledge, it is compatible with many languages.
CORBA is the only free "RPC" thing that would work for my system right now, even though it scales very badly. Thrift isn't Windows-friendly yet. Neither is MessagePack-RPC yet available in all languages and OSs, even though it's still in development. If CORBA was elegantly scalable it probably wouldn't have become obsolete at all.
Protocol Buffers and messaging would work, I'd have to develop a both a client and service implementation for every platform/language. It would also be very scalable. I've decided on this.
I'm currently using Apache Thrift for a Hospital Manager project. It is better than CORBA in many areas, not to mention it is lightweight and much easier to implement and understand. The learning curve for Thrift is definitely subtle compared to CORBA, but the documentation for Thrift is the worst thing.
I'm using a Ruby Thrift server to which Obj-C and Java clients connect. The Thrift parser or "compiler" does a pretty good job generating source files for the languages you want, although it is far too verbose. I would definitely look into implementing Thrift, or Google ProtoBuffs if I was starting a new project, since CORBA is really outdated, and might not implement new technologies in the future, not to mention that there are many vulnerabilities and exploits targeting CORBA that will not get patched since it's not in development anymore, presenting some serious security holes on your new project.
Thrift supports many programming languages: C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Objective-C, JavaScript, Node.js, Smalltalk, OCaml and Delphi as of this writing. Supporting multiple languages is key, I think, for the purpose of your project.