let's say i'm skeptical about the encryption software i'm using... that they are lying to me and the scrambled data it spits out that they say has been encrypted by AES-256 really has not.

for instance i download the 7-zip source code. i can look up the rijndael algorithm but i'm not a cryptologist so to be realistic i don't really trust myself looking at 7-zip aes.c file and believe that's really the algorithm and that 7-zip truly encrypts my plain text file properly.

so, would the following be true?
if i get some other software programs that will encrypt using aes-256... say encryption wizard from here: http://www.spi.dod.mil/ewizard.htm

i have a file called ron.plaintext,
i encrypt ron.plaintext using 7-zip aes-256 and get a ron.7zipencrypt file.
i encrypt ron.plaintext using encryptwizard also using aes-256 and get ron.ewencrypt file.

if i do a binary compare of ron.7zipencrypt and ron.ewencryp, would they be equal and if so does this give me a good indication that 7-zip did indeed encrypt properly using aes-256?
(not knocking 7-zip or say encryptwizard is trustworthy, just using them as examples)

what really matters is the encryption algorithm used, and that whatever software employing that algorithm does so correctly and truthfully, right? so if we all agree (for example) that rijndael AES-256 is the way to go end of discussion about encryption algorithm choice, then the elephant in the room is trusting the software you are using... that it is actually using aes-256 properly and doing nothing else to compromise security of the encrypted output?

Well, one thing you could is take the AES code used in the program and encrypt and verify using known test vectors:
http://csrc.nist.gov/groups/STM/cavp...es/KAT_AES.zip

That is difficult to do, unless you are programmer.

The better thing to do IMO, is just verify all the constants and tables against the reference implementation.

You cannot just checksum two files from two different programs and expect them to match, because the file formats are probably different (especially for 7zip because it is also compressed).

I don't agree that AES is the way to go, but many people do, so that's up to you.

let me ask this way, again using the AES-256 encryption algorithm for sake of example let's say i'm requested/required to use it so i don't have a choice,

when you encrypt a piece of data just because you use a program that says "encrypted by AES-256" does not mean that's all it is doing?
for encryption_wizard i tried it on a simple jpg file and noticed the encrypted output has EWZDHEDR as the first 8 bytes in the encrypted output, so for a freely available utility that's how you know what program encrypted it. but with 7-zip i realize it can also compress it so i said format = 7z with compression level = store so i'm guessing straight encryption with no compression? if that were the case, then would any other program that does straight aes-256 be able to decrypt the file?

so if i were to encrypt a file and then give it to someone and say here but it's encrypted via aes-256 and the password is abc123, they can't just use any old program to decrypt it can they?

how important is it to know how to decrypt something by using the correct program? i'm asking this in regards to typical work day and transferring your data not from a how can i break the encryption point of view, like if i put an encrypted file on cd and mailed to someone. the receiving person then needs to know more than "it's encrypted with aes-256" right?

7zip always compresses in 7zip format, encryption with password is optional. A program would have to be able to decompress and decrypt a 7zip archive.

It is very important to know the file format. If a format goes out of fashion, you'd have to reverse engineer it unless you have enough documentation to tell you how it works.

You would have to tell the person you send it to the program they would need in order to open the file. Unless it is raw encryption, the header will contain AES-256 and salt and other things. You don't actually need to tell them what encryption algorithm it is, because the program has saved that to the file.

Block encryption software at the basic, encrypt blocks of data (in AES- 128 bits or 16 bytes). But different software may use different cipher, variant(cbc, ctr, ofb, cfb) as well as different metadata.

So it's best to use a single app. Gnupg is a good example of encrypting and decrypting files and available for both windows and linux.

Theoretically, unless you have a peer-reviewed software implementation and compile it from source ... and assuming that those sneaky devils at NSA haven't slipped something nefarious into your compiler! ... then you probably need to assume that the library or package that you're using, is doing what it says it is doing.

Most encryption programs insert metadata surrounding the encrypted payload, and include a certain amount of "quatch" (random garbage) such that, if you encrypt the very same file twice in a row, the encrypted files are not byte-for-byte the same even though they (provably) will decrypt to the same content.

The suggestion to use a "true, soup-to-nuts" encryption program such as GPG / PGP is a very good one ... and I would add to this that you should use digital certificates. In a pragmatic encryption situation (and especially if the data is to be transmitted), you need to be assured of several different things, which tools like these can do:

1. The data will be securely protected from disclosure, using the "latest" peer-reviewed algorithms but with backward-compatibility to older files.
2. You can be confident that the data in the encrypted file has not been tampered with: that "what you decrypted" is "what was encrypted." (You can verify this, even for files that are not encrypted.)
3. You can be confident that the data was provided by the party who claims to have sent it.
4. It's possible for someone to encrypt a file and send it to you such that only you can decrypt it, or vice-versa.
5. ... and the "guv'mint Spooks" really have nothing to do with it, since we're not breaking the law. (Right?)

This "greater whole" encompasses a lot more than just "the encryption algorithm de jour." (In fact, it is securely open-ended as to exactly what encryption algorithm is used, thus "future proof.") It's peer-reviewed and therefore trustworthy. Hence, the odds of you "having a false sense of security" are much lower ... not to mention it's also a lot less work!