On Friday, 7 December 2018 18:24:38 CET Paul Smith wrote: > Thanks for your reply Martin! > > On Fri, 2018-12-07 at 10:46 -0500, Martin Thomson wrote: > > Unfortunately, we can't say that we have a PAKE, so I appreciate that > > you aren't able to just drop that in. > > A concern is that I have to support full backward-compatibility, not a > "flag day" upgrade, so unless a new PAKE behaves identically to my > existing SRP implementation it's probably not worth it to switch. When > I move to TLS I'll also have to maintain control of the initial > connection message, at least, to support backward compatibility... > that'll be its own brand of fun. > > > For key derivation, you probably want HKDF with SHA-256 rather than a > > straight hash function. > > Another thing that I didn't bring up: I need to implement this in other > languages (at least Java and Python), so clients can connect to the > service. So I need to consider availability in other crypto libraries > like Python ssl and javax crypto or BouncyCastle. I'm sure they have > HKDF too of course.
all that sounds like something that will be very painful to do in multiple libraries; having to support two, not just one legacy implementation when the migration happens to TLS doesn't seem to me as something that will help with that (not to mention that leaving such dead and already vulnerable code is a huge liability) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
