I need to build an iOS application in which PGP keys will be created in order to encrypt and decrypt certain messages.
Since I'm new to PGP encryption in iOS is there some library that will allow me to create, keep and access the PGP keys as well as do the encryption and decryption using the keys.
I've implemented a backend and Android version using RSA algorithm with bouncy castle and OpenPGP in JAVA, however I will need to do the same with the iOS version. That means that the keys created in iOS should be in the same format and compatible with the ones created in the Android version.
Check out this projects: UNNetPGP or ObjectivePGP, this may do the job for you.
OpenPGP keys have a standard format defined in the RFC 4880 (two formats - binary and base64-encoded). As far as I know, it's BouncyCastle that can create keys in some custom non-standard format.
One of options is to use our SecureBlackbox (C++ edition) on iOS - it offers full scope of OpenPGP functionality including key generation and management.
If you really need Bouncy Castle as-is, consider using j2objc
We recently encountered the same situation and so far have had luck with using j2objc to convert both Bouncy Castle and the code that was using it to Objective C. We needed strong compatibility between the iOS and Android versions of the app and didn't want to risk finding out there were incompatibilities with our solution down the road.
In order to convert Bouncy Castle we had to remove a handful of LDAP-related classes (which we didn't have a need for anyway) but beyond that it was pretty straightforward. We did this through trial and error, seeing what it couldn't convert and then just removing the file and trying again.
Using j2objc also had the advantage of letting us port over a lot of the business logic and avoid having to re-implement it in Swift/Objective-C. We just created some simple wrappers in Swift for the classes we needed to use directly and used those throughout the app.
Important Caveats
It's worth noting that this isn't a solution for everyone though, as mentioned in this comment on an issue there are some potential ramifications to using Bouncy Castle this way, so make sure you know what you're doing. It's also something that takes time and know-how to set up, between understanding potential Java classpath issues and figuring out how to pull in and convert everything you need (ideally using shell scripts or something similar to automate the process for when you have updates).
So unless you're using a lot of Bouncy Castle features this may come with additional complexities that make it not worthwhile, particularly the US Export Compliance piece.
I just did a cursory search (which I'm thinking you may have also done) and I found the "GPGTools" project, which is basically an Open Source OpenPGP implementation.
And since it's derived from OpenPGP, the keys you create should be compatible with the keys created on the Android side. They have an OLD (circa 2011) project page here, but the current code (which is in a state of flux) can be found on GitHub.
Related
I am using the open source MobSF security framework to scan my Swift project's source code and its dependences for vulnerabilities. Most things look pretty good however I'm concerned that it is showing me that encryption algorithms (MD5, SHA1) in my dependencies are not sufficiently secure.
What would be standard practice for solving this? I made sure to pull the latest branches for most of these but they seem to insist on using outdated algos. I am reluctant to go in and have to change their source code only to have it wiped out each time I rebuild the Podfile.
First, it depends on why they're using these algorithms. For certain uses, there are no security problems with MD5 or SHA-1, and they may be necessary for compatibility with existing standards or backward compatibility.
As an example, PBKDF2 is perfectly secure using SHA-1 as its hash. It doesn't require a very strong hash function to maintain its own security. It's even secure using MD5. Switching to SHA-2 with PBKDF2 doesn't improve security, it's just "security hygiene," which is "avoid algorithms that have known problems even being in your code, even if they cause no problems in your particular use case." Security hygiene is a good practice, but it's not the same thing as security.
For other use cases, the security of the hash function is critical. If a framework is authenticating arbitrary messages using MD5, that's completely broken. Don't take this answer to suggest that algorithms don't matter. They do! But not in every use case. And if you want to decode credit card swipe transactions, you're probably going to need DES to be in your code, which is horribly broken, but you're still going to need it because that's how magnetic stripes are encrypted. It doesn't make your framework "insecure."
When you say "but they seem to insist on using outdated algos," I assume you mean you opened a PR and they rejected it, in which case I assume they have a good reason (such as backward compatibility when there is no actual security problem). If you haven't, then obviously the first step would be to open a PR.
That said, if you want to change this because you feel there is an actual security problem that they will not resolve, or purely for hygiene, then with CocoaPods you would fork the project, modify it, and point to your own version using the source attribute to the pod keyword.
Maintaining a cryptography framework myself, I often get bug reports that are simply wrong from developers using these scanners. Make sure that you know what the scanner is telling you and how to evaluate the findings. False positives are extremely common with these. These tools are useful, but you need to have some expertise to read their reports.
I have to develop library for 3rd party. This library have to be secure so that only parties that have credentials can use it.
I am going in a direction that I will provide API key that 3rd party app will have to enter it in order for library to work.
Is there any possibility that I do some sort of locking of a Cocoapod? Or is Framework better solution for this kind of problem?
Does anyone have any other solution/suggestion?
It would be better if you elaborated a bit on what exactly you are trying to achieve and what type of task this library performs, maybe give some examples. If I understand you correctly, you need to prevent usage of library by those who did not pay for the service etc.
The key approach will be OK if the library is a client for some webservice. In this case, you should have API keys anyway to protect the API itself, so the client library will just forward this key to the webservice. This approach is widely used in lots of client libraries.
If the library does work only locally (for example, it performs some science-heavy computation / computer vision / etc), then you can just give out the compiled library and license to those who have already paid. You can protect it with a key of course, but it is not too useful, as the key will likely be validated locally, therefore it can easily be compromised or reverse engineered. So the only good way will be to distribute the library to those who purchased / requested trial, and force upon them a license which will restrict the library's usage.
EDIT
If by "Cocoapod" you mean "distributing as source code" and by "Framework" you mean "distributing as a binary", then it depends on what exactly you do in the library. If it is just connecting to the endpoint and marshalling data (e.g. parsing), you can just distribute the source version, as there is no "know-how" to that. On the other hand, if there is something business-related and specific done besides contacting the API, use closed source distribution (binary).
Source distribution has a benefit that you don't have to recompile it if new target architectures appear. It is also easier to distribute via CocoaPods, and your library users will like it more (for a variety of reasons).
I have seen a plethora of projects roll their own things instead of using well tested libraries.
In some other instances I have seen people re-implement Elliptic Curves and Random Number Generators, refusing to use tested libraries, because their code is "better".
Why do people do this, choose to spend their time implementing something instead of using something that has been already done, tested and deployed in a plethora of systems?
For example, the Signal Android messenger app has the whole, full copy of OpenSSL embedded into itself for encryption. Ref
Why not use BouncyCastle or java.security.*?
Is it a ego thing? Is it a trust thing, ie. they don't trust libraries?
It can be for a host of different reasons.
Build vs. buy (or use by reference) should come down to a thorough analysis. That said, many folks get into programming because they like building things. Sometimes it's rewarding to build your own code (even when a third party library exists).
That said, I'll try to list some reasons why you might not want to use third party libraries:
Licensing: Does the third party library licensing conflict or restrict your intended usage of your code? For example, GPL-licensed code may not be the best pick for something used commercially.
Security: Has the third party code been thoroughly analyzed for any security vulnerabilities? If it's public-facing, then have there been exploits in the past that have targeted this code? If so, then how quickly have the contributors fixed things (or have they even bothered to issue a patch).
Ease of use: For example, I may not want to try to use a C++ library in C# code. It's possible, but it's less straightforward than using a C# library.
Bug fixes: Is development ongoing on the third party library? If there's a bug, then how easily can you get it fixed?
Domain knowledge: We can't specialize in everything. Using your example of encryption, I'd strongly discourage attempting to build an encryption library from scratch unless you have an encryption background.
Simplicity: Your use case may be much smaller than what a third party library is built to provide. For example, if you needed to build a Point class to represent an X,Y,Z point, then you could reference a third party graphics library. But if you don't need the ability to do graphics calculations on 3D space, then referencing an entire graphics library might be overkill.
All this said, there are many times using a third party library works (and is the appropriate choice). Using your example, I'd never try to implement an encryption stack on my own -- there's no reason to do so with the plethora of open-source options available.
I have been working on an app that uses Parse as its backend and while this works well, I don't want the app to become too dependent on Parse to work. Having the apps own Core Data implementation is probably the best way to go but the implementation must be flexible so that it can support syncing etc. I have been looking into frameworks like Ensembles, MagicalRecord, iOSDataManager and a number of others. I even looked at FTASync but this has not been updated for years and does not have a good reputation. I felt to ask the community what others may recommend as a good design of a backend system to sync with Parse or other web service. Particularly considering how important the backend is...
Thank you
I have used Ensembles, and I recommend it highly. The open source version is probably fine for your use, with the version 2 version available if you find you need any of the benefits for the paid upgrade.
If you want to see how to build a backend agnostic interface, then I also highly recommend studying the ensembles framework, especially how the interface for the cloud file system interface.
I have implemented my own backend for a specific project, and the interface is quite clear, and extremely useful for teaching one how to design and build such an interface.
I'm trying to find a straightforward way to consume arbitrary iOS libraries from MonoTouch. At the moment, I need this calendar functionality, but the question applies to any such component.
I've read the Xamarin article on creating iOS bindings, but the process of building these bindings looks so complex (and tedious and likely error prone) that I think it would actually be easier for me to re-implement the given functionality in C# from scratch than it would to go through this process. Creating these bindings would require a deep dive into ObjectiveC, and I'm using Xamarin precisely so I don't have to do that.
As it stands, I am torn because I really want the ability to access some iOS libs, but don't have the time to master this process enough to create these bindings. Is there any other way to access these libraries?
(I wonder if there is or could be any sort of automated binding generator? It seems to me that 95% of the work is boilerplate translation of ObjectiveC headers to C# idioms, and an automated tool could do this, and then the final tweaking could be done by hand.)
You can:
Consume the ones that are already bound: you can find many on github, in particular in monotouch-bindings, and in the (just announced) Xamarin's Components Store;
Bind them yourself. That does require some Objective-C knowledge. Some tools/scripts exists but, in the end, the manual by hand editing is where the Objective-C knowledge is needed. There are general unit test (e.g. for Touch.Unit) that you can re-use that will dramatically reduce the number of bugs in them (blog post will be coming up soon to describe them in details).
Convert (or write from scratch) some into C# components;