Re: Simple Question: Always the same cyphertext?
From: sammy (notvalid_at_it.com)
Date: Tue, 17 Aug 2004 19:08:23 -0600
"John E. Hadstate" <firstname.lastname@example.org> wrote in message
> "sammy" <email@example.com> wrote in message
> > Thank you all for your answers. The gist of what I hear is that, yes,
> > algorithms do that, but they are generally considered insecure.
> I think you misinterpreted some of what you received. The fact that you
> encrypt a file twice with the same key and obtain the same ciphertext does
> not automatically imply that your cipher algorthm is insecure. All it
> implies is that your cipher is deterministic, which is more or less
> if you are going to decrypt the file later.
> > Let me explain why I asked that question. I'm brainstorming a system
> > whereby I would like to verify the integrity of a file using a hash.
> > want to verify it while it is encrypted. So, I will encrypt the file
> > then compute it's hash which I will use later to determine if some other
> > copy of the original encrypted file is untampered with... fairly
> > from what I read.
> > The catch is, I may instruct a user to decrypt the file and then
> > it with a NEW key, say, key_2. I would have already previously
> > that file on MY system with that new key_2 and computed a new hash_2.
> > newly encrypted file may end up being copied or backup up someplace or
> > tampered with for whatever reason. The point is, at any point in time,
> > may instruct the client to compute the new hash_2 and send it to me and
> > will verify that it matches my previously computed value of hash_2.
> And, it will if:
> (1) The user supplied the proper decryption key.
> (2) The decrypted file is identical to your decrypted file.
> (2) The user supplied the proper key_2.
> (3) The user used exactly the same encryption and hashing algorithms that
> you used to compute hash_2 (no hardware or software errors).
> What you're really asking is, "will two identical files (encrypted or not)
> produce an identical hash?" The answer is, "of course."
> > So, what I'm saying is that I want to previously construct a database of
> > keys and hash pairs for a given plaintext/ciphertext and expect that the
> > same encrypted plaintext will yield the same hash if encrypted on
> > user's system sometime in the future. Can I do this?
> Obviously. The user must process the file using the specified encryption
> and hashing algorithms and the specified key.
> Now, here's a cute idea: if the ciphertext hash matches the hash stored in
> your database, and you assume that the proper key was used, then to a
> probability approaching 1, you don't even need to decrypt the file; you
> already "know" the file's contents.
That's EXACTLY what I was shooting for. I want to verify that the file is
uncorrupted BEFORE decrypting it.
> Of course, the probability is less than
> one because you might have stumbled on a hash collision, a case where two
> ciphertexts hash to the same hash value. For ordinary file sizes and the
> usual crytographic hashes, this collision probability is unimaginably
Hmmm, ordinary file sizes? How do I adapt for media files over 1GB?
> > I've been reading how
> > a given key-size for a given algorithm is rated as to how long in years
> > ciphertext is considered to be secure. What if I only practically need
> > security for, say, 1 year? Then, can I use one of the methods that you
> > previously stated as being insecure?
> I have to admit that I didn't read all the responses, but I don't see
> your basic thinking requires the use of an insecure system.