Re: Requesting comments: SRP based IRC encryption

On 2009-02-08, Björn Edström <be@xxxxxxx> wrote:
Ilmari Karonen wrote:
On 2009-01-27, Björn Edström <be@xxxxxxx> wrote:
Say for the sake of argument we add HMAC-SHA1 or similar.
What do we use as secret key, and how is this key established
among users?

The same way you establish the encryption key. Instead of setting up
a shared 256-bit key fer encryption, you set up a shared 512-bit key
and use half of it for encryption and the other for authentication.
There are other ways to do it, too, but this is the simplest, safest
and most obvious one.

So with your solution Alice and Dave have a shared key for
authentication. What about Bob and Carol? Alice _only_
exchange keys with Dave.

I see you're going to insist I actually _read_ your proposal, eh? ;)

At a glance, it seems in your protocol all session keys are generated
by a single trusted party ("Dave"), who sends them to the other users
after they've autheticated themselves using SRP, right?

If so, I still don't see what the problem is. If Dave can generate
and distribute 256-bit session keys for encryption, surely he can just
as well generate and distribute 512-bit session keys for encryption
_and_ authentication. Or am I missing something obvious here?

Note that I'm mainly addressing only the "channel encryption" part of
the protocol here; I'm assuming that the "authenticated key exchange"
really is properly authenticated already, though I'd need to take a
closer look at SRP and your implementation of it to see if that's
really the case.

At a glance, it does seem like there might be a potential gap in step
4 of your key exchange, where the session key is sent encrypted but
not authenticated; appending M2 to it doesn't help by itself, since
CBC mode is still somewhat malleable. Fortunately, this is easily
fixed: instead of doing K = H(S), do something like K = H("foo" || S
|| "foo"), L = H("bar" || S || "bar"), and use the key K to encrypt
and the key L to authenticate the message. This is just standard key
expansion.

--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
.

Relevant Pages

  • Re: Encryption and authentication
    ... have encryption without authentication? ... it seems that encryption couldn't exist without authentication. ... and example is asymmetric key cryptography technology. ... http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked ...
    (comp.security.firewalls)
  • Re: Signatures and encryption headers
    ... breached when an attacker can modify the message received? ... But I see how the lack of authentication can cause the receiver to act ... not for the iv or other encryption ... A create a payload, S signs it with public key crypto (most likely ...
    (sci.crypt)
  • Re: Ciphers and their effect on the size of data
    ... We have a security-sensitive client that is wants common authentication between a J2EE environment and a "fat windows client". ... we'll also be facing 4/3 expansion of the payload after encryption. ... This password field will include a digital signature, or the digital signature will be in another XML element in that document. ...
    (sci.crypt)
  • Re: Ciphers and their effect on the size of data
    ... The user goes to the J2EE server, ... and submit them to the UNIX-hosted service for authentication. ... authenticate to the J2EE environment first, ... facing 4/3 expansion of the payload after encryption (for base64 ...
    (sci.crypt)
  • Efficient message authentication?
    ... Is the following message authentication algorithm known? ... One would like to combine encryption and authentication, ... faces impractically difficult patent negotiations for ...
    (sci.crypt)