security concern: key management flaw with silc-client

[mal content]

On 17/05/07, Daniel Kahn Gillmor <dkg-silc at fifthhorseman.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi SILC folks--
>
> I'm using silc-client 1.0.4.1 at the moment, monolithic build (not
> irssi-plugin).  I'm concerned that there is a serious security flaw in
> the model used for silc-client's management of clientkeys.  I'm hoping
> that someone can explain to me what i'm doing/thinking wrong, and how
> silc-client (or some other SILC client?) can help a reasonable user to
> avoid this scenario.

Hello.

I think the problem here is one of perspective,
specifically the view of SILC that the current silc-client
imposes. As you (probably) know, nicknames are not the
unique identifiers that they are in IRC. The only unique
identifier in SILC is a key.

The client imposes the perspective that nicknames are
unique identifiers (I assume in order to provide an
environment comfortably familiar to IRC) where in fact a
'pure' SILC client should probably provide a means to
associate a name with a public key in the client. This
way, when you've verified Alice for the first time, you
can associate the name 'Alice' with the given key and at
a later effectively ask 'Is this Alice?', regardless of
whatever the user has given as a nickname:

  /get_key_and_name Alice nickname_that_alice_is_using
  /verify_key Alice nickname_that_alice_is_using

The get_key_and_name function does what /getkey
currently does and associates the name 'Alice' with it.

The verify_key function checks to see if the key you
associated with the name 'Alice' matches the key the
other user is offering.

Think of it as a cryptographically verified "buddy list".

Of course there may be weaknesses in this idea as well,
as I said I'm just thinking aloud.

MC