[openssl-project] OpenSSL 3.0 and FIPS Update
beldmit at gmail.com
Sat Feb 23 20:47:00 UTC 2019
On Sat, Feb 23, 2019 at 8:47 AM Richard Levitte <levitte at openssl.org> wrote:
> On Thu, 21 Feb 2019 17:20:53 +0100,
> Matt Caswell wrote:
> > On 21/02/2019 15:02, Dmitry Belyavsky wrote:
> > > Dear Matt
> > >
> > >
> > >
> > > On Wed, Feb 13, 2019 at 9:30 PM Matt Caswell <matt at openssl.org
> > > <mailto:matt at openssl.org>> wrote:
> > >
> > > Please see my blog post for an OpenSSL 3.0 and FIPS Update:
> > >
> > > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
> > >
> > >
> > > After reading the proposed architecture description, I have some
> questions that
> > > are very important for the developers of non-US certified
> openssl-based products.
> > Hi Dmitry,
> > Answers inserted.
> > >
> > > 1. Will it still be available to implement custom RAND_methods via the
> > > providers API?
> > Yes, I expect this to be possible.
> This is something I'd like to see explored further. OpenSSL 3.0 will
> target the EVP API primarly, and while we do talk about entropy with
> regards to FIPS, I haven't quite grasped if that would be a provider
> internal thing or if entropy is supposed to come from "elsewhere".
> Since our RAND API is separate from the EVP API, I'm unsure how we
> plan on getting custom RAND_methods from providers.
> Please note that we can add RAND to the list of provider backed APIs,
> and given a foundation that we're currently building, it may even be
> quite easy. However, no one has said explicitly that we would do so.
> The other option is, of course, to move the RAND API to EVP somehow,
> but that will probably be more challenging.
I do not think it is really necessary to move RAND to EVP.
Current architecture suits our requirements, but if the possibility to
the RAND_METHOD is removed, it will cause problems for us.
> > > 2. Can we do something with a bunch of hard-linked non-extendable
> lists of
> > > internal NIDs?
> > > For example, providing GOST algorithms always requires a patch to
> extend 3-5
> > > internal lists.
> > > If it could be done dynamically, it will be great.
> > That's not currently something we've considered, but I agree it
> > would be great to fix that. Perhaps you could create a github issue
> > identifying the specific areas we should be looking at and then we
> > can take a look at the feasibility of fixing it.
> Let me address this in a different way...
> Are you very attached to those NIDs and them actually being NIDs? Or
> would you be just as happy to have the implementations identified by
> name? You see, providers will offer algorithm implementation by
> algorithm name (oh, and properties), not by number.
grep -ril gost . | grep -v objects
in the crypto/ folder enlists the following files:
Namely the functions CMS_add_standard_smimecap, PKCS7_sign_add_signer,
asn1_write_micalg, X509_certificate_type and array builtin_pbe refer to
The pkcs12_gen_mac function has a gost-specific processing.
It was much more simple to add gost-specific processing here than to add
a callback everywhere, though it breaks encapsulation I dream about.
Also, we have some patches adding Russian-specific X.509 extensions,
and I think for now it's better to register the necessary NIDs and provide
pull requests to add their processing.
The situation in libssl is much more difficult, because of more monolithic
> > > 3. Do you have plans to make some callback structures created by
> > > I mean such structures as SSL key exchange/authentication methods,
> > > extensions etc.
> > There aren't any plans to do that at the moment. There's nothing in the
> > design that would prevent us from doing so at some point in the future.
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users