It's not entirely clear what you are asking for here, but have you looked at the key derivation in TLS 1.3?
On 16 October 2015 at 01:27, Phillip Hallam-Baker <ph...@hallambaker.com> wrote: > > I strongly oppose any new crypto that does not include a fix for the > ephemeral keygen. > > The reason logjam is possible is that the key negotiation is essentially > > 1) Negotiate a shared secret S1 using the strong, long term server key. > 2) Use the shared secret to authenticate ephemeral key parameters Ec, Es > 3) Derive the session keys S2 from the ephemeral key parameters only > and throw away the output from the strong long term keys. > > It is not just 512 bit keys that are vulnerable. 1024 bit DH keys are also > weak: > https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/ > > If we are changing the crypto suites we can and should fix this > instead of S2 being a function of Ec, Es alone, add in the original S1 > as a salt. e.g. S2 = SHA512 (S1 + f(Ec, Es)) > > This ensures that no matter how broken the ephemeral crypto is, the > key exchange is always at least as secure as either the long term or > the ephemeral key. > > > Logjam isn't the only way that the system can be compromised. > > Oh and damn right I think BULLRUN might have had a part in keeping the > spec broken. > > > There is a right way to design an ephemeral key exchange and it is to > 'Do no harm'. Logjam shows that our current key negotiation mechanism > has a hole that makes it possible for the ephemeral to do harm. > > The move to the CFRG curves will mean a backwards incompatible change > to the deployed infrastructure so this is a perfect time to fix > ephemeral key establishment. > > I am going to keep raising this until the issue is fixed. > > > > On Mon, Oct 12, 2015 at 4:25 PM, Simon Josefsson <si...@josefsson.org> > wrote: >> Hi, >> >> I've updated my drafts on Curve25519/Curve448 support in PKIX to refer >> to the CFRG-Curves and CFRG-EdDSA drafts. >> >> The following document adds new EdDSA key/signature OIDs directly: >> >> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 >> >> The following document adds new namedCurve OIDs, thus going indirectly >> through the existing ECDSA 3279 route: >> >> https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 >> >> These two drafts take different approaches to including the new curves >> into PKIX, and currently both lack applicability statements. There is >> potential for overlap and conflict right now. It recently came up that >> for PKCS#11 a namedCurve approach would be useful, but for normal PKIX >> Certificates, it may be that the first direct approach is preferrable. >> The former lack the possibility of encoding keys for DH. I believe each >> approach can be useful on its own, but we need to include text adressing >> use-cases that can be resolved by both documents to avoid conflicts. >> >> /Simon >> >> _______________________________________________ >> pkix mailing list >> p...@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
