Re: [P1363:] meeting agenda item

[Philip MacKenzie <philmac@xxxxxxxxxxxxxxxxxx>]

Hi all,

I'll be talking about the problem in PAKZ at the meeting tomorrow.  In
preparation, here is a summary of the problem, and the text of a
proposed change to the P1363.2-D20 text (sorry I didn't make these to
D21, but I think they would be easy to merge).

The problem in PAKZ is that the server stores an "encrypted signature
key", where the encryption key is the password, and the encryption
algorithm is E_pw(sk) = H(pw) \oplus sk.  The problem is that this
encryption is malleable.  Thus an attacker who compromises the server
can get this encrypted signature key, spoof the server to a client, and
send the client a slightly modified encrypted signature key.  The client
will then sign using the modified signature key, and the attacker may
learn something about the signature key.  

Here's a sample attack. Assume a DL-based signature, with a public
key/secret key pair (y=g^x,x).  Then the attacker sends E_pw(sk) \oplus
1 (i.e., bit 0 is flipped), and gets a signature.  From this signature,
he can compute the public key y' that was used.  If y'=yg, then bit 0 of
x must be 0, and if y'=y/g, then bit 0 of x must be 1.  We can get the
other bits of x similarly.

The text fixes this problem by adding a hash of the signature key to the
encryption of sk, i.e., E_pw(sk) = H(pw)\oplus sk | h(sk).  This
essentially makes the encryption non-malleable.  It is not really
non-malleable according to the formal definition of non-malleable, but
it is enough to make the scheme provably secure (in the random oracle
model).

I've marked the changes to the D20 draft in red.  There's not much
change.

-Phil





> > -----Original Message-----
> > From: owner-stds-p1363-discuss@ieee.org
> > [mailto:owner-stds-p1363-discuss@ieee.org] On Behalf Of
> > Philip MacKenzie
> > Sent: Wednesday, July 13, 2005 4:57 PM
> > To: STDS-P1363-DISCUSS@listserv.ieee.org
> > Subject: [P1363:] meeting agenda item
> >
> > Hi all,
> >
> > I found a problem in the proof of security for PAKZ, and I
> > need to make
> > a small change to the protocol.  Sorry that this is coming so late
in
> > the process, but I just realized the problem.
> >
> > In some sense, by simply adding a clarifying note I could avoid the
> > attack I'm envisioning, but I don't think that is a satisfactory
> > solution.  The problem is that someone may make a minor
generalization
> > to PAKZ scheme and not understand that it would cause a security
hole.
> >
> > I would like to present this new information at the meeting on July
> > 20th.  I will have further documentation at that point.  I think 30
> > minutes should suffice.
> >
> > Best regards,
> > -Phil
> >
> > ########################################################
> >
> > You are subscribed to the STDS-P1363-DISCUSS.
> > To unsubscribe, send your request to LISTSERV@LISTSERV.IEEE.ORG
> > and type the following in the body of the message
> >
> >         SIGNOFF STDS-P1363-DISCUSS
> >
> > You can also click on the following link
> > http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-P1363-DISCUSS&A=1
> >
> > send all questions or concern about this list to
> > STDS-P1363-DISCUSS-request@LISTSERV.IEEE.ORG.
> > ########################################################
> >



########################################################

You are subscribed to the STDS-P1363-DISCUSS.
To unsubscribe, send your request to LISTSERV@LISTSERV.IEEE.ORG
and type the following in the body of the message

        SIGNOFF STDS-P1363-DISCUSS

You can also click on the following link
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-P1363-DISCUSS&A=1

send all questions or concern about this list to STDS-P1363-DISCUSS-request@LISTSERV.IEEE.ORG.
########################################################

P1363-2-D20-revised-PAKZ-only.doc