WIP: TLS with GOST ciphersuites in NSS

[Paul Wolneykien]

  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

Re: Adding support for nationwide (Russian, GOST) cryptography

[Paul Wolneykien]

В Thu, 13 Feb 2020 13:45:38 +0300
Dmitry Baryshkov  пишет:

> Hello,
> 
> For the past several years I have been working on adding support for
> GOST crypto to several OSS crypto libraries (libgcrypt, GnuTLS,
> LibreSSL, Nettle).
> 
> One of my next targets is NSS support. My primary goal is to get GOST
> S/MIME (See RFC 4490) support working in Evolution and Thunderbird.
> TLS 1.3 (draft-smyshlyaev-tls13-gost-suites) and optionally TLS 1.2
> (draft-smyshlyaev-tls12-gost-suites) are definitely a longer term
> optional goals which will require more coordination with Firefox (and
> other projects).
> 
> For now I'd like to understand if these patches (if implemented with
> proper code quality and test coverage) have a chance at all of landing
> at NSS repo?

  Hi! I've already have some conversation on the subject:

https://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg13003.html


> May I extend main soft token library with necessary algorithms, or I'd
> better create another PKCS#11 soft token library to be used instead
> (just for GOST for now)?

  I've extended the main (freebl) part with most of the GOST code in
the separate subdirectory.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto