I want to implement RSA encrytion/decryption in my App.I googled around the net to find any Library or Classes which perform the RSA encryption/decryption algorithm,but was not able to find any suitable link.I know i can use the SecKeyGeneratePair provided by Apple to generate the private public key pair.But it is a necessity for me to use the RSA algorithm as i want to implement it over client-server network.So the Algorithm needs to common amongst the parties.
Please provide some valuable info.
Thanks
Aditya
Isn't that what SecKeyEncrypt and SecKeyDecrypt functions do?
The functions SecKeyEncrypt and SecKeyDecrypt uses the RSA keys you got from SecKeyGeneratePair.
Related
I am trying to replace HSM(s) with my software-only application and integrate with PKCS11. The problem I have with that is all of PKCS api functions deal with slots and tokens which are not a part of my software application. Are there examples out there that I can look up to see how a software application can be used to imitate an HSM and integrate with PKCS ?
When you are dealing with HSM's you have to deal with slots and tokens. You have to modify your software slightly to accommodate this.
There are 2 ways you can use the PKCS#11, PKCS#11 Wrapper or PKCS#11 Provider. The Wrapper is the api that calls the native functions of the HSM library (.dll or .so) directly. The Provider uses the Wrapper under the hood, but gives you the convenience of using it with Java KeyStore api.
Considering your case, the Wrapper might not be fit for you, because it involves writing new classes to integrate with the HSM. You could use the provider.
Java has very good documentation of the PKCS11 Provider here. There is also a very good third-party library called IAIK, here is their provider documentation. Even though you use the Provider in your software application, trivial code changes are inevitable.
Where ever you have used the KeyStore api, you may have to make changes there. And initially, when your software loads, you have to load a configuration file for the PKCS11 provider that tells which slot number and the token to connect to.
IAIK has very good examples too, and their provider library is only free for development purposes.
I have a simple websocket server and I currently XOR the bytes to provide simple encryption to prevent data tampering, sniffing, no AES, no other cipher algorithms - the key can be reverse engineered anyway. When I google "how to secure websockets" I get only one answer: SSL/TLS. Using SSL requires from me to generate certificates in order to use it and protocol handles encryption for me so I don't have to call my encrypt/decrypt functions myself. I don't understand the difference between those two approaches. Certificates ensure that the server we connect to is the right one am I right - they are like identification cards. But I'm confused. Do I really need SSL for my simple server? My client is written in C++, websocket server is on Node.js. I'm planning to make a webclient for it later.
SSL/TLS is correct and well vetted. The chances of creating a solution with equivalent security is close to 0. But perhaps you have many years of full time experience developing cryptographic solutions, but then this question would not be asked.
In answer to: "Do I really need SSL for my simple server?" Yes if you need security.
See the "Schneier's Law" comment,
In Auth0 there are 2 algorithms for jwt token signature: RS256 and HS256.
RS256 is an asymmetric algorithm which means that there are two keys: one public and one private (secret). Auth0 has the secret key, which is used to generate the signature, and the consumer of the JWT has the public key, which is used to validate the signature.
HS256 is a symmetric algorithm which means that there is only one secret key, shared between the two parties. The same key is used both to generate the signature and to validate it. Special care should be taken in order for the key to remain confidential.
In their docs they describe the advantages of RS256. Could someone explain me the advantages to use HS256 algorithm, I don't see them now but I'm pretty sure that there are some.
You have asked for benefits of HS256 over RS256 eg.
perceived convenience
easy to understand and get started with if new
to Oauth2 / OIDC (related to perceived convenience)
performance (?)
Lets take a quick look at each of these:
Perceived convenience / understand what to do - It is true that copying a clientId, and clientSecret into configuration on the application is both easy to understand, and quick accomplish. However, today's libraries make RS256 simple too to setup - the library / framework will often offer the functionality to retrieve the public key and do the verification with similar configuration to HS256 but without the need to supply a secret. See some Auth0 examples using your technology choice to get an understanding on this if unfamiliar.
Performance - Yes, here HS256 potentially has a niche. Caching public certs etc aside (for caching example using node.js see here and here), having a symmetric key and using that locally at the application without the need for any network request at all etc, may prove more efficient. That said most good JWKS libraries / sdks will handle caching options out of the box.
But really the question you should be asking is whether these benefits (performance optimization?) outweigh the disadvantages - certainly from a Security perspective.
See this answer and feel free to leave comments there (Auth0 Community website) if still not convinced. Auth0 has switched to using RS256 by default for new Clients, and its Resource APIs also default to RS256.
A major benefit of RS256, which trumps most arguments for choosing HS256, is simply that there is no need to store (co-locate) secrets with the Client application - the private key is only known by the Authorization Server (Auth0 etc), and the secret cannot be leaked. That alone pretty much tells you why RS256 is overwhelmingly the better choice for most situations.
Confidential vs Public Clients - you should only even consider HS256 if your Client is considered a Confidential Client. Since confidential clients are capable of holding secrets, you can choose to have ID tokens issued to them that have been signed in one of two ways - for non-confidential clients, you should never be using HS256 as by definition the client is not capable of keeping the secret confidential.
There are other considerations that make HS256 a poorer choice too, for example the need to manually update all applications using a given Client configuration if there is a signing key rollover.
I couldn't find an information about in in Google. We are generating PGP key pairs using Bouncy Castle library and implementing our own "web of trust". I wonder if it is possible to use these keys for JWT also, or I need to use a PKI X509 certificates?
Thanks
The signature and encryption algorithms officially supported are listed here.
No signature or encryption algorithm using PGP is listed.
But nothing prevent you from implementing a new signature/encryption algorithm used by your server and clients.
AFAIK, there is no implementation at the moment that uses GPG.
From my point of view, you have to create a new key type (e.g. JWK with kty=PGP) and new alg (e.g. alg=PGP).
What is the difference between pkcs#11 and pkcs#12?
How do they work? How export pkcs#11 from e-token?
How it use in java 1.4?
PKCS#12 is a container for certificates with associated private keys.
PKCS#11 is a protocol to work with hardware (usually). So you can't "export" PKCS#11.
The rest of your question is way to broad to answer - try using Wikipedia as a starting point, then proceed to specifications.