Re: Simple Question: Always the same cyphertext?

From: sammy (notvalid_at_it.com)
Date: 08/18/04


Date: Tue, 17 Aug 2004 19:08:23 -0600


"John E. Hadstate" <jh113355@hotmail.com> wrote in message
news:MvvRc.34$3a4.22@bignews1.bellsouth.net...
>
> "sammy" <notvalid@it.com> wrote in message
> news:at-dnWLEf54e1YjcRVn-iw@adelphia.com...
> > Thank you all for your answers. The gist of what I hear is that, yes,
> some
> > 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
required
> 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.
But,
> I
> > want to verify it while it is encrypted. So, I will encrypt the file
> first,
> > 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
standard
> > from what I read.
> >
> > The catch is, I may instruct a user to decrypt the file and then
> re-encrypt
> > it with a NEW key, say, key_2. I would have already previously
encrypted
> > that file on MY system with that new key_2 and computed a new hash_2.
> That
> > newly encrypted file may end up being copied or backup up someplace or
> even
> > tampered with for whatever reason. The point is, at any point in time,
I
> > may instruct the client to compute the new hash_2 and send it to me and
I
> > 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
another
> > 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
small.
>

Hmmm, ordinary file sizes? How do I adapt for media files over 1GB?

Thanks,
Sammy

>
>
> > I've been reading how
> > a given key-size for a given algorithm is rated as to how long in years
> the
> > 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
> have
> > previously stated as being insecure?
>
> I have to admit that I didn't read all the responses, but I don't see
where
> your basic thinking requires the use of an insecure system.
>
>
>
>
>



Relevant Pages

  • Re: Need secure block cipher for 96 bits of block size
    ... AES need 128 bits data blocks. ... If you need to send exactly 96 bits of ciphertext for 96 bits of plaintext ... Encrypt the first 64 bits of plaintext to give a first 64-bit block. ... To decrypt you first decrypt the second block, and append the last 32 bits ...
    (sci.crypt)
  • Re: how to generate license keys for software
    ... Decrypt thelicensetext (using the privatekeythat only the ... Encrypt "xytlhkgeeddsddkf555" using the publickeybuilt into the ... Check to see if A is the hash of B, and if so, thelicenseis valid ...
    (sci.crypt)
  • AES Codebook Decrypt Problem
    ... just wondering if anyone can decrypt the following ciphertext (with key ... I can encrypt but I can' t seem to ... RijndaelManaged rijndael = new RijndaelManaged; ...
    (microsoft.public.platformsdk.security)
  • Re: Will Ada-95 Programs Written in MS Windows Run in MacOS and Linux Without Some Tweaking.
    ... Austin Obyrne writes: ... encrypt and decrypt. ... decrypt ciphertext decrypted-plaintext ...
    (comp.lang.ada)
  • RE: Problem while decrypting
    ... Extend your data with the hash THEN encrypt the whole thing and write into a ... now encrypt your new data and write it into a file ... rest will be your data X. Hash again the retrieved X and compare the ... >> you should NOT use the same key for CBC decrypt AND CBC MACing on the same ...
    (microsoft.public.platformsdk.security)