[2834] in Kerberos
Re: Kerberos non-repudiation idea
daemon@ATHENA.MIT.EDU (Jim Miller)
Mon Oct 4 19:18:11 1993
From: jim@bilbo.suite.com (Jim Miller)
Date: Mon, 4 Oct 93 17:03:58 -0500
To: don@gza.com
Cc: kerberos@MIT.EDU
Reply-To: Jim_Miller@suite.com
Don Davis <don@gza.com> wrote:
> i don't think this notary function should be part of the
> kerberos server's responsibility.
>
Why not? It seems to me to be the natural place for it. Or am I missing
something?
I should probably state an important assumption of mine. It is: In the system
described in my original "Kerberos non-repudiation idea" post, I assume the
majority of authenticated messages will *not* also be signed messages.
> actually, kinit already can be the mechanism for
> certificates' issuance, because certificates are just
> long-lived tgts, anyway.
>
I agree they are quite similar, though some of the ticket-specific fields would
have to be interpreted differently.
> here, your "nonce" seems to offer little if any extra
> security;
This surprises me a little, though I admit that I'm no cryptographer. The
original intent for including the XOR step was to have a cheap way to make it
more difficult to perform a brute force search for the key used to encrypt a
message signature. The XOR step was supposed to transform the known
"plaintext" message hash into "random plaintext". I'm assuming it's more
difficult to do brute force searching if the target plaintext is random bits.
How do you know when you've found the key?
> > It is now possible for a recipient to re-authenticate the
> > origin of an archived message, even after the sender's
> > certificate has become compromised.
> >
> it's not as simple as this, because the recipient needs to
> know that this archival signature is itself authentic,
> because its contents are hidden from the recipient. this
> is straightforward to fix, though.
>
Good point. I hadn't considered this.
> your efficiency improvements are ones i knew about
> already, so i certainly believe they're secure.
It was never my intention to critique your Private-Key Certificate
Authentication mechanism. I just mentioned it to show where I was getting the
private-key certificate idea from.
> of your ideas, my favorite is the signed hash of the
> message archive; i had believed that a compromised
> translator key would inevitably invalidate old
> signatures.
>
Too bad I can't take full credit for it. The Digital Timestamp people from
Bellcore described something like this at this year's RSA Data Security
conference. Actually, what they described was a mechanism for retaining the
integrity of their long-term Timestamps (MD-like hashes) even after computer
technology advanced to the point where the hashing algorithms became insecure.
Their solution: Occasionally imbed a hash of your old Timestamps inside a new
Timestamp that is created using a better hashing algorithm. (They're assuming
that better hashing algorithms will appear sooner than better computer
technology. A safe assumption, I think.)
My favorite idea is that the message signature mechanism allows you to do most
of the work of a transaction in parallel with the validation of the message
signature.
Jim_Miller@suite.com
