1 / 8

Comments on P1363.2 D25

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.

tovah
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Comments on P1363.2 D25 August 24, 2006

  2. 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.

  3. 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.”

  4. 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 …

  5. 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:

  6. 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”

  7. 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.

More Related