From: TC on
Hi folks

Say I encrypt some data with a symmetric stream cipher.

When the data is DEcrypted, is there any way to know if the right key
was used or not, WITHOUT relying on known plaintext?

Here's what I'm thinking:

temp = CIPHER (key, plaintext + HASH (plaintext))

ciphertext = temp + MAC (key, temp)

Then on decryption:

1. Check MAC. If wrong, the ciphertext has been altered. Otherwise,
the ciphertext is intact: proceed to step 2.

2. Decrypt using relevant key.

3. Detach and check the hash. If correct, the RIGHT decryption key
was used, so the decrypted text should be correct; otherwise, the
WRONG decryption key was used, so the decrypted text is useless.

(1) Is there anything clearly wrong with that scheme?

(2) Can I use the same key for encrypting and MACing (as shown)?

(3) Is it ok to HASH the plaintext, or should it be MAC'd?

Please note, I'm not asking about key strengthening, salting, known
plaintext attacks on symmetric stream ciphers, and so on. I'm only
interested in whether you can tell if the right decryption key was
used, without relying on known plaintext!

TIA,
TC
From: Globemaker on
On Jul 4, 4:24 am, TC <gg.20.keen4s...(a)spamgourmet.com> wrote:
> Hi folks
>
> Say I encrypt some data with a symmetric stream cipher.
>
> When the data is DEcrypted, is there any way to know if the right key
> was used or not, WITHOUT relying on known plaintext?
>
> Here's what I'm thinking:
>
>    temp = CIPHER (key, plaintext + HASH (plaintext))
>
>    ciphertext = temp + MAC (key, temp)
>
> Then on decryption:
>
>    1. Check MAC. If wrong, the ciphertext has been altered. Otherwise,
> the ciphertext is intact: proceed to step 2.
>
>    2. Decrypt using relevant key.
>
>    3. Detach and check the hash. If correct, the RIGHT decryption key
> was used, so the decrypted text should be correct; otherwise, the
> WRONG decryption key was used, so the decrypted text is useless.
>
> (1) Is there anything clearly wrong with that scheme?

You should specify the sizes of blocks used. If the + sign means
addition or concatenation makes a difference.
plaintext is 128 bits
ciphertext is 256 bits or 128 bits, please tell us
temp is 128 bits or 256 bits, please mention is you are concatenating
or adding using XOR so the block remains 128 bits
temp = CIPHER (key, plaintext + HASH (plaintext)) How long?
ciphertext = temp + MAC (key, temp) How long?

From: TC on
On Jul 4, 8:37 pm, Globemaker <alanfolms...(a)cabanova.com> wrote:
> On Jul 4, 4:24 am, TC <gg.20.keen4s...(a)spamgourmet.com> wrote:
>
>
>
>
>
> > Hi folks
>
> > Say I encrypt some data with a symmetric stream cipher.
>
> > When the data is DEcrypted, is there any way to know if the right key
> > was used or not, WITHOUT relying on known plaintext?
>
> > Here's what I'm thinking:
>
> >    temp = CIPHER (key, plaintext + HASH (plaintext))
>
> >    ciphertext = temp + MAC (key, temp)
>
> > Then on decryption:
>
> >    1. Check MAC. If wrong, the ciphertext has been altered. Otherwise,
> > the ciphertext is intact: proceed to step 2.
>
> >    2. Decrypt using relevant key.
>
> >    3. Detach and check the hash. If correct, the RIGHT decryption key
> > was used, so the decrypted text should be correct; otherwise, the
> > WRONG decryption key was used, so the decrypted text is useless.
>
> > (1) Is there anything clearly wrong with that scheme?
>

Hi, thanks for replying. I'm about to get kicked out from my internet
access - right now!! - so I'll have to reply tomorrow.

Cheers,
TC
From: Kristian Gj�steen on
TC <gg.20.keen4some(a)spamgourmet.com> wrote:
>Say I encrypt some data with a symmetric stream cipher.
>
>When the data is DEcrypted, is there any way to know if the right key
>was used or not, WITHOUT relying on known plaintext?

Yes. Use a MAC. With a secure MAC, it is hard to create a valid tag
without knowing the correct key. Hence, if the tag verifies, you know
the ciphertext was created by someone who knew the correct key.

This is the well-known encrypt-then-mac paradigm.

Note: Don't use the same key for encrypting and MAC'ing, use different
keys. Alternatively, derive encryption and mac keys from a "master key".

Note: Use an authenticating encryption mode, like CCM or GCM, instead.

--
kg
From: mike clark on
On Jul 4, 2:24 am, TC <gg.20.keen4s...(a)spamgourmet.com> wrote:
> Hi folks
>
> Say I encrypt some data with a symmetric stream cipher.
>
> When the data is DEcrypted, is there any way to know if the right key
> was used or not, WITHOUT relying on known plaintext?
>
> Here's what I'm thinking:
>
>    temp = CIPHER (key, plaintext + HASH (plaintext))
>
>    ciphertext = temp + MAC (key, temp)
>
> Then on decryption:
>
>    1. Check MAC. If wrong, the ciphertext has been altered. Otherwise,
> the ciphertext is intact: proceed to step 2.
>
>    2. Decrypt using relevant key.
>
>    3. Detach and check the hash. If correct, the RIGHT decryption key
> was used, so the decrypted text should be correct; otherwise, the
> WRONG decryption key was used, so the decrypted text is useless.
>
> (1) Is there anything clearly wrong with that scheme?
>
> (2) Can I use the same key for encrypting and MACing (as shown)?
>
> (3) Is it ok to HASH the plaintext, or should it be MAC'd?
>
> Please note, I'm not asking about key strengthening, salting, known
> plaintext attacks on symmetric stream ciphers, and so on. I'm only
> interested in whether you can tell if the right decryption key was
> used, without relying on known plaintext!
>
> TIA,
> TC

An authenticated encryption mode such as GCM would work well, as would
a MAC (as you have already suggested). If you are generally interested
in the topic of authentication, here are two papers that I have found
interesting and practical:

The Order of Encryption and Authentication for Protecting
Communications. (Or: How Secure is SSL?), by Hugo Krawczyk (http://
www.iacr.org/archive/crypto2001/21390309.pdf)

Practical Crypto Attacks Against Web Applications, by Thai Doung and
Juliano Rizzo (https://media.blackhat.com/bh-eu-10/whitepapers/
Duong_Rizzo/BlackHat-EU-2010-Duong-Rizzo-Padding-Oracle-wp.pdf)

The first paper is especially interesting for your case. Your example
is correct in doing encrypt then mac. In that paper it discusses
problems with other orderings. The second paper is a very easy read on
what happens if you do things very wrongly. Basically it outlines a
number of attacks where one has used the value of padding for
authentication instead of a proper MAC.