I am making a small project for college in GAE (using Java) in which I implement a form of "messaging service" where when a user sends a message to another user, the message is encrypted by 128-bit AES using Java crypto libraries and then stored on the server. The resulting key then has to be entered by the recipient to be able to read the message.
I now want to incorporate file upload (attachment) capability in this. So that when a user attaches a file (which can be ANY file, jpg,gif,txt,pdf,doc,exe,etc...), it is first encrypted and then stored. I want to interpret any file like a txt file (a sequence of characters), so that encryption/decryption can be done by existing code. (Does this even make sense? I am thinking of this because you can open any file in notepad and see the file as a sequence of characters). I would like to keep a limit on size of attachment as something like 5-10 Mb, but if for some reason this can only be done for even smaller sizes (<1Mb) even then its fine with me.
So if a user attaches a file, say abc.exe, I interpret it as a txt file, abc.txt and encrypt it along with the message. Then when recipient enters the correct key, I decrypt the message and file abc.txt, but serve as abc.exe. (I can ask the user to first convert any file to .txt, but that would be awkward)
Can this be done? And I am a novice to web development, servlets and GAE (my first project using any of these), so please bear with me.
Thank You !!
Well, the simple asnwer is yes: it can be done. The normal operation is to read the file as binary, encrypt the data, then base 64 encode it. Then the receiving side base 64 decodes it, decrypts it and probably writes the data. Base 64 will grow the data though, using 4 characters for every 3 bytes (+ maybe one or two padding bytes at the end).
If you need more information with it, such as the file name, you need to create some kind of container for the data and encrypt that. One solution is to use ASN.1 although that has a relatively large learning curve.
To view an example of this, take a look at the SMIME specifications and the CMS (cryptographic message syntax) which defines mail with encrypted attachments. CMS is broadly used. CMS is available in the bcmail (or subsequent) package of Bouncy Castle.
Note that you need some kind of authentication/integrity protection if you are creating an online protocol with encryption. A good PKI infrastructure may also be needed. This is a pretty large project to undertake.
Related
I'm looking for where to begin with this conversion. I have very limited coding experience (FLL parent) and virtually no support from the software company generating the files.
I am trying to take a data file generated by aircraft avionics that stores GPS waypoint information and read / write new information into it from a PC. The company I work for uses hundreds of waypoints and right now the only way we can create new ones is to do so through the avionics software, which is incredibly time-consuming. I can upload and download the file from the avionics onto a thumb drive but I have no idea how to read it. I opened it in a hex editor and can read the waypoint names, but the GPS coordinates are just garbled text characters.
Where do I start looking for answers? is this something I could convert in C++ or something similar without an overwhelming learning curve?
Thanks in advance.
I've got a web application that I know to be written in C, that's running on a specified IP address and port. I can access the application either with telnet or nc. With each of those, once connecting I'm prompted for input.
Since I've got a copy of the binary, running it through strings and hd showed me that the application is looking for a particular string to validate.
There's a file sitting on that domain that I'd like to access, which I can't seem to do with telnet or nc, so I'm thinking that either cURL or ftp would be the better bet here.
However, since the string validation that happens with this running service isn't really a password, I'm not sure how to pass this string value into the service with cURL or ftp. My gut tells me that I probably need to structure the command as a POST, but since this definitely isn't an HTTP service, I'm not sure how to proceed.
Any ideas?
(not an answer, but too long to post as a comment)
when dealing with undocumented custom protocols, telnet/curl/wget is definitely not suitable, and nc is not practical. write your own client.
you say the server is expecting a string? well, maybe you could run a dictionary attack on it, make a client that tries everything in a large dictionary (like this?), looking for any non-standard response, and go from there. add any strings you find in the binary too, ofc
if that gets you nowhere, maybe the binary is vulnerable to timing attacks? maybe you can extract a string that it is looking for, through a timing attack
and because you already have the binary, you could run it through a disassembler and study the assembly code, it should reveal both whether or not it's timing-attack vulnerable, and, if the strings are hardcoded, what string it is looking for, albeit, reading compiled assembly code is really difficult.. (game crackers does this all the time for cracking video game copy protections)
I'm writing a client-side program (in C) to access a certain web site, and I'd like to implement a 'remember password' feature in it. I don't think storing it in plain text is a good idea (what if the user's running malicious software which might find the password?), so I'm wondering. what's the best way of storing a password in such a case? I need to be able to recover it verbatim (a hash/salt won't do, the server needs the entire password), and the solution needs to be somewhat portable (it has to work at least on GNU/Linux).
You can use the lib openssl and write the password crypted with aes in a file. The location of the file may be only know by user.
Else, you can use a system variable as key.
If the user compile the program, you can generate a key and compile with (so store it in the executable)
Is there any archive format that offers the following:
be digitally sign-able with a digital certificate from a trusted source like Verisign - for preventing changes to the file (I am not referring to read only, but in case the file was changed it should no longer be signed telling the user this is not the original file)
be stream-able - be able to be opened even if not all of the content has been transferred (also not strictly linearly)
be "readable" - be able to read the data without extracting to a temporary folder (AFAIK if you open a file in a zip archive it is extracted first, and this stays true even for zip based formats like OOXML. This is not what I want)
be portable - support on at least Windows, Linux and Mac OS X is a must, or at least future support
be free of patents - Be open source - also preferably a license that allows commercial use(as far as i know GPL a share-alike license so it doesn't allow commercial use, BSD on the other hand allows it)
Note: Though it may come in handy eventually I can not think right now of a scenario that would require both point 1 and point 2 simultaneously. Or lets leave it a be able to check the signature only when the whole file was downloaded.
I am not interested in:
being able to be compressed
being supported on legacy systems
Does any existing archive format fit this description (tar evolutions like DAR and pax come to mind) ?
If there is, are there programing libraries available for the above mentioned OSs?
If not, would it be hard to create such a thing?
Usage scenario:
I want to use this to create a new media container.
Current media containers contain the audio, video and subtitle streams directly.
Matroska, currently the most advanced container, has supplementary features like attachments and menus.
The menu functionality however is not implemented and very limited.
What I want to create is one level higher.
I want to create a file similar in a way to OOXML.
Also all of the menuing should be done in web technologies like HTML5 (as it is now the tag allows for any kind of codec to be used) and CSS.
Also just like you have holograms on dvds to prove the authenticity I want to create a sign-able file
Research notes:
Before asking this question I stumbled uppon this:
Whats the best way digitally sign a zip file for download using .Net
While detached signing would be feasable for the individual files contained in this archive it is not an ellegant solution for the archive file. Not end user friendly.End users should be able to doubleclick the file to open it in a media player like VLC, and see a message that the file is legit (just like you see in a browser if the page is transmitted with SSL through HTTPS or not)
EDIT: clarified point 5
EDIT 2: added a note to clarify point 1 and 2
EDIT 3: added usage scenario
EDIT 4: added research notes section
P.S.: This is my first question on StackOverflow
I doubt that you find such format out of the box. I understand how such solution can be built with help of our SolFS, but SolFS doesn't have built-in signing (you can add signing easily).
Is there any difference between encrypting a file and encrypting the content of the file. If so, how to do the both.
File encryption is encrypting a whole file, from the outside (e.g. by right-clicking in Windows XP Explorer). Content encryption is generally used as a synonym for file encryption, but the two things are different. Content encryption means encrypting the contents of a file, or part of the contents of a file.
Consider video streaming. For instance, we might want to encrypt an HD video so that anybody can see the low-res version but only paying subscribers get the top quality stream. We cannot do that by encrypting the whole video file.
There is no difference.
There is no difference; however, it is possible to go an extra step by mapping the name of the file to something completely meaningless (EncFS does this in paranoia mode) or by attempting to hide the encrypted file is some way (maybe as diffused bits in some other media file). However, those aren't really encryption, but rather steganography -- attempting to hide important (usually encrypted) information.