I kind of know why its bigger when DES files are zipped are bigger but can anyone give me proper reason why or link i cant seem to find anything why ?
Thanks :)
A decently encrypted ciphertext looks very much like a sequence of random numbers to the compression program. Without the patterns that'd be present in cleartext, the compressor can't find much redundancy to remove, and thus can't compress very well at all. Add in the data the compressor needs in order to be able to decode, and it's entirely possible that the "compressed" file will be bigger than the original.
If you want to compress, you might consider doing so before you encrypt.
Related
I am fairly new to cryptography, but I have come across this :
ea706916-4d0a-460d-9778-4d1a7195b229
which looks like a familiar format. It's original value is tjotol.
Would anyone know what format the above code is in? I know that if it has hashes it can be a giveaway. Base64? HTML? Something else?
It does not look like Base64, it may be MD5 with dashes in-between. However, remember that a hash is a one-way function (ie. it's not reversible), while a cryptographic function is two-way (you can encrypt and decrypt it). Hence, it's not correct to speak about "hash decrypting". I don't know what you mean by "format language", would you care to elaborate on that?
A quick google search took me to this article that seems to be well written an covering many issues regarding your concern related to hashes being a "giveaway".
Note: Base64 is hardly an encryption algorithm, it is indeed just an encoding/representation format.
This have the format of a Globally unique identifier (GUID). Take a look here: Globally unique identifier
Cryptographic Mavens,
Would you be so kind as to offer a bit of background for a cryptographically-related scene in a novel?
Assume the good guy has to decrypt a dozen image files...yet does not know either the system used to encrypt the files, or their key(s).
Unlike the TV/Movie hackers who crack such files after ~5 seconds of furious keyboarding...what (in your opinion) would be plausible (not necessarily through or completely accurate) approaches to (1) determining how the files were encrypted (i.e., what encryption system was used?), and (2) how to attempt decrypting them for viewing?
Your suggestions...thoughts...ideas--maybe even a reference or two (Amazon?)--will be gratefully appreciated.
Thank you,
Plane Wryter
You can't. A reasonably good encryption algorithm will yield data that is statistically almost pure normally-distributed "random" data. (i.e. undecipherable, unrecognizable, high entropy)
The only way you could do this was to brute-force passwords through a brute-force list of password-derivation functions, into a brute-force list of crypto algorithms (i.e. really freaking hard).
What are the possible ways to attach the iv to the encrypted string. Prepending iv as the first sixteen is the most common approach. Are there any other ways can we able to do it?
You can attach it however you like (at the beginning, or end, or middle if you really feel like it), or send it separately, via smoke signals if you like! As long as your decryption code knows where to find it. At the beginning is certainly the logical place for it though (especially if you want to start decrypting before you've got the entire ciphertext). But from a security point of view, there isn't a reason not to put it elsewhere if you have that need for some reason.
Just remember that you should assume any eavesdropper knows where you've put the IV. You shouldn't consider that to be a secret.
I wanted to know whether
A file encryption algorithm can be designed in such a way that it can perform the activities of a file compression as well (any live example?).
Also can I integrate it to a Mobile SMS Service, I mean for text messages?
Also I wanted to know about binary files...if a plain text file is encoded in binary does its size reduces? Also is it better to encode a plain text file to a binary one rather than encoding it to any other format (in case if anyone wants it to encode for any purpose)
In fact all decent encryption programs (take PGP for example) compress data before encryption. They use something mainstream like ZIP for compression. The reason is once data is encrypted it looks like random noise and becomes incompressible, so it can only be compressed before encryption. You likely can't do that for SMS - you have to obey the specifications for the SMS so you'd better check those specifications.
Compression removes redundant information. Redundant information makes breaking an encryption easier. So yes, encryption and compression are compatible. I don't know if there is an algorithm designed to do both things though.
Yes, a binary file will usually be smaller than a plain text file. For instance, the number 34 written out in text takes 2 bytes (at least) whereas in those same 2 bytes you could write a number as large as 65000.
What makes an encoding "better" than another is the purpose to which it is put. If you are optimizing for size, binary is probably better. If you are optimizing for readability or graceful failure, text might be better.
First question: No reason why it shouldn't be possible. Since you can still encrypt compressed data and vise versa, you can test the benefits by trying. I don't know if it can be used for text messaging, but you'd have to explain what you're trying to do if anyone wants to give a reasonable and fitting answer.
Second question: plain text is still binary, it's just readable and encoded in a certain character set. Main difference is that plain text usually conforms to a certain encoding, say UTF-8 or ISO-8859-1.
You can still compress plain text, which makes it "binary" in the traditional sense that you only see weird bytes. :-)
I want to ask for a mature model to do this.
Suppose I want to deliver a program and a sensitive data file to user. The program is able to read any data stored in the data file, but user is not allowd to easly break the data file. The data file will be encrypted by standard algorithm such as AES. Now, the problem turns to how to manage the key. Putting the key in the program seems to be a bad idea, but what else I can do? Apparently I can't give the key to user directly.
There is no way to do this securely, ie. to really prevent the user from reading the data. As long as they have the data and they have the program that can read it a competent disassembler will be able to figure out how the program reads it and do the same thing. Or, even easier, they could let the program do it and then get the decrypted version out of its memory.
Having said that, if you just want to prevent the average user from doing it, hardcoding the key in your source code should be fine. :) Just be realistic about the level of protection this provides.
Does it have to be pure software? If not, you could look at a solution which does decryption and storage of the key on a hardware device, e.g. a USB dongle.
You can also potentially prevent the whole problem by having your software retireve the data from a web-service instead of a data file. In this case you can control access to the data much more tightly (i.e. who gets how much of what and when). This might or might not work for your application.
Otherwise as others pointed out, there is no known good pure software solution.
There is no 100% safe solution to this because at some point you have to have the key loaded into memory so that de/encryption can take place and a savvy-enough hacker will be able to capture it. The best you can do is to make it very difficult to capture and to mitigate exposure to data (by limiting access as much as possible) if the key is compromised.
As far as how to make it safer... you could have a combined key that is made up of something stored in the program and something derived from the user's passcode?
Is your perceived user determined? are they skilled enough to do reverse the application or the key? If the user is considered to just be a generic desktop user you probably could implement a partial key using some general encryption just to make the key non obvious, beyond that a determined individual will be able to reverse must simple means of encrypting keys and data.
A DVD John conundrum, eh? Why is having a key in the program bad? You could have a super-obscured function which computes it reliably once. Someone with disassembler and debugger can break your key given enough time, IMO.