Prev: A link to a news on SSL
Next: New visual for the Lp pattern found in the first 300 million Primesums.
From: Kristian Gj�steen on 25 Mar 2010 18:30
Jonathan <jonathan.day.jobs(a)gmail.com> wrote:
>A probably simple question. A glance through block encryption modes
>that also support authentication seem (to me) to keep the
>authentication distinct from how the next block is handled. I'm sure
>someone can point me to a useful (online or dead-tree) guide on the
>whys and wherefores of this, and/or whether my observation is indeed
>correct.

First, observe that an encryption scheme consists of an algorithm for
encryption and an algorithm for decryption. You encrypt messages,
and decrypt ciphertexts. A block cipher is not an encryption scheme,
but rather a building block, you get an encryption scheme from a block
cipher by using a mode of operation.

Next, there are usually two goals for an encryption scheme. You want
to keep messages private, and you want to ensure integrity. You want
to ensure this at the level of messages, so you want a guarantee that
nobody can learn anything about the message from the ciphertext, and you
want a guarantee that if the ciphertext decrypts correctly, then nobody
has tampered with it.

Traditionally, we used two distinct tools to achieve this: a simplified
encryption scheme to provide confidentiality, and a message authentication
code to provide integrity. There were some remarkably easy-to-use
results about this (namely, use distinct keys, encrypt first, then MAC
the ciphertext), but it turned out people were somehow unable to follow
these simple rules. Therefore, we got modes of operation that do both
confidentiality and integrity.

The way these work is as follows: If the ciphertext has been tampered
with, the integrity protection will detect it and you discard the entire
ciphertext. Otherwise, decrypting the ciphertext produces the original
message, unmodified.

--
Kristian Gj�steen
From: Jonathan on 25 Mar 2010 18:48
On Mar 25, 3:30 pm, Kristian Gj steen <kristiag+n...(a)math.ntnu.no>
wrote:
> Jonathan  <jonathan.day.j...(a)gmail.com> wrote:
> >A probably simple question. A glance through block encryption modes
> >that also support authentication seem (to me) to keep the
> >authentication distinct from how the next block is handled. I'm sure
> >someone can point me to a useful (online or dead-tree) guide on the
> >whys and wherefores of this, and/or whether my observation is indeed
> >correct.
>
> First, observe that an encryption scheme consists of an algorithm for
> encryption and an algorithm for decryption.  You encrypt messages,
> and decrypt ciphertexts.  A block cipher is not an encryption scheme,
> but rather a building block, you get an encryption scheme from a block
> cipher by using a mode of operation.
>
> Next, there are usually two goals for an encryption scheme.  You want
> to keep messages private, and you want to ensure integrity.  You want
> to ensure this at the level of messages, so you want a guarantee that
> nobody can learn anything about the message from the ciphertext, and you
> want a guarantee that if the ciphertext decrypts correctly, then nobody
> has tampered with it.
>
> Traditionally, we used two distinct tools to achieve this: a simplified
> encryption scheme to provide confidentiality, and a message authentication
> code to provide integrity.  There were some remarkably easy-to-use
> results about this (namely, use distinct keys, encrypt first, then MAC
> the ciphertext), but it turned out people were somehow unable to follow
> these simple rules.  Therefore, we got modes of operation that do both
> confidentiality and integrity.
>
> The way these work is as follows:  If the ciphertext has been tampered
> with, the integrity protection will detect it and you discard the entire
> ciphertext.  Otherwise, decrypting the ciphertext produces the original
> message, unmodified.
>
> --
> Kristian Gj steen

Thank you, and thanks to Maaartin as well. Between your answers, I've
got a far better understanding of the subject. I appreciate you both
taking the time to answer me.
From: Mok-Kong Shen on 26 Mar 2010 05:28
Jonathan wrote:
[snip]
> For example, let's say you used a cryptographic block cipher mode that
> was ultra-sensitive to corruption. You can use a mix of Reed-Solomon
> (to fix bit errors) and Turbo Codes (to fix block errors) to ensure
> that the ciphertext is not corrupt. You could then both detect
> modification and undo it. But again, this is generally not what is
> done in practice. Sure, there may well be some error-correction and
> some authentication, but these appear to be considered extensions and
> extras rather than as intrinsic to the very nature of the encryption
> process. [snip]

Nowadays computers are highly reliable, so sensitivity to corruption
shouldn't be an issue (assuming one#s program is correct). Errors in
communication networks are very well dealt with in lower levels of the
protocols. Adding error correction codes on the user level for the
purpose of detecting/correcting manipulations by man-in-the-middle
wouldn't work, because he can change the bits in such a way that the
criteria of these codes are satisfied.

CBC-MAC is popularly used and certainly well-known to you. If you have
two minutes to spare, please do take a look at my proposal mentioned
(despite constant attempts of someone to maliciously denounce me), and
make a simple and straightforward comparison. The result should be
entirely clear to you.

Thanks,

M. K. Shen
From: Scott Fluhrer on 26 Mar 2010 09:10

"Kristian Gj�steen" <kristiag+news(a)math.ntnu.no> wrote in message
news:hogo6n$5gq$1(a)orkan.itea.ntnu.no...
> Jonathan <jonathan.day.jobs(a)gmail.com> wrote:
>>A probably simple question. A glance through block encryption modes
>>that also support authentication seem (to me) to keep the
>>authentication distinct from how the next block is handled. I'm sure
>>someone can point me to a useful (online or dead-tree) guide on the
>>whys and wherefores of this, and/or whether my observation is indeed
>>correct.
>
> First, observe that an encryption scheme consists of an algorithm for
> encryption and an algorithm for decryption. You encrypt messages,
> and decrypt ciphertexts. A block cipher is not an encryption scheme,
> but rather a building block, you get an encryption scheme from a block
> cipher by using a mode of operation.
>
> Next, there are usually two goals for an encryption scheme. You want
> to keep messages private, and you want to ensure integrity. You want
> to ensure this at the level of messages, so you want a guarantee that
> nobody can learn anything about the message from the ciphertext, and you
> want a guarantee that if the ciphertext decrypts correctly, then nobody
> has tampered with it.
>
> Traditionally, we used two distinct tools to achieve this: a simplified
> encryption scheme to provide confidentiality, and a message authentication
> code to provide integrity. There were some remarkably easy-to-use
> results about this (namely, use distinct keys, encrypt first, then MAC
> the ciphertext), but it turned out people were somehow unable to follow
> these simple rules. Therefore, we got modes of operation that do both
> confidentiality and integrity.

Actually, it's about performance, rather than to stop stupid people from
doing stupid things. We've come up with ways to do both encryption and
integrity that turn out to be cheaper than doing each one separately. In
addition:

- These ways (at least, modes such as GCM and CWC) are provable (that is, we
have a security proof that if you can violate either the privacy or the
integrity protection on the combined mode, you have a way to violate the
security properties of the underlying block cipher; in other words, if the
block cipher is secure, then the combined mode is secure). This is also
true of some separate privacy and integrity transforms (e.g. CBC, CMAC);
this just tells us we're not creating any potential security holes for the
sake of performance.

- In fact, the provability constraint is a good part of the reason why the
modes are constructed as they are; it makes it easier to prove things about
the mode. For example, if you use the block cipher in two different
sections in the mode with the same key, then you need to show that the
attacker cannot exploit collisions between the two instances of the block
cipher. That is, if he has a message in which the input to AES instance 1
is X, he cannot (with nontrivial probability) generate another message in
which the input to AES instance 2 is also X, or if he can, it is harmless.

--
poncho


From: Paul Rubin on 26 Mar 2010 16:43
"Scott Fluhrer" <sfluhrer(a)ix.netcom.com> writes:
> Actually, it's about performance, rather than to stop stupid people from
> doing stupid things. We've come up with ways to do both encryption and
> integrity that turn out to be cheaper than doing each one separately.

Are any of those combined modes actually faster than something like
CTR+UMAC?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: A link to a news on SSL
Next: New visual for the Lp pattern found in the first 300 million Primesums.