I have an implementation of such based on libgcrypt.

Hey there,

I'm happy for this to be included, but only "PBKDF2_STREEBOG256". GOST is a verification hash function, which is not suitable on it's own for password storage. It must be used in a manner such as PBKDF2 to make it a key-derivation function that is suitable for password storage.

Another note is that I don't feel comfortable accepting code linked to libgcrypt or gnutls. Both projects have histories of incorrectly and poorly implementing cryptographic primitives, to a point I do not believe it is responsible for us to trust them.

I think better implementations are potentially:

• openssl - https://github.com/gost-engine/engine
• rust streebog - https://docs.rs/streebog/0.9.0/streebog/

Reading https://fa.freebsd.security.narkive.com/xiz2YNMY/gost-in-openssl-base it would seem that rust streebog might actually be our best approach in this case, but we would need to provide a PBKDF construction for it.

So I think the process for this is:

• get @mreynolds or someone at RH to check with their legal if this is going to impact fips (IE do we need to feature gate this? I think we wont but we have to check to be sure ...)
• add PBKDF2_STREEBOG256 to rust streebog
• write rust password plugin support (probably I can do this)
• create a pbkdf2 streebog plugin + test suites

Are there parts of this you could contribute to for this? Thanks, hope that helps,

NOTE: GOST isn't in mozilla NSS, so that's not an option we could look at for this.

We have a gost openssl engine packaged in Fedora, so probably making a generic plugin that allows to use a custom openssl configuration could be better? Then one can enable the engine in the configuration and import required algorithms properly.

Note that freebsd's mailing list post is 4 years old. There were many changes in the gost engine since that time, including a very recent update to have a formally verified optimized implementation: https://arxiv.org/abs/2007.11481

We have a gost openssl engine packaged in Fedora, so probably making a generic plugin that allows to use a custom openssl configuration could be better? Then one can enable the engine in the configuration and import required algorithms properly.

No, this is not a good idea. Generic is a recipe for disaster because that allows untested and insecure configurations, that are beyond our knowledge. We go from "here is a list of KDF's that we know are good" to "I have no idea it's openssl yolo work it out I guess".

A key point in 389 is we can do things like "on upgrade cryptography improvements" so that defaults improve over time. But your suggestion would thoroughly break this and send us back to a point where we can't influence and help people's deployments be better.

So sure, we can use a gost openssl engine, but it's not going to be generic. Don't over-engineer a problem that doesn't exist.

For any openssl engine you would need to do the same configuration fitting to enable its use. This asks for generalization. A specific KDF on top of what is enabled by that generalization is a secondary part here.

How about we achieve the task in front of us first before we attempt to generalise over every possible configuration that could or might exist. Let's make something simple and testable, first.

That's what @slev already has with libgcrypt version. While you might not like gnutls, libgcrypt exists in all distributions and has support for both 256 and 512 bit versions of Streebog.

Anything touched by gpg is considered radioactive by infosec experts, so I won't accept libgcrypt or gnutls for cryptographic operations.

1) Actually, everybody has its own "trusted experts", which are not accepted by others, this is OK. Please, let's use the arguments other than personal feelings.
If 389-ds team wants to support the subject, let's choose one implementation or another which will satisfy the majority.

2) I can't choose Rust, because of E2K architecture, which has no support for Rust right now:
https://en.wikipedia.org/wiki/Elbrus_2000
Perhaps, this is a weak argument but it is.

3) As @abbra said I chose libgrypt because of its mass distribution and support for both hash functions (Streebog 256 and 512).

BTW, this is my test version (based on libgcrypt), which I've checked:
http://git.altlinux.org/people/slev/packages/?p=389-ds-base.git;a=shortlog;h=refs/heads/password_hash_streebog

1) Actually, everybody has its own "trusted experts", which are not accepted by others, this is OK. Please, let's use the arguments other than personal feelings.
If 389-ds team wants to support the subject, let's choose one implementation or another which will satisfy the majority.

I believe in this discussion I am the only member of the 389-ds team.

2) I can't choose Rust, because of E2K architecture, which has no support for Rust right now:
https://en.wikipedia.org/wiki/Elbrus_2000
Perhaps, this is a weak argument but it is.

That's okay, it's a valid reason, but the problem is ... 389-ds won't support this arch either? We do not support x86 or 32 bit arches which already precludes 389-ds from running.

Also be aware that 389-ds will make rust a requirement of the project in the future, so this will also be an issue for you ...

3) As @abbra said I chose libgrypt because of its mass distribution and support for both hash functions (Streebog 256 and 512).

libgcrypt may be widely used, but that does not make it good. Many of the worlds leading cryptographers refuse to use or touch gpg's code because it's so poor in quality. I personally believe that 389-ds must be the best work possible, to protect the identities of people around the world, and to achieve this means that we must only make decisions that we can rely on. I can not in good faith rely on libgcrypt to protect and secure people's passwords, which is why I refuse to allow it in the code base.

So I think this comes back to - the options are rust or openssl in this case, and it must be a PBKDF variant, I will not accept a bare verification hash as this is not suitable for storing passwords.

Ok, what about gost-yescrypt from libxcrypt?

about yescrypt: https://www.openwall.com/yescrypt/

Yep, I've just done some research on that library and:

• It's in fedora/suse
• They have extensive testing and use address sanitizers for memory safety
• It's backed by a fedora project member

So I'm happy to use libxcrypt.

Reminder though, that for passwords, we can't use a pure verification variant, it must be a KDF. So STREEBOG{256,512} are still a no, but PBKDF2_STREEBOG256 is a yes!

Thanks!

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/4272

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.