Subject: Re: looking for feedback on crypto draft: cipher state chaining

From: "Nicolas Williams" <[email-masked]>
Date: Mon, 3 Jun 2002 11:26:54 -0400

On Fri, May 31, 2002 at 09:08:06PM -0400, Tom Yu wrote:
> Nicolas> How significant is the additional overhead of using
> Nicolas> KRB-SAFE/KRB-PRIV as opposed to stream encryption?
> 
> KRB-SAFE and KRB-PRIV add a _minimum_ of 48 octets, assuming all
> optionals omitted, all (allowed) integers positive but less than 127,
> and all octet strings are zero length.  Additionally, this value of
> overhead ignores cryptosystem-provided padding.  Obviously these
> conditions are somewhat unlikely.

[...]

Thanks. For some purposes that's pretty hefty, for others, not at all.

I imagine the same could be said for the compute-time overhead of
KRB-SAFE/KRB-PRIV, so I shan't ask.

IMO keeping the cipher state spec in there is justified.

> ---Tom

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Martin Rex <[email-masked]>
Date: Mon, 3 Jun 2002 18:55:26 +0200 (MET DST)

> Thanks. For some purposes that's pretty hefty, for others, not at all.

What was the protocol overhead of TCP(IPv4) over Ethernet again?
I think it was somewhere around 40 octets per datagram.

The "protocol overhead" is therefore ONLY significant for low-bandwith
communication anyway (like pure ascii characters from a users keyboard).

> KRB-SAFE/KRB-PRIV, so I shan't ask.

Of course, per-message overhead in CPU cycles is often overlooked,
in particular when markedroids boast about the encryption speed
of hardware crypto.

We had a crypto vendor show up with a product that imposed a 8 millisecond
minimum overhead on GSS-API message protection calls in order
to setup the crypto hardware through the PCI bus of the PC... OUCH!

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Mon, 03 Jun 2002 13:46:25 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Thu, May 30, 2002 at 07:22:17PM -0400, Ken Raeburn
    Nicolas> wrote: [...]

I think the value of the chaining may actually be layer 9 more than
anything else.  I really don't like being forced to specify
crypto-system specific information for a bunch of protocols because it
increases the time ti takes to deploy a new crypto system, increases
code complexity, and historically has lead to security errors.

In my mind, significant value from the crypto framework document comes
from it providing enough primitives that applications who for whatever
reason choose not to use Kerberos messages may be willing to at least
use Kerberos crypto.

One of the evaluation criteria I used for the document was to see
whether we could implement all the historical cases where people had
roled their own crypto creating crypto-system specific assumptions in
things in the Kerberos space using these primitives.  My argument is
that if some use case came up in the past, it has a reasonable
probability of coming up in the future.  Chaining was important to
some of these use cases.  Since I believe that avoiding crypto-system
specific assumptions is useful and that chaining may help avoid these
use cases then I think chaining is worth the spec complexity.

Note that we can always drop chaining later--say when we go to
draft--if it is not useful.