I have a RSA key in a PEM file created with openssl, and Im trying to load it into Lockbox3 (a delphi component) but it seems they are not compatible. In their forums I found this:
"Only after you nail down all the options used by the other party, both explicit and implicit (which are typically poorly documented), do you have a chance for interoperability."
So, I'm wondering if someone had made it work.
The latest version of Lockbox (available from SVN, not the file downloads as yet), provides a Delphi wrapper of OpenSSL's RSA functionality. It can save and load files in PEM format. I hope this satisfies.
The OpenSSL component is marked as experimental at the moment, but it has been tested and seems to work well.
Related
I'm starting to dive into a customer requirement that we use FIPS 140-2 for data at rest and data in transit. From my (limited) reading so far, it sounds like iOS 7 and up have FIPS support built in. I've also seen articles on the subject (iOS with FIPS) point to building OpenSSL and including that in your project to get FIPS support. I'm not sure why OpenSSL is necessary if FIPS is already included in iOS 7+. Am I missing something?
At the time of this writing OpenSSL FIPS is pretty much broken for newer Apple devices and versions of iOS past 6, because getting it to compile requires heavy modification of the build process, which is absolutely disallowed for FIPS compliance. You get a library, but not FIPS compliance unless you re-certify. Try stepping through the documented build process to observe the minefield. Community contributions to help resolve the issues have not been incorporated. It is also not very secure because it isn't responsively updated for threats. Heartbleed will be with us for years, but CommonCrypto turns on a dime in comparison, being re-certified as needed and updated along with other OS updates. Use Apple CommonCrypto.
One of the many threads about why it is broken: https://groups.google.com/forum/#!topic/mailing.openssl.users/V_HITNhWaDA
A related(not duplicate) question by me. The only answer breaks FIPS compliance.
Unknown cpu type when compiling OpenSSL FIPS Capable libraries for arm64 or arm7s
Unless you need some functionality that is in OpenSSL that is not in Common Crypto use Common Crypto.
The reason that Apple no longer supplies OpenSSL is due to many instances where SSL is not backward compatible and an Apple supplied current version may not be compatible with an app that was built with an earlier version.
Further, Common Crypto uses the build-in hardware crypto and OpenSSL may not.
Why use OpenSSL for FIPS 140-2 vs relying on CoreCrypto on iOS?
OpenSSL is available on a wider array of iOS platforms. For example, OpenSSL includes iOS 5 through iOS 7 using the A4 through A6 processors. There are more iOS validations, but they have not been given to the public under Certificate 1747. For example, the foundation already has an iOS 8 validation in progress.
In addition, OpenSSL is available on non-Apple platforms. The latter is appealing because the means the same code base can be used on multiple platforms, including Windows, Linux and Android.
Apple got its first validation on May 2013, which meant there was nothing available from Apple from 2010 to summer of 2013. That was a big void. Apple still only provides a validated module up to iOS 7.
And during the time of missing vendor support, Apple made it appear they had a validated module through their marketing literature. (Apple had a "Module In Progress", which is different than a "Validated Module". And it took them years to get it validated, which was kind of unheard of).
As someone who follows these things, Apple's tactics from 2010 through 2013 were clearly meant to confuse those who were looking for FIPS 140 validated modules. (I wrote to the CMVP about Apple's despicable practices. The CMVP will request a Cease and Desist order for vendors like Apple. Apple is not the only vendor to confuse and lie to folks - CipherCloud did it too).
I am currently encoutering a very strange problem. In one of my applications I use OpenSSL and Indy in order to create a secure TCP connection to a host. I wanted to test if the application (and Indy) are recognizing if the OpenSSL-libraries are missing. Those libraries are placed inside the application folder.
The strange thing is that my application still works fine even though I have removed the libraries. I also removed OpenSSL itself from my computer and searched for any other appearance of the OpenSSL-libraries. There are no OpenSSL-libraries on my computer.
So what is going on? I call the Load() method from IndyOpenSSLHeader in order to load the libraries and guess what...they are loading perfectly. How can this be? There are no libraries on my computer ^^
Btw I did NOT set up a custom library path. I am using the default one which - as far as I know - should be the application folder.
I am using Delphi XE5 and Indy 10 for me application.
What is wrong here?
Thanks in advance!
If you are on iOS then Indy links to OpenSSL statically. On any other platform, there is no possible way that Indy can successfully use OpenSSL SSL/TLS without loading its library files first, so they have to be getting loaded from somewhere you missed. If you are running on Windows, use Process Explorer to see where they are actually being loaded from.
Indy defaults to using the OS search path to load external libraries. The OS defaults to looking in the app's folder, but it can also look in other places as well. You can use Indy's IdOpenSSLSetLibPath() function to specify where you want OpenSSL loaded from (there is a similar function for ZLib - IdZLibSetLibPath()). This is good to ensure your app loads the libraries only from your app's folder and nowhere else, in case someone maliciously deletes the libraries from your app's folder in an attempt to trick it into loading the libraries from another path on the OS's search path. It is also good for testing purposes if you just want to see how your app reacts when the libraries are missing, without having to actually delete them.
They may be statically linked into your binary.
Also, there is a lot of places where SSL libraries could be.
See this article (Search Order for Desktop Applications):
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
I would like to put the Z3 (V3.2) assembly into the GAC, but it is not signed.
Is there a reason for that ?
The 64 bit managed DLL is built with a self-signed key, the 32-bit DLL is not. This looks like a bug and I will check if we can add a workable delay signing to the 32-bit version as well. We don't build already signed assemblies, but components that use Z3 have so far been able to integrate delay signed assemplies that we provide per requests.
There are many questions on zipping in Delphi, anyway this is not a duplicate.
I am using ZipForge for zip/unzip capability in my application.
Currently I use 2 features of ZipForge:
1) zip and unzip (!)
2) password protect the archives
Now I am removing the password from all the archives so I need only to zip and unzip files. I zip them just for minimizing bandwith when uploading/downloading files from the server. So my idea is to process all files once for unzipping them (with password) and rezipping them without password.
I have nothing against ZipForge, anyway it is an extra component, every time I upgrade to a newest Delphi version I have to wait for the new IDE support and moreover the more components the more problems during the installation (I don't mention the cost since it is very low, and replacing a component with some other thing costs time, so it is not a cost issue).
So since what I do is very simple I'd like to replace ZipForge with 2 simple functions using the ZLib unit.
I found (and tested) the functions here on Torry's.
What do you think of using Zlib unit? Do you see any potential problem that I would not have with ZipForge? Can you comment on speed?
Well, ZLib out-of-the-box is not ZIP and if you need to create ZIP files which should be unpacked by third-party software, you will have to write extra code to actually ZIP files. If you use your own code to perform both compression and decompression, you can go with ZLib. But still you will be reinventing the wheel by creating your own convention of passing file names etc. And you still need to use a third-party library.
How do I implement BouncyCastle RSA encryption for a BlackBerry application?
As #itsteju points out, you can get the same functionality using the BlackBerry methods, but that does require an agreement and a royalty payment to Certicom.
Bouncy Castle maintains a J2ME compatible release on their releases page. It's not their full API, but does support RSA encryption.
As they provide source, the easiest way to integrate their RSA code into your project is to add their .java source files to your project and build. As I remember (I don't have the source readily available) they provide some classes in the java.lang package (BigInteger for example) - or at least they used to. The BlackBerry won't let your application run with these, so you'll have to rename the package and all references to it in the source you download. Note that last time I did this was a few years ago so things may have changed.
There is standard set of methods available for RSA encryption. Check API docs for this.
Those are licenced with Certicom. You need to get the keys purchased from Certicom before using RSA encryption.