I am looking for the methods in CommonCrypto to generate the shared secret based on ECDH. I can find proprietary implementations but nothing standard. This method is called sometimes Key Exchange and includes the calculation of the shared secret. Can someone send a link to the right documentation or to an example that uses CommonCrypto for generating the shared secret based on Elliptic curve Diffie–Hellman?
CommonCrypto implements ECDH. Apple Open Source includes the source code for the implementation. The problem is that the implementation is not exposed in the iOS SDK header files. I just checked iOS SDK versions 6.1 and 8.0, and the functions are not declared. This means that any app that somehow calls the routines will violate Apple's App Store Review Guidelines: Section 2.5 says "Apps that use non-public APIs will be rejected".
I suggest using OpenSSL, which includes ECDH.
Related
We're considering to migrate legacy API to FCM HTTP v1 API to fully utilize FCM functionalities.
Although they provide API Client Library for various programming languages, it could not be possible to cover all programming languages including C++.
Because our push server is written in C++, we decided to implement the protocols. However, we could not find any documents on how to get access token using service-account.json file or server key that can be found in firebase console.
Is there anyone who integrated FCM HTTP v1 API without SDKs that FCM provides?
I figured out the problem.
These articles helped me to implement the protocol in C++. Now it works well. developers.google.com/identity/protocols/oauth2 developers.google.com/identity/protocols/oauth2/service-account
Do HSM companies usually provide a PKCS#11 API to work with the HSM or do they just provide their own Cryptographic API?
In each case how to integrate to a Linux Application(using OpenSSL, possibly like how one would call an openssl engine for a 3rd party library?) and to a Windows Application?
What is generally preferred? PKCS#11 API or a generic API?
What are the advantages and disadvantages of the two?
A HSM vendor has told us that they can provide both a PKCS#11 API and a crypto API written in C language. I am trying to understand the terms and therefore this question!
A simple overview would me to research further :)
Many thanks!
Generally a PKCS#11 library is supplied, if just to compete with the other products that also supply such a library. PKCS#11 is a common interface that can be used from software. There are many software packages that allow the use of the PKCS#11 token standard underneath, such as the OpenSSL PKCS#11 engine and a PKCS#11 security provider in the Java language.
Although PKCS#11 can be extended this doesn't mean that all the functionality of a HSM can necessarily be supported. PKCS#11 is a relatively low level interface. Sometimes it makes more sense to use proprietary API's that better fit a specific use case. The more parts of a cryptographic protocol can be performed on a secured device, the better.
As for which one is better, that depends entirely on your use case and threat model as well as the crypto API that can be provided.
PKCS#11 (definition from wiki)
The PKCS #11 standard defines a platform-independent API to cryptographic tokens, such as hardware security modules (HSM) and smart cards, and names the API itself "Cryptoki" (from "cryptographic token interface" and pronounced as "crypto-key" - but "PKCS #11" is often used to refer to the API as well as the standard that defines it).
So this is generally the standard API all the HSM manufacturer's use.
It completely depends on the HSM vendor if they implement this API. If they did implement it, you should be able to communicate with their hardware using the standard PKCS#11 API from any platform (provided they support it) or any third-party libraries that can act as a middleware between your software and their hardware. If they didn't implement it, they usually write their own proprietary API that may be specific to a platform and communicate with their devices only. This forces you to use their API to communicate with their hardware (HSM in this case).
So, from your perspective, if you used the standard PKCS#11 API and in future if you collaborated with another HSM vendor, you can use your same code to communicate with the new HSM as well (because PKCS#11 is a standard). But if you used their own API, and to communicate with a new HSM vendor you cannot reuse your code, because their API might only work with their devices.
The PJPROJECT libraries are organized as follows:
Base libraries (PJLIB/PJLIB-UTIL/PJSIP/PJNATH/PJMEDIA)
APIs (PJSUA/PJSUA2)
I'm trying to develop a new API based on PJSUA but using RTC native libraries (as far as I know, the term WebRTC is more related to the Web API) instead of PJMEDIA.
However, according to the official docs, I understand that the RTC native libraries are used for signalling and media.
Is it possible to only use the media part of the RTC libraries? If yes, where can I find resources to integrate the RTC libraries with PJSIP?
Thanks,
Mickael
CSipSimple (Android SIP Client) has bolted a part of WebRtc into PJSIP as patches: https://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/jni/pjsip/patches/002pjsip-webrtc-aec.diff
I am developing a client app for a RESTful web service. The web app uses the Stanford JS Crypto library for some client site cryptography and I would need to do that with the app too.
But the SJCL library doesn't just AES256 crypt the data, it does provide a kind of easy to wrapper around it. Have a look at the SJCL short overview page for more details: http://crypto.stanford.edu/sjcl/
Does anybody has experience in providing a compatible process to crypt data like SJCL would do with ObjC?
OS X and iOS both come with several frameworks which provide everything you need to do the same as SJCL: CommonCrypto/CommonCrypto.h and Security/Security.h to start with. From AES to PBKDF2, with SHA-1/2 or Base64 in between.
There is a lot of stuff here on what an API is, but I can't find what I need on the distinction between plugin APIs and class library APIs. I don't get it anyway.
In the book, Documenting APIs, I read: The key difference between a plugin API and a class library API lies in the which party supplies the implementation for the exposed API.
Plugin API: The publisher creates an application and exposes a plugin API; the 3rd > party developer implements the API. The 3rd party developer plugin extends the functionality of the publisher's application.
Class library API: The publisher creates the API and implements it. The end-user uses the class library via its API to write an application. With a class library, the publisher implements a library of functionality that exposes an API.
I think I understand the plugin. I'm not clear on the class library API. Is it like a printer manufacturer creating a driver based on an O/S class library so that their printer works with that O/S?
If so, could you explain more about the differences in the APIs themselves? Are they both still a set of exposed methods? And how does the publisher implement its own API?
References
Documenting APIs: http://www.amazon.com/documenting-APIs-writing-developer-documentation/dp/0963002104
What is the difference between a Java API and a library?
Difference between framework vs Library vs IDE vs API vs SDK vs Toolkits?
API vs Toolkit vs Framework vs Library
They are both software interfaces. This means that they both look similar, typically a Java archive (JAR) containing a package (or multiple packages) with interfaces, classes, exceptions, etc.
I can understand why you found the explanation from the book confusing. As far as the API itself is concerned, the Java implementation is provided in both cases.
The major difference is in how this Java code is used. In the case of Plugin API (I like to call it Service Provider Interface, or SPI) you are primarily expected to add your own functionality by implementing the provided Java interfaces and/or extending the provided classes. On the other hand, you are only expected to call a Library API (I like to call it simply API), you are rarely expected to implement interfaces or extend classes.
Because of how they are used, there are many subtle differences between how you design an SPI and how you design an API. While I don't have a post dedicated to comparing SPI and API, when I discuss the various aspects of API design, I usually point out these differences:
http://theamiableapi.com/