I googled but mostly found links to 3rd part libraries for encryption/decryption works. However, I saw Security articles on the Apple site, though without examples.
Can you please show me an example of a simple encrypt/decrypt a string with a key function?
Security and CommonCrypto are low level frameworks. They only provide security primitives, not a full encrypted data format. It is challenging to build a secure format out of the primitives, and most examples you'll find online are insecure. Either the author did not know how to build a secure format, or the author assumes you know how to take what they've written and finish building a secure format.
There is no such thing as "decrypting a string" in the way that you likely mean. All encryption functions generate raw bytes. If you want a string, convert it to base64 or hex or whatever. Some libraries automatically add this, but it often leads to strange artifacts like double-base64-encoded data.
If you want a cross-platform "out of the box" encryption format, see RNCryptor or libSodium. Both of these convert data-to-data. If you want strings, just encode and decode the data as you like (usually as base64 or hex).
What I have found you can have a look at this url : Swift Default Encryption
Related
Good day everyone! I've been using AFNetworking 2.0 for a quite a while and because input was always of https with json - never had any problem. Yet now we have a custom written on C server which works only with HTTP and sends encrypted raw byte data.
As far as I understand it's necessary to use some sort of serializer , but i can choose only from: AFHTTPResponseSerializer/AFJSONResponseSerializer/AFXMLParserResponseSerializer/AFXMLDocumentResponseSerializer/AFPropertyListResponseSerializer and none of them seems to fit.
What's the best solution?
As result i need decrypted NSData which i can parse byte by byte.
All the possibilities of encryption rule out a standard ResponseSerializer. Some of the encryption properties include algorithm, key, key size, mode, possible iv and padding.
The solution is to decrypt the received data in a separate step.
In order to decrypt the data you need to know the algorithm, it's parameters and the encryption key. It is also possible that additional encryption information is added to the encrypted data such as an iv, KDF reputation count, etc. You need to obtain this information from the server developers.
I would like to apply the encryption & decryption technique in one my downloading concept. I want to do the partial encryption using AES 256. Is it possible to do it? is it have any algorithms available for partial encryption&decryption.
Please suggest ideas.
Partial Encryption : it means i dont want to encrypt the full content of the file.It will do the encryption for some specified part of file.(like 10% or 20%) or some junks of file content. basically , I dont want to do the encryption to the entire content
THanks.
I'm not aware of any algorithms that offer "partial encryption" functionality. Instead, I think you'll need to take charge of separating out the bytes you wish to encrypt and pass that through standard AES encryption code.
I need to be able to decrypt a chunk of AES256 encrypted data with iso10126 padding from an uncontrolled server. CCCrypt seems to only support "kCCOptionECBMode" and "kCCOptionPKCS7Padding" as options, so the CommonCrypto library seems incapable of what I want. What is the best solution?
I would also like to be able to use iso7816 and iso10126 padding, but they are less of a priority. I know these padding options were deemed "possibly insecure", but as I can't control the data source, I would like to be able to decrypt with these settings still.
I'm fairly certain these AES encrypted pieces of data are encrypted by the CryptoJS javascript library, (it has all of the padding options mentioned above). I'm aware that I can use this library through a UIWebView and get the result back in Objective-C, but I'd like more speed than what the javascript library can offer.
Thanks!
Padding is one of these things that you can actually program yourself (unlike many other cryptographic algorithms). Just decrypt without any padding, and do the unpadding yourself to get the plain text. If you encrypt, obviously first pad, then encrypt. Almost all libraries support something like "NoPadding". You can simply find how all padding modes work by looking at the Wikipedia page.
Be careful that you always pad/unpad for your given modes. So you may have to add a full block of padding bytes.
Note that ISO 7816 padding does not really exist. It is ISO/IEC 9797-1 Padding Method 2, which is used on bytes instead of any number of bits. The fact that it is used (not defined) in ISO/IEC 7816-4 for secure messaging (informative) does not make it part of that standard.
Other question/answer for no padding:
iOS encryption AES128/CBC/nopadding why is not working?
this link should show you how to perform no padding encryption/decryption using the iOS API.
A colleague provided me two text files he encrypted using GNUPG, AES128/AES256 with no salt.
Using the following example, https://stackoverflow.com/a/1400596/300972, I tried to decrypt both files in an iOS application, one using the AES256 example, the second by modifying the algo to kCCAlgorithmAES128 and keysize to kCCKeySizeAES128.
Loading the files to an NSData object proved successful; I am able to output the NSData. However, on decrypt they always fail with kCCDecodeError (-4304). I thought it may be the padding, so we tried different variations, the original being kCCOptionPKCS7Padding, still the same error. I tried a padding of 0, which provides a truncated NSData object which I cannot create an NSString from. (UTF8 encoded).
Has anyone been successfully able to decrypt a file encrypted using GNUPG in an iOS environment? Can you provide us with lessons learned?
GnuPG writes in the OpenPGP file format (RFC-4880). This is a fairly complicated format and you would need to parse it before you can even begin to decrypt the data. GnuPG also compresses the data before it encrypts it. And it uses "OpenPGP's variant of Cipher Feedback (CFB) mode." While iOS 5 supports CFB, this isn't quite the same as RFC-4880. For instance, they don't use a normal IV, and they synchronize in a novel way to provide a "quick check" that is incompatible with standard CFB. Then there's their String-to-Key (S2K) algorithms, which are not the same as PBKDF2.
In short, CommonCryptor is the last in a long series of steps of tearing this down to something to hand to AES. You could look at libgcrypt, but its LGPL license is generally incompatible with iOS development. You should probably investigate other OpenPGP implementations. I know there are some in JavaScript (which is crazy, but could still work without creating licensing headaches). Maybe Cryptlib (which has a commercial license).
Personally, I'd go with some other encryptor if you can. OpenSSL, while not particularly secure, is very portable, and as easy to use as a commandline app. RNCryptor can read and write it on iOS.
You can check ObjectivePGP framework.
I have an erlang program which generates data. This data needs to be transferred via udp to a non-erlang program for further processing. I already have this part working - sending the data via udp and receiving it on the other non-erlang side.
Here's the problem. The data (erlang terms like tuples containing lists) doesn't seem to be able to go over "as is" (i.e. I can't just send arbitrary erlang terms). It apparently needs to be converted to either text or binary first. Converting to binary seems easy enough with a bif I found. The problem is, binary gobbledygook comes out the other side, and I don't know any easy way to decode it (the other side is non-erlang).
Barring someone telling me some easy way to decode binary gobbledygook on the other side, I'd like the data to be sent as a simplistic string representation of the terms - for instance a tuple like this:
{[1,2,3],[4,5,6]}
sent like this:
"{[1,2,3],[4,5,6]}"
I haven't seen any such bif, i.e. "convert_term_to_ascii/1" etc. I know I could scan it and send token representations of the terms, but I don't want to do that - decoding that on the other side is just a pain I don't want to deal with.
I know I'm not the first, second, or third person to have this problem. It has to be fairly common. How is it normally dealt with?
Can someone point me to some resource showing me how to either 1) convert binary gobbledygook to ascii (needed on the non-erlang side), or 2) straightforwardly convert terms to a string (needed on the erlang side)?
Or, tell me how I'm wrong and how I should really be doing this?
Thanks.
1) you can convert any term to string using
R= io_lib:format("~p",[yourtermhere]),
lists:flatten(R)
2) you might look at erlang external binary format, a lot of other languages have libraries for encode/decode that erlang binaries format. And in erlang you can encode any term by term_to_binary
I'd recommend converting the erlang terms into JSON, with either of known libraries (heard good words regarding rfc4267). It'd be a trivial task to convert JSON back with any non-erlang platform, I guess. )