Comments on p1363 2 d25
This presentation is the property of its rightful owner.
Sponsored Links
1 / 8

Comments on P1363.2 D25 PowerPoint PPT Presentation


  • 81 Views
  • Uploaded on
  • Presentation posted in: General

Comments on P1363.2 D25. August 24, 2006. Kaliski/1 (technical). D.5.5.3.4.1 [B15] also describes a multi-server scheme that obtains a retrieved key using just one PKRS-1 server, plus another non-PKRS-1 server.

Download Presentation

Comments on P1363.2 D25

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Comments on p1363 2 d25

Comments on P1363.2 D25

August 24, 2006


Kaliski 1 technical

Kaliski/1 (technical)

  • D.5.5.3.4.1 [B15] also describes a multi-server scheme that obtains a retrieved key using just one PKRS-1 server, plus another non-PKRS-1 server.

  • Master key is derived from the PKRS-1 retrieved key and an additional component from the non-PKRS-1 server.


Kaliski 1 technical1

Kaliski/1 (technical)

  • Proposal to insert 3rd sentence:

    “Alternatively, the master key could be derived from a single PKRS-1 retrieved key and a component stored on another (non-PKRS-1) server, where the Client must demonstrate knowledge of the retrieved key to the second server in order to obtain the component. This variant protects the password against compromise of the PKRS-1 server.”


Kaliski 2 technical

Kaliski/2 (technical)

  • D.5.5.3.4.2 paragraph 4, bullet 1:

    • Does the Server know oKCF = Hash(Z||)?

    • If so, server can determine password with offline dictionary attack. Master key Z depends only on password  and the server's private key u, so oKCF can likewise be calculated as a function of only those values. Since the server knows u already, if the server also knows oKCF, then  can be exhaustively searched.

    • The approach involving an ordinary server (above) blocks this attack …


Kaliski 2 technical1

Kaliski/2 (technical)

  • Editor’s notes:

    • Agree with this concern.

    • The first bullet item does not exactly correspond to either of the cited references.

    • Although it was intended to correspond to a proposal in [B21], the differences introduce this concern.

    • Propose replacing the first bullet item with the following text to match the cited [B21] reference and resolve this concern:


Kaliski 2 technical2

Kaliski/2 (technical)

  • Editor’s proposed change, from:

    “⎯ using oKCF = Hash(Z || ), which prevents the Server from fooling the Client without first correctly guessing the password, or”

    to:

    “⎯ using oKCF = Hash(Hash(Z1||Z2|| … Zn) || ), where the Zi values are derived using PKRS-1 with n distinct Servers, which prevents each Server from fooling the Client without first correctly guessing the password, or”


Kaliski 3 4 5 editorial

Kaliski/3,4,5 (editorial)

  • 8.2.1 KRBP-1: Should "party" be changed to "Client" to match KRPP-1 and KRUP-1?

  • 10.2 paragraph 1, line 4: "computes" --> "compute"

  • 10.2.1 paragraph 1: "Client and Server parties" --> "Client and Server"

    Editor’s Notes:

    Agree with these changes.


  • Login