User Tag List

Not sure where to post this, but I'll try here.

I hear a lot about cryptography, and making stronger algorithms, and tools that try to hack, and I have to ask: how does a hacker know when they are done decrypting?

For example: If I tell someone I have encrypted a Microsoft Word 2003 document, they'll know their decrypting is done when they get a Microsoft Word 2003 document. But if I withhold this information and just hand them a binary file, how will they know when it has been decrypted?

I could write a pretty simple program that does a bunch of bit shifting and scrambling and padding. It would take input from the keyboard and create this file, possibly several megabytes for a simple phrase. To decrypt, I would use another homemade program that reverses the process and spits out the secret. But without the decrypt program, how can anyone look at this file and extract that secret? And what if the secret is not in the usual ascii character range for human readable text?

I know very little about cryptography, but this has me puzzled. Anyone offer up their opinion?

This might explain a little better...

Secret: "The eleven herbs and spices are..."
Run secret through Encrypt_A: large_binary
Run large_binary through Encrypt_B: huge_binary

The decryption process would involve running huge_binary through Decrypt_B, and then run its output through Decrypt_A. Both decrypt programs simply spit out a stream of characters.

So without the decrypt programs, how would someone know that there is a two-step process to get from huge_binary to secret?

A very good question. I think the answers in large part come down to context and experience.

Okay, this just guesswork while sipping my first coffee of the morning...

Encryption is a mathematical transformation, and when we're trying to decrypt something, we're initially more interested in figuring out the parameters and operators of that transformation than the decrypted information. The more input data we're provide, e.g. your very large binary, the easier this will become. The reason for this is that the parameters to the transformation, or key, become more apparent across larger samples. So for a very simplistic example, say I XORed my original input data with the word 'JPOLVINO', fragments of this word would appear in my encrypted file where there were zeros in the input binary. If my encryption process expands the data, this is more likely to highlight a key than obfuscate it.

To the best of my knowledge, most high end encryption is iterative, but doesn't increase size significantly as this would have undesirable bandwidth implications.

To put is simply, I may have two main reasons to encrypt something : 1) I do not want anybody else than me to see that something or 2) I need to make that something available to some other parties, that I've chosen, and I want that only those parties can see it.

Case 1 :
The scheme that you describe can be valid, but you need to have both the encrypted data (huge and large binary files) and the decrypting algorithms at the same place when you want to read the data in clear. Therefore, it does not matter how strong (or complicated) your encryption algorithm is : if a hacker has access to that place where you store both the data and the programs, there are great chances that (s)he will find a way to use the later to decrypt the former. So, you'd better to always store the data away from the programs, and your system ends up to be not very "user friendly".

Case 2:
This is the most common use case for cryptography. As the encrypted data is going from one place (the "sender's repository") to another (the receivers' repositories), you need the decrypting algorithm to be available to the receivers. If your receivers are well known, you can send them your decrypting programs (through secure means so that nobody can intercept them !). Of course, in real life, this is not the case : that's why all encrypting/decrypting algorithms are public and rely on a data set (the keys) to produce unique results.

There's quite a few other common uses for encryptions. One seen regularly in IT is to protect copyright, in which case the algorithm is protected, and the parameters are often less well protected. For example, you install a piece of software on a PC that has a registration process. This process picks up a number of parameters that make your PC unique, such as the NAT address, primary hard drive serial number, processor serial number, etc... and combines them to create a signature. This signature is sent to a server to create an encrypted unlock key, which is you enter on your PC. The piece of software on the PC then performs the same procedure, and if the results match, allows you to use the software.

There are similar schemes, not very popular I might add, used to protect various other types of intellectual property.

Both of the above are hackable, but usually put in place to make things awkward enough to discourage 95% of would be hackers. Quite often a cracked piece of software is still putting out encrypted signatures within its data for traceability purposes, which in turn can give the vendor sufficient information to prosecute the copyright infringer. See digital watermarking for more on this.

There are some other great encryption techniques out there which disguise rather than encrypt data, e.g. steganography, showing that sometimes the best way to hide important data is to keep it in plain sight [img]/images/graemlins/wink.gif[/img]

Maybe steganography fits in here, making the argument even simpler.

I could scatter the secret into a big binary file containing random acsii. It could even be human-readable ascii. My HideIt program knows how to hide input given to it: first character goes here, second character goes here, etc. My GetIt program knows how to pull those bytes out of the file using the same process.

Keeping both programs secret would be the key. I don't think anyone looking at a big binary file on its own can know what I am hiding in it.

Am I missing something fundamental here?

Ah. So this wasn't an abstract question.

It probably would have been a good idea (and polite) to explain that up front.

[ QUOTE ]
Keeping both programs secret would be the key. I don't think anyone looking at a big binary file on its own can know what I am hiding in it.

Am I missing something fundamental here?

[/ QUOTE ]

Depends entirely on who is looking, or put another way, who you are trying to hide this information from, and how much they're willing to invest in getting it. If it's just about keeping something private, and sharing it with a restricted audience, you might consider something like PGP. You can always combine strong commercial encryption tools like PGP / DESkeyetc..., with your home rolled encryption, and then hide the results in other files using the likes of steganography. This would take some serious resources to crack, and I'm guessing your secret isn't worth enough to anyone to make this investment.

(Of course you could just tell us the secret and we'll mind it for you, we're all trustworthy guys here and wouldn't tell a soul. Honest.)

[ QUOTE ]
Am I missing something fundamental here?

[/ QUOTE ]

Perhaps.

It's reasonably simple if you are the only one hiding data, and the only one finding it.

It's a different problem if you want to share any of it with anyone else (which is the more common case).

Page 1 of 2 12 Last

Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.