Hi Paul,
I don't want to answer specific questions here, but I did want to address
the higher level point.
Integrating all the pieces for a new cipher suite is a major project. I
strongly suggest that you work on doing this in pieces. If you intend to
present a single patch that adds all the primitives and their integration
throughout the stack all the way to TLS, you are not likely to be
successful. Working on small increments is definitely more likely to work.
For TLS pieces, we would want a very strong case for anything that isn't an
AEAD and anything that is being added to TLS 1.2 or earlier. We would like
to avoid adding new features to anything earlier than TLS 1.3.
All that said, the bar for new cryptographic primitives in NSS has been
getting higher. While we don't intend to block new primitives, we would
want to see some case made for their value and some due diligence regarding
the risks. The
recent addition of HACL*-based primitives is the ideal, with code that is
formally verified for several properties. We have taken primitives with
lesser assurances, but require strong justification. The recent change to
accept an X25519 implementation from a similar project for performance
reasons is one example of that.
Cheers,
Martin
On Wed, Jul 17, 2019 at 11:15 AM Paul Wolneykien
wrote:
>
> Hi!
>
> I'm currently working on getting TLS with GOST ciphersuites in NSS:
>
>
> http://git.altlinux.org/people/manowar/packages/?p=nss.git;a=shortlog;h=refs/heads/gost-tls
>
> That's work in progress. However, I have some questions and proposals
> to the NSS community.
>
> New `SECOidTag algorithm` field in the `struct SECKEYECPublicKeyStr`.
> The algorithm tag (originated from a certificate) is used to determine
> how to parse the next `DEREncodedParams` field of that structure. In the
> upstream NSS code there is an assumption, that DER encoded parameters of
> an EC key always represent a single OID number. But that is not the
> case, at least, with GOST keys for which a SEQUENCE of parameters is
> supplied.
> On the other hand, the proper way to interpret the encoded parameters
> can possibly be *guessed* from the DER structure itself (and the actual
> values there). For example: if there is a sequence of two OIDs in the
> encoded parameters (and the OID values are in the GOST domain) then most
> probably it's a GOST key.
> However, the idea of having an identifier next to the encoded data
> which explicitly determines what is encoded seems more attractive to me.
> What do you think?
>
> Next, the PRF hashing algorithm in TLS versions prior 1.2. In the
> upstream NSS code there is currently no way of using a custom PRF
> hashing algorithm. That affects the calculation of the master secret and
> the encrypted TLS finishing message. With GOST ciphersuites you have to
> use GOST hashing for that with any TLS version.
> I have no good solution here yet. Does it violate the TLS 1.0 and 1.1
> standards? And another thing: I can't find a corresponding mapping of
> the hashing algorithm to the TLS version in OpenSSL.
>
> The third is the "stream" MAC mode. The idea that the MACing context
> shouldn't be re-created for each packet but rather re-used along with
> the whole sequence of packets in the session. That's how MACing works
> with GOST. I've added the `stream` flag to the `struct
> SFTKSessionContextStr` and then have to use a special PKCS#11 mechanism
> number in order to signal the softoken module to use that mode (the
> mechanism parameters are standardized, so there is no place for a
> `stream` flag).
>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
