I use webView to preview documents like PDF,Word,PPT. My requirement is to check whether the document is password protected before loading into the webview.
I use below function for PDF
bool CGPDFDocumentIsEncrypted ( CGPDFDocumentRef document );
I just wanted to know how to find out document is password protected for word, ppt,other documents.
Please provide the possible ways to accomplish the above requirement.
The only way to tell is something is encrypted is to be able to tell if it is not encrypted and the only way to tell that is to look at the data and see if it makes sense. Look at each type of file and check for something that must be there, usually there is a pre-amble that can be checked.
An example: a .jpg file will always start with the 4 byte Application marker: 0xff 0xd8 0xff 0xe0.
For all the file types you want to determine encryption of lookup the file formats and write code to verify them.
Encryption changes the data bytes in such a way that they can not be discerned from random bits and bytes, if it is possible to tell anything from the encrypted bytes the encryption method has failed. That is the whole point of encryption.
Related
I am using 'RijndaelManaged' and 'CryptoStream' classes in C# to encrypt files. Before encrypting the files, i want to check whether the file is already encrypted or not.
I tried using File.GetAttributes() method to check for Encryption but it is not working.
I need some tips on ways i can check whether the file is already Encrypted or not.
Without any sort of custom headers, the only way to be absolutely sure the file is encrypted is to attempt to decrypt it.
If you attempt to compress the file and it gets smaller, then it is extremely unlikely to be encrypted. If there is a non-uniform distribution of byte values (including plain text!), then it is unlikely to be encrypted.
Those heuristics depend on proper execution of the encryption. If AES is applied to a file one block at time, then patters can emerge in the result, but since you are using CryptoStream this shouldn't be a problem.
If your own code will always be used to encrypt and decrypt the files, then you should consider adding a custom header that indicates it is an encrypted file.
Suppose I have a file F containing ciphertext X, which is the enciphering of plaintext Y with key Z.
I wish to ensure that the plaintext Y can only be determined by someone who possesses both key Z and key Q. (I can think of a number of reasons why I might wish to do this.)
I therefore wish to encrypt the already-encrypted file with key Q.
You're telling me that your system wishes to detect that F is already encrypted, and then refuse to encrypt it with key Q?
That seems like a bad idea. I might want to encrypt the file with key Q irrespective of whether it is already encrypted with key Z or not.
You have to inspect the file and look for structures, or byte strings that would not be there if the file is encrypted. You would need a separate test for every type of file you are dealing with.
If the file is encrypted it will appear as a stream of random bytes. You can:
Attempt to open the file and/or confirm that it is of the expected format (JPG, ZIP, whatever). If the file matches a known format then you know it is decrypted.
Attempt to decrypt the file if you have the key, then repeat the previous step. If it now matches a known format then you know it is (was?) encrypted.
I would suggest rename the encrypted file at encryption process with something with you can check it when you want to decrypt it.
Set your encrypt method bool type, if the file can decrypt, then the method return true which indicates the file is encrypted, otherwise the method throw exception and return false which indicates the file cannot be decrypted, or say the file is not encrypt.
I've been going around in circles from Apple's CCCrypto docs, frameworks and other SO answers and am not making any headway.
I think I need to figure out how to get a IV from an encrypted string that I receive.
I receive a JSON payload which contains a String. That string is encrypted in AES-256-CBC. (From a Laravel PHP instance that I think uses OpenSSL). The string itself, decrypted, is another JSON object.
I have a pre-defined key.
The string I receive looks something like:
eJahdkawWKajashwlkwAkajsne8ehAhdhsiwkdkdhwNIEhHEheLlwhwlLLLLhshnNWhwhabwiIWHWHwh=
(but is a lot longer).
I'm trying to use this answer here: Issue using CCCrypt (CommonCrypt) in Swift
But am a) unsure if I'm properly converting the string to data and b) how to get the IV (initialization vector) from the string I receive.
Using that answer I do get "success" however when I try to pass it to the NSJSONSerailizer I never got a good result (it always fails) but I do get data out - I think it's garbage.
Edit:
I really mis-understood my original problem - I was receiving a base64 encoded string that I needed to decode into JSON (which went fine). Then using the linked answer and importing CommonCrypto I thought I'd be able to get usable data but I am not. #Rob Napier 's answer is extremely helpful. I think my problem is that the instance of laravel in question is using OpenSSL.
There is no really commonly used standard format for AES encrypted data (there are several "standard formats" but they're not commonly used....) The only way to know how the data you have is encrypted is to look at the documentation for the data format, or failing that, the encrypting code itself.
In good encryption formats, the IV is sent along with the data. But in many common (insecure) formats, there is a hard-coded IV (sometimes 16 bytes of 0x00). If there's a password, you also need to find out how they've converted the password to a key (there are several ways to do this, some good, some horrible). In a good format, the key derivation may include some random "salt" that you need to extract from the data. You'll also need to know if there is an HMAC or similar authentication (which might be stored at the beginning or the end of the data, and may include its own salt).
There just isn't any good way to know without documentation from the sender. Any decently encrypted format is going to look like random noise, so figuring it out just by looking at the final message is pretty hard.
If this comes out of Laravel's encrypt function, then that seems to be ultimately this code:
public function encrypt($value)
{
$iv = mcrypt_create_iv($this->getIvSize(), $this->getRandomizer());
$value = base64_encode($this->padAndMcrypt($value, $iv));
// Once we have the encrypted value we will go ahead base64_encode the input
// vector and create the MAC for the encrypted value so we can verify its
// authenticity. Then, we'll JSON encode the data in a "payload" array.
$mac = $this->hash($iv = base64_encode($iv), $value);
return base64_encode(json_encode(compact('iv', 'value', 'mac')));
}
If this is correct, then you should have been passed base64-encoded JSON with three fields: the IV (iv), the ciphertext (value), and what looks like an HMAC encrypted using the same key as the plaintext (mac). The data you've given above doesn't look like JSON at all (even after base-64 decoding).
This assumes that the caller used this encrypt function, though. There are many, many ways to encrypt, though, so you need to know how the actual server you're talking to did it.
Ok. I have experienced this problem for quite sometime. Feeling like I am getting close, just need to be pointed in the right direction. So I am using this cool third party library called FBEncryptorAE:
NSString * encryptedMessage = [FBEncryptorAES encryptBase64String:localQuery keyString:key separateLines:NO];
When I post this encrypted query up to my server, I get the following error:
The AES/CBC/PKCS7Padding algorithm is not supported by the Security Provider you have chosen
Here's what my constraints are:
128 bit key
AES/CBC/PKCS5Padding, Base64
coldfusion
Based off of my readings, PKCS5Padding/ PKCS7Padding are the same thing?? If someone could be kind and help me understand:
Why I am getting the error.
Is there sample code I can view based off of my constraints I have? Appreciate any help.
PKCS5Padding and PKCS7Padding produce the same result for AES, are essentially the same.
If you are using CBC an iv is required. How is the iv made the same for both encryption on iOS and decryption on the server? FBEncryptorAES has iv capability but only for (raw data) not (base64) so it is defaulting to "nil" (from the docs). You must get this correct. Since FBEncryptorAES does not support what you need you need to use the (raw data) API and then Base64 encode with the NSData method base64EncodedDataWithOptions:.
Ensure that the key and iv are exactly the required size, for AES128 that is 16 bytes for each. Some wrappers expand undersize keys but there is no standard for that, Common Crypto does not.
Hex dump the input and outputs of all all parameters and data on both sides to ensure they match.
The problem with wrappers is that they are rather opaque as to what is actually being done and that can create interoperability problems. For this reason I always use Common Crypto and the NSData base64 encoding/decoding so I know exactly what is being done.
there exist some sample code for an Http Server in the Dart:io section.
Now I will distribute images with this server. To achieve this, I read the requested image file and send its content to the client via request.response.write().
The problem is the format of the read data:
Either I read the image file as 16bit-String or as Byte Array. Neither of them is compatible to a raw 8-bit array, which I have to send to the client.
May someone help me?
There exist several kinds of write-methods in the response class.
write
writeCharCode
add
While "write" writes the data 'as seen', "writeCharCode" transforms the data back to raw-format. However, writeCharCode prepends some "magic byte" (C2) at the beginning, so it corrupts the data.
Another function, called add( List < int > ) processes the readAsBytes-result as desired.
Best regards,
Alex
When i backup my blackberry using blackberry desktop mananger, it saves it as an .ipd file.
its in hex... Not sure if its any particular type. But i used software called ABC amber Text Converter to convert this .ipd file into plain text format. And some of it comes out as plain text, Like all the messages saved in the backup file. But some of the text in the file looks like this:
qÖ²u_+;¢õ¿B[[¤†D`Ø,>p
|Cñ:ÌQ†nÁä¼sÒ®sKDv©{(]
)++³É«.gsn>
z
'‚51o4Kq
8Ütâ¯cí¿þ2´Õ|5kl$S,H
dbiIjz
*!~k$|
&*OÝ>0ðîwã
+zno%q
2k;
YnÁÅŸ5|Xñ7Ú<}y2
A
V܉lO5‰<œtÅRI-I
Does anybody have any idea What the hell this is or if there is Any way i can decode this?
Thanks
It's just binary data. You may have been able to extract some text from the file where strings of text were stored, but the rest will be just bytes of data.
You'll need a specific program that understands these backup files. A quick google reveals a few choices, such as MagicBerry.
One of the Blackberry developers has helpfully blogged a bit of information about the binary format, so you could try using that to write your own program to parse it:
http://us.blackberry.com/devjournals/resources/journals/jan_2006/ipd_file_format.jsp