I want to read a the content of a PDF file and encrypt the content using AES256 encryption and post the content(encrypted) as a base64 string.
for that i have 2 solution
read the content using a stream reader(PDF formated data) the encrypt the content and the base64 encoding, Finally send the encrypted string
Read PDF content and convert it into text then encrpt and then send
Which is the best method, If i use first method then there will be any problem for failure
I need your opinion Please help me
Your first method seems absolutely fine and I would certainly go for that approach. What you are essentially doing is simple transmitting a file from one machine to another.
If you consider this without encryption all you should be aiming to do would be to send the file stream exactly the same as you read it, this ensures the receiver gets the file in it's original state and can reliable open the file as it will be in the exact same format as it started.
Now when we consider adding encryption, all we are doing is change the raw binary data of the file. As long as we decrypt the file at the other end using the same key parameters we can be sure that we will still have the same original raw file data we started with (assuming we don't get any data loss during connection - you could add a hash check for this if desired, for example)
Related
I create my file using File.WriteAllBytes(). Byte[] that is passed to File.WriteAllBytes() is encrypted by algorithm of my own. You need password that was used when file was encrypted (user of the program knows the password) to decrypt it. But when some file is opened by my program using File.ReadAllBytes() there are 3 situations:
File that is being opened is my program's file and user knows the password to open it.
File that is being opened is my program's file but user doesn't know the password to open it.
File that is being opened is not my program's file.
First one is easy to handle. 2nd and 3rd are same for my program because my program doesn't know the difference between encrypted byte[] and byte[] of some random file.
How do I differ these situations? I was thinking of adding some sequence of bytes to the end or beginning of byte[] before passing it to File.WriteAllBytes(). Is that safe? How do modern programs differ their files from other files?
You can give your file some structure before encryption, and check that the structure is there after decryption. If the structure is not there, it's not your file.
For example, you could compute a check sum, and store it in the first few bytes prior to the "payload" block of data. Encrypt the check sum along with the rest of the file.
When you decrypt, take the payload content, and compute its check sum again. Compare the stored result to the computed result to see if the two match. If they don't match, it's not your file. If they do match, very good chances are that it is your file.
This is not the only approach - the structure could be anything you wish, from placing a special sequence of bytes at a specific place to using a specific strict format (e.g. an XML) for your content, and then validating this format after the decryption.
[the file is] encrypted by algorithm of my own.
Be very careful with security through obscurity: coming up with an algorithm that is cryptographically secure is an extremely hard task.
Many many file format use "Magic numbers" in front of the file to determine their types. Use the first ... 4 bytes, write a custom sequence it it then read it when you load the file.
I have the following textual binary representation: "0x255044462D312E340D0A25FFFFFFF..."
I know it's a pdf.
I know it's the textual represantation from a sql server column (image data type).
But im lost to find out how to save this binary to a pdf file on my disk and view the content.
Maybe someone can hint me in the right direction.
Best Regards and Thanks in Advance
You're correct that it is a PDF file (at least it masquerades like on. You have hexadecimally encoded bytes; the first read:
255044462D312E340D0A
%PDF-1.4<CR><LF>
So you appear to have a PDF 1.4 string.
Just take two characters from the string, treat them as hex, convert them to the correct byte and write them to a file. Write binary, not textually (you don't want to add additional line-breaks in there, PDF is too binary to let that work.
(I did the conversion using this site: http://www.dolcevie.com/js/converter.html)
I'm not sure what database you are working with or how you are getting your string that you have above.
Many databases allow you to save binary data as a blob or some other byte array type. I believe in MSSQL this is called an "image" but I am not 100% on that. I would start by looking into the two following links in order. The first link talks about how to pull byte array data from a database. The example is in Visual Basic but should be easily changed to C# if that is what you are using.
The second link contains an example of how to save that byte array data to the file system.
I would also suggest posting some of the code you have tried as well so that the community may comment and point out areas you possibly had misunderstandings on.
1.) http://support.microsoft.com/kb/308042
2.) Save and load MemoryStream to/from a file
http://www.pdfsharp.com/PDFsharp/ can read in binary data and you can call .Save() and it will make the PDF file to disk for you.
I have a winforms application that connects to a couple of databases. However, I would like my app to be used even when the user is not connected to the internet. I had been writing datasets to XML files locally and reading them in based on the user preference whether to download from the database or use a local data file.
DataSet.WriteXml(localPath)
As the application is improving, I would like to encrypt the XML file to prevent the user from looking inside (There is a bunch of data in there but the application selectively displays data based on access levels assigned to users). I looked into 'Rijndael Managed' and got a prototype working based on Encrypt/Decrypt Files in VB.NET. I have not been able to figure how to pass in a stream to cryptography classes without them ever being saved to the disk.
Right now, I save the xml file out of the Dataset to a temporary directory and construct a new stream and pass it in to CrypotoStream which then writes an encrypted file to the desired location.
I am looking for a solution to directly pass in the stream without ever writing it to the disk. Please suggest.
a better thing to use would be the EncryptedXml Class
EncryptedXml Class
Encryption can entail different approaches for cryptographic strength, key bases, etc. Follow the examples in the MSDN documentation. This is not a short implementation, but it works extremely well.
other alternatives
Write into a MemoryStream and use MemoryStream.ToArray();
to read the encrypted stream
Just use the CryptoStream to load the DataSet.
refer to this like to read/decrypt
Read/decrypt encrypted XML file and then process internally
Sounds like MemoryStream may be what you are looking for.
Hoping you can help out here. I'm creating a file an appending lines to this file using a Crypto stream.
If I write out all the lines at once then the file will encrypt/decrypt correctly.
But if I open the file in append mode, append a line, close then file. Then only the 1st line decrypts correctly, the other lines return back rubbish.
I am wondering if this is the correct behaviour. I'm trying to build up a text file of encrypted details users enter over the course of a day; and then batch processing them at the end of a day.
The overhead of decrypting and encrypting the whole file just to add a single line to it would seem to be excessive as I could end up with 1000's of lines over the course of a day.
I'm using the excact same Crypto Provider with the same Initialisaion Vector and key on all access to the file?
Am I doing something wrong or is it not possible to append to an encrypted file?
Cheers
Noel
Yes, this is expected behavior. One thing you can do is encrypt each record (text line) separately AND add a prefix that indicates beginning of the block and it's length. Then when reading from the file, read the prefix, check the record length and load the record. Repeat for each record.
I suspect the crypto you're using is a stream or chained cipher - meaning the output from one encrypted block is used to modify the next block. Directly appending to this kind of data and then attempting to decrypt the lot will not work because the dependency between the blocks will be broken.
A simple way to fix it is to add a marker or save some data for the offset+length of each record in the file. When you come to do the batch processing, you'll need to reset the CryptoProvider for each record.
We have a process that has SQL Server Reporting Services create a pdf file via
ReportExecutionService.Render
from data in the database. Then we save the byte array that Render returns to the database. Later I get the byte array and do a
File.WriteAllBytes
to write it to disk before attaching it to an email and sending it. The problem I'm running into is that after writing the file to disk, it is corrupt somehow. I'm not sure what to look at, can anyone help?
Thanks
EDIT:
I can write the file from SSRS to disk before saving the byte array to the database and I can view that fine.
If you work with the byte[] returned by render, then things are fine, but if once you write that to the DB and read it back, you have problems, correct?
Why don't you compare the array written in to the DB with the one you retrieve to find the problem? Then start looking into your DB write and read routines, finally your DB storage.
I've done similar things without problems, such as taking the results of a Reporting Services call into a bytestream and attaching that directly to an email, both using a memorystream and an on-disk file. So the basics of this are sound and should work.
Not sure if this is your issue or not, but if the PDF file itself is corrupt you might want to look at how it's being written. If Windows Preview can view the PDF but Adobe cannot, it may have to do with the fact that Adobe is expecting %PDF in the first 1024 bytes of the file (otherwise it will consider it corrupt).