I am trying to decrypt some data using Jasypt. The data was not encrypted using Jasypt but using 3Des(TripleDes). To provide more info on the encrypted data, the algorithm used is DESede, encoding is UTF-8, transformation is DESede/CBC/PKCS5Padding and this is Base64 encoded.
Is it possible to decrypt this data using Jasypt?
I have checked a lot of Jasypt related topics and cannot find any clues. I get exceptions varying from org.jasypt.exceptions.EncryptionOperationNotPossibleException when I set algorithm to PBEWithMD5AndDES, to org.jasypt.exceptions.EncryptionInitializationException: java.security.spec.InvalidKeySpecException: Inappropriate key specification when I set the algorith to DESede.
Please point to the right direction...
I think you should install jce.
This Link may be help you.
Related
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'm using the RNEncryptor and RNDecryptor classes for encryption and decryption as follows:
NSData *encryptedData = [RNEncryptor encryptData:input
withSettings:kRNCryptorAES256Settings
password:thePassword
error:nil];
NSData *output = [RNDecryptor decryptData:encryptedData
withSettings:kRNCryptorAES256Settings
password:thePassword
error:nil];
The first time I have to encrypt data in my app I generate a password using the RNCryptor class as follows:
NSData *thePasswordData = [RNCryptor randomDataOfLength:32];
NSString *thePassword = [aesPasswordData base64EncodedStringWithOptions:NSDataBase64Encoding64CharacterLineLength];
I save this generated password in the app's Keychain and use it for all subsequent encryption and decryption.
Is this a good strategy for encryption/decryption or can anyone see any flaws in it? Should I instead be generating an AES key and storing that in the Keychain and working with that rather than a password?
Edit: I changed above how I generate the password from using the NSProcessInfo class to using the RNCryptor class based on Rob Napier's answer. That aside I'm still curious to know whether the strategy in general of working with a password rather than an AES key is correct and secure.
This is not a good way to pick a password. globallyUniqueString can be quite predictable in many of its bits. You're much better off using something like RNCryptor.randomDataOfLength to generate a blob of desired length (32 bytes would be ideal), and then base-64 encode it to get a password.
Using randomDataOfLength to generate keys instead wouldn't really be any more secure, but it would be faster (by 10s of milliseconds depending on the device, if that matters to you). In general, I recommend using the password interface unless you have a special problem where keys are particularly helpful. Keys are just a little harder to use correctly.
The actual encryption key used by these libs is derived from the password, if you use one, but, IIRC, salted so it isn't intrinsically less secure.
There are concerns regarding the theoretical level of security provided by these libraries, (see How to correctly encrypt data with proper authentication using AES-256-CBC in php?) but you have to make a judgement call on that. Thing to bear in mind is that RNCryptor is a set of libraries (which may have published attack vectors in different implementations) AND a consistent format, which is useful if you want to move encrypted data across platforms.
Personally, I would feel more comfortable with using a unique, random AES key for each encryption and storing that key encrypted with RSA stored in the keychain.
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.
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.