Re: Requesting comments: SRP based IRC encryption

Using a special "change session key"-message encrypted with
the old session key, sent to the IRC channel. Replaying this
message serves no purpose.

This design is within the spirit of how IRC works: The
channel operator may kick a user from the channel and change
the session key afterwards.

B

I noted in private conversation with Bjorn that he uses AES-CBC for
encryption after key exchange has taken place.

Since there is no MAC there is no guarantee the messages after the key
exchange are authentic. I tried to convince him that he really needs a
MAC but, naturally, a random guy on the Internet is not all that
convincing. Perhaps somebody with a bit more credibility can tell him
why it's a monumentally bad idea not to have a MAC.

I did get him to introduce a time-stamp in to the message, which is a
partial victory, but I'd have prefered that coupled with a message
number field.

It's a bit annoying in a way, professional cryptographers spend an
inordinate amount of time designing algorithms for mobile phones,
embedded devices, browsers etc and what not but Internet Chat which
has _millions_ of users world wide. We're in desperate need of a
professionally vetted protocol for multi-way discussions.

That's why I got in touch with him. It'd be great to have a workable,
well vetted protocol for setting up a multiway secure-chat over IRC.
His proposal looks quite good despite the lack of a MAC.

Simon.
.

Relevant Pages
Quantcast