[TLS] 答复: Re: about the PWD Proposal

[[e-mail]]

Hi, Rene and Dan，


Rene Struik <[e-mail]> 写于 2011-11-19 00:06:39:

> Hi Sujing:
> 
> I did not make it to IETF-82, so am not privy to what was discussed 
> with respect to this draft in Taipeh. Dan Harkins would be in the 
> best position to answer you.
> 
> Some quick assessment of my own:
> 
> #1) Indeed, better to sprinkle in some salt that does not have to be
> stored (e.g., protocol-related nonces, etc.).
Dan has make it clear that salt is transfered to client from server, like 
a "constant" challenge.
Then my first previous concern is dismissed. Thank you Dan.

> 
> #2) Some people suggested that this particular "tweak" was motivated
> by trying and circumvent patent concerns.

So, the tweak one is to circumvent patent? then I can understand, 
but in my personal opinion a standard-to-be proposal is better to be 
elegant and simple, hehe :)


> 
> #3) if G is a generator of the prime order subgroup of the curve and
> Gp is another one, then either has the same prime order should be 
> fine for executing the DH protocol.
Thank Dan for introducing SPEKE to me,I didn't know the detail of SPEKE.
Rene, you are right in regard to selecting a generatir G or Gp for 
executing DH protocol.
I notice that there is specification of how  to ensure the resulting PE to 
be a suitable DH base in the document:
"hunting and pecking" by trying different counter.
So my third concern is gone. 
The only concern left is efficience in producing a suitable PE.

Best regards.

> Best regards, Rene
> 
> ==
> 
> 3. Now I only talk about the security of the simplified version (as 
> in above point 2) 
>    after simplification the protocol is easier to analysize, it is 
> just like an ordinary DH exchange except that the base group 
> generator is PE instead of g. 
>    So the security is reduced to the PE, is it a good group 
> generator which has large order? if not then it is insecure. 
>    Unfortunatly the authors failed to analysize this crucial point. 
> 
> On 18/11/2011 3:59 AM, [e-mail] wrote: 
> 
> Hi, 
>  I am interested in the PWD proposal at the meeting, and run through it(
> http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4), 
>  and have the following concerns: 
> 
> 1. In the document, it  says both Client and Server should be able 
> to compute PE, which is derived from username, password, salt,etc. 
>    That means Client or the user should also remember the salt 
> value, in that case, salt is meaningless and can be replaced by a 
> longer password. 
>    This is quite different from the widely known usage of salt, e.g.
> in UNIX operating system, salt is not required to remember by the 
> user, but by server to fetch locally by reference to the username. 
>   And as far as I know, I am sure the authors also know that, other 
> password based key exchanges protocols don't involve salt, but store
> a hash value of password among other things locally. 
> 2. From the figure in the PPT shown at the meeting, I cann't see why
> the protocol should use both "private" and "mask" values, in my 
> opinion, only "mask " value shall be OK. 
>    private value is redundent, and not helpful in security improvement. 
>    because the current derived shared key is 
> PE^{private_a*private_b}  according to this document， and 
>    after removing private value, it will be  PE^{mask_a*mask_b} 
>    and private, mask value are both generated locally and not 
> transported  on the wire, so it does not make much difference except
> making it more complex. 
> 3. Now I only talk about the security of the simplified version (as 
> in above point 2) 
>    after simplification the protocol is easier to analysize, it is 
> just like an ordinary DH exchange except that the base group 
> generator is PE instead of g. 
>    So the security is reduced to the PE, is it a good group 
> generator which has large order? if not then it is insecure. 
>    Unfortunatly the authors failed to analysize this crucial point. 
> 
> Thank you for your patience! 
> 
> Sujing Zhou 
> 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

> 

> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls

> 

> -- 
> email: [e-mail]
> Skype: rstruik
> cell: [phone]
> USA Google voice: [phone]


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.