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.
Related
I'm using Airdrop to transfer application internal data between two phones. Because Airdrop was intended for file sharing, it could occur that user choose "save the file" to save the data file in Files app by accident. Since my app is a financial planning app, I'm considering to encrypt the file transferred by Airdrop to keep user's data secure. The encryption only applies to the temp file transferred by Airdrop. Once the app on the receiver phone receivers it, it decrypts the file immediately.
I'm referring to this thread to determine how I should answer the export compliance question if I encrypt the temp file. And I noticed these two exemption items:
(iii) your app uses, accesses, implements or incorporates encryption with key lengths not exceeding 56 bits symmetric, 512 bits asymmetric and/or 112 bit elliptic curve
(iv) your app is a mass market product with key lengths not exceeding 64 bits symmetric, or if no symmetric algorithms, not exceeding 768 bits asymmetric and/or 128 bits elliptic curve.
I don't quite understand the difference between the conditions in the two items (what is a mass market product?). But I don't think either helps, because the ciphers provided by iOS Cryptokit contains only AES and ChaChaPoly - the former takes a minimum key size of 128 bits and the latter takes 256 bits key size.
Since there are a lot of apps using Airdrop to transfer application internal data (I can tell that from the discussions on SO), I wonder how other people deal with this? Is this considered an exemption case?
BTW, I considered other options, but none is satisfying:
Don't encrypt the data. Obscure it instead (for example, using something like Caesar cipher). But that feels very unprofessional.
Don't use Airdrop. Implement my own data transfer mechanism. For example, start a tiny web server on sender side and the receiver side get the data through HTTPS, which from my understanding is an exemption case. I don't choose this approach because a) Airdrop provides a much better user experience than this approach, b) I'll need to use Bonjour to discover service, which requires local network permission. I'd like to avoid that if possible.
The answer depends on what cipher you use to encrypt the data.
Apple summarises your requirements in a couple of documents.
First, in the CryptoKit documentation
Typically, the use of encryption that’s built into the operating system—for example, when your app makes HTTPS connections using URLSession—is exempt from export documentation upload requirements, whereas the use of proprietary encryption is not. To determine whether your use of encryption is considered exempt, see Determine your export compliance requirements.
This leads you to this document which has a table, that I have shown in part:
Assuming that you use AES from Apple's Crypto Kit framework, the second clause would apply. You don't need to provide any documentation to Apple but you should submit a self classification report to the us government.
The exemptions you listed in your question do not apply since you wouldn't use a symmetric cipher with a key length of 64 or 56 bits.
I need to implement jcryption in IOS. I have gone through the library it uses Rijndael encryption internally to encrypt the data.
I have tried AES256EncryptWithKey but it is not giving me expected encryption key.
Any help on this would be nice. Thanks
Rijndael with a 128-bit block size is AES. Use Common Crypto on iOS, it uses the hardware encryption engine. There are several ObjC AES answers here on SO, see iOS AES Encryption.
For a detailed answer you will need to provide your usage information on jCryption.
Also notice that jCryption has been discontinued. If you are trying to use jCryption in place of HTTPS the correct solution is to use HTTPS, see jCryption.
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
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 am building a Monotouch application which downloads data from the server encrypted using AES. I then need to decrypt this data when the file is accessed.
What is the best way for doing this using MonoTouch? iOS AES decryption is apparently hardware accelerated and so I would ideally like to call into CCCrypt. I am a bit of a n00b to MonoTouch so does anyone know how to do this?
Or alternatively is there a better approach to doing AES decryption in MonoTouch?
MonoTouch provides AES support inside it's class library, e.g. the RijndaelManaged class.
However you need to know a bit more about how it was encrypted (cipher mode, padding mode, key size) to be able to decrypt a file. Also depending on the file size you might want to decrypt it in memory (safer) if it's small or to a temporary file (if large).
Notes:
Rijndael is the original name of the algorithm that got selected to be AES;
AES is a subset of Rijndael (only one block size, 128 bits) so you can do everything AES supports using RijndaelManaged;
At the moment MonoTouch does not use CommonCrypto (it uses the managed implementation from Mono) so you won't get hardware acceleration. This will likely change in future releases (and will be compatible, i.e. simply re-compile, for people who used RijndaelManaged in their applications).
EDIT
MonoTouch 5.3.3 (alpha) now default to use CommonCrypto implementations, including hardware acceleration (when available) for AES and SHA1.
If you are interested in encrypting data at rest (i.e. a database) under MonoTouch SQLCipher might be a good option (http://sqlcipher.net). The MonoTouch provider for SQLCipher provides SQLite full database encryption using AES-256 (http://sqlcipher.net/sqlcipher-for-monotouch). There is also a companion library for Mono on Android, which provides the same API and features for android (http://sqlcipher.net/sqlcipher-on-mono-for-android)
Disclosure: I work for Zetetic, the author of SQLCipher.