Re: [skex] SKEX Use Cases

[Manfred von Willich <[e-mail]>]

On Wed, Apr 3, 2024 at 3:09 AM Panwei (William) <william.panwei=
[e-mail]> wrote:

>
>     > • A rather exceptional use case: allowing mutually distrustful
>     >   organizations to communicate securely in a way that cannot be
>     >   cheated by any single organization (negotiations come to mind)
>
> I can basically understand the first two use cases.
> But I'm confused by the last one.
> How are the two mutually distrustful organizations cheated when using
> methods other than SKEX?
>

This illustration will sound artificial, but a single untrusted key
distribution centre (KDC) doesn't work.  It can leak keys (it does not have
confidentiality), and it can provide different keys to different parties
(it does not have correctness).
Consider two or more organizations or NGOs with limited mutual trust using
a KDC controlled by one of them.  Assume that the keys are used between
members of these organizations as one-time pad keys.  Alice sends a message
with a key shared with one or more others.  The KDC sends a key to Alice,
and another (possibly delayed) key to one or more of the receivers, chosen
to mutate the message (including any message check code) to a chosen
replacement plaintext.  This could be used to tactically minipulate a
situation.
One could argue that normal key use (e.g. as an AES key) would guarantee
that the message would be garbled and could not be chosen.  However, the
security properties of key distribution should never rely on a subsequent
(especially unspecified) system to detect problems.
In reality, having a system in which no player has a disproportionate
security role will generally be more acceptable to all parties, including
for the optics of it.  This balance is not a property that can be achieved
securely in centrally managed KDC.