I need an obvious example about AES decryption. i just want to know how it works in order to make my own coding of this algorithm so, I neither want code nor algorithms, i just want some explanation of how it works, I need to understand it first before i can make an implemetation fir it. Can someone give me tutorials or references?
How about Moserware's A Stick Figure Guide to the Advanced Encryption Standard (AES)? It's clear and entertaining. Don't forget to sign and date the Foot-Shooting Prevention Agreement.
Related
I'm developing an app that uses ECDSA for identity management, a steep learning curve wrt best practices. Is it wrong or just bad form to leave a signed message visible or discoverable? The data being signed is hashed (or at least, it will be soon).
Any advice is greatly appreciated, or references to reading material...
Thanks!
can someone give me a tutorial about key paths in Cocoa KVC concept, because I can't understand them. I understand what they do, but how they do it? I'll really prefer a tutorial with sample example, all tuts I could find are with very low amount of information, and examples are missing most of the times.
Thank you
Congratulations, it's your lucky day! It turns out, apple thought that this would be important too, so they created a shiny and fancy guide for you right on their site, which you can view here.
Surprisingly I was not able to find a tutorial along with a sample code that is easy to attain.
The following web page on KVO and KVC is very short, simple, with code, and explains the most basic concepts of KVC and KVO very well.
I need a push in the right direction - preferably with code samples/links - for how to encrypt an NSString using DES encryption algorithm. Knowing that it is not that secure, but a possible candidate for avoiding to file a CCATS.
Could commoncrypt be the solution?
Or would using the key chain or sqlcypher be able to provide encryption and avoid the CCATS paper work.
In my app, i dont see any issue with 56 bit security and i dont assume any issue with a symmetric key solution.
In short:
I can't find any good example of how to use 56bit DES symmetric encryption for my ios 4.2 app (This is to avoid the CCATS hassle)
Why don't you use the Security.framework?
I would like to encrypt a few of my obj c classes in my iphone game which handle openfeint data and classes which handle scores.
I have heard there is a way to encrypt this data to act as another level of security, at least enough to discourage some from cracking it and forging scores on a jailbroken iphone and then spam the leaderboards.
How is this done, what are good techniques to secure this data and discourage some from attempting to spoof data?
Thanks
To truly encrypt compiled code is probably more trouble than it is worth. You have to isolate the code that will be decrypted into a dynamic library and load the library manually after decrypting it in memory. Dynamic libraries, and the other methods you might use to modify code at runtime, are frowned on by Apple when used with iOS.
With Objective-C you essentially ship with the headers build into your code. That makes it much easier to dig around in your application. Anything you can do in C, where symbols may be stripped, will be slightly harder to read. You can also use #define to obfuscate your class and method names a little. This is nowhere near encryption, but is much easier to implement and less likely to introduce wacky bugs.
#define MyNicelyNamedClass somegarblegarble
#define myNicelyNamedMethod othergarblegarble
#interface MyNicelyNamedClass
-(id) myNicelyNamedMethod;
#end
This is a relatively painless way for a developer to make their Objective-C code less obvious to others. It is about as effective as javascript obfuscation, which is to say it is one more little hurdle that will dissuade many casual attackers.
If you choose meaningful but misleading names instead of straight garbage you may even trick someone into spending hours digging through the wrong code. Not that you would ever know, but it is a satisfying thought.
Encrypting classes suffers the "shipping the lock with the key" problem that any DRM or similar security system has.
What you are looking for is self modifying code, where the code is either loaded and decrypted later by the application, or is present as machine code in the binary and modified at runtime by a key the application has.
Note that you'll likely create some very subtle and interesting bugs, and your method will be bypassed (it will take someone maybe an extra day).
I've been evaluating a framework that on paper looks great. The problem is that the sample code is incomplete and of poor quality. The supplied reference implementations are for the most part not meant to be used (so they can be considered as sample code as well) and have only succeeded at confusing me.
I know that it's common for things to look better on paper, but my experience with the sample code is turning me away from further investigation.
Do you let poor code samples change your judgment of frameworks/libraries? So far my experience has been similar to the "resume effect": if someone doesn't put the effort into spell checking their resume, they probably won't get the job...
For me, it does. I tend to want to avoid libraries where the code samples are incomplete. If the library is open source, I will overlook it, since I can directly look at the code and see if the library's internals are reasonable, and I know that, if there is a problem someday, I could (if I had to) fix it.
If the library is commercial, and their samples and/or documentation is poor, I look elsewhere. I just see it as risk management - poor samples make me fear the quality of the library in general.
No matter how good something is on paper or in theory, it can still be crap when programmed.
I think this is a valid reason to turn away from and evaluate other libraries. As a potential user of a library a lack of documentation and/or bad code samples gives the impression that the library is not yet mature enough for use by third parties. In time it may well gain the missing pieces but until then I think its reasonable to look elsewhere.
I was recently evaluating the multitude of blogging applications that people have uploaded to github.com I quickly skipped ones that no documentation as they obviously weren't ready for others to use. The ones that remained at the end had a good README with info on how to get the app up and running as well as an online example of the code running.
Poor code samples combined with poor documentation will make me turn away from a library unless there is a compelling reason to use it. However, a library that has either good code samples or good documentation is usually worth using. (Assuming that the library itself otherwise meets my needs.)
If I can't find good examples (and/or documentation) illustrating how to use the library, I'm definitely less likely to use it - just as a practical matter, it'll be harder for me to figure out how. But I don't care what the code that implements the library itself looks like. I don't think I'd choose one library/framework over another just because the developers of the one have shown an ability to write cleaner code (which is what I understand the "resume effect" to mean).
Lack of documentation and examples makes me a whole lot less likely to use that particular library. It's not worth my time testing and trying to figure out how a black box works if there are alternate solutions to the problem out there.
Yes, definitely. Every library should come with a simple example using program and a CLI interface (for very simple libraries with <3 methods and <10 hooks, one example should suffice).
And why does your framework "look great" if it's so hard to use that even the original coders make mistakes using it?
It certainly matters to me. Evidence of sloppy/incomplete coding and poor communication decreases my confidence that the actual implementation code is stable and robust.
Myself yes, but there must be people out there who aren't turned off by this otherwise there are plenty of open source projects that would have died a long long time ago.