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!
Related
I am using cryptography to implement some blockchain application, after I looked code, I don't know how to distinguish SHA2-256 and SHA3-256.
The Elliptic Curve Digital Signature Algorithm (ECDSA) supports any hash function not limited to the SHA family, as MD5. SHA-3 should be supported, yes, indeed, I recommend using it as it is a open contest standard and improves security.
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 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.
I'm currently using a modified HTTP::Daemon::Threaded server in
combination with SOAP::WSDL and Pod::WSDL to provide web services
used by a variety of client types and roles.
---- that's not the question, the following is -----
I'd like to arrive at an optimal solution (as far as is possible) with respect to the following topics:
Request/Dispatch/Response speed
Protocol security (proper use of client-authenticated SSLv3/TLS)
Resource security (security roles/traits on per-resource & per-method bases)
Declarative specification of types, method signatures, and required security roles & traits.
Questions:
I'd like to be using an IO::Select or IO::Async::Loop::IO_Ppoll -based server, but I understand that this is not compatible with in-server client authenticated SSL. Is my understanding correct?
I'd like to move away from verifying the client certificate on each request, to something like CA SiteMinder, where I give out a time-limited session cookie after successful client certificate verification, which can be used on subsequent requests to avoid this time penalty (and to lessen server load). Is this going to be as secure? (or even good enough?)
Is there some module/framework I can build on to provided Trait and Role -based Authorisation for the exposed object and methods. Pod::WSDL really only deals with types (and not even complex ones). I'd like to use/implement some declarative annotation (or external YAML) -based scheme to handle complex WSDL typing as well as Trait & Role Authorisation. Has anyone done this? (even separately?) Are there any other modules which might be a good starting point?
Finally - Am I just crazy for doing this in Perl5 ? ;)
Ok, everyone's answering everything but the real questions.
I'll break this out into specific questions in separate posts, and won't make any mention at all of the server make-up - a topic which everyone in this thread seems to want to discuss, and which is completely irrelevant.
I know this is an old question, but FYI IO::Async will work just fine with SSL, ever since the IO::Async::SSL module.
You're crazy for doing this in Perl :-)
Seriously though, more power to you. My question is, presuming you have some reason to reinvent this wheel, is why not consider Python? Perl is alive and well but so much of this kind of thing (low level scripting) is being done in Python now.
Finally, presuming you don't have an actual reason to be doing this (aside from fun), you should really consider a Web Framework (Django of course) and something like nginx to handle the HTTP interaction.