>>This is possible, but you’d need to have the client and server negotiate
> based on
>>what they have. For example, if the server has a SRP verifier from the
> current
>>protocol, but the client has a stored PBKDF2 hash of the password for that
> server,
>>they cannot communicate and would need t
>> TLS-pwd already supports both of these. It also supports ECC too,
>> which is problematic with the current SRP protocol.
>In the language of the CFRG draft, TLS-pwd is “balanced” where SRP is
“augmented”,
>so they’re not really equivalent, correct?
Correct.
>This is possible, but you’d need
> On 17 Jul 2015, at 1:38 am, Schmidt, Jörn-Marc
> wrote:
>
>>> - Change the negotiation so that user name is not exchanged in the clear
>>> - Change key exchange to do PFS
>
>> TLS-pwd already supports both of these. It also supports ECC too,
>> which is problematic with the current SRP proto
>> - Change the negotiation so that user name is not exchanged in the clear
>> - Change key exchange to do PFS
>TLS-pwd already supports both of these. It also supports ECC too,
>which is problematic with the current SRP protocol.
I agree: Instead of modifying SRP I would prefer introducing a n
On Mon, June 29, 2015 4:31 am, Hubert Kario wrote:
> On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote:
>> Dave Garrett writes:
>> > On Friday, June 26, 2015 07:48:01 pm Attila Molnar wrote:
>> > > Currently SRP cannot be used with newer crypto primitives such as
>> > > ciphers in AEAD mode
