Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

25519 support in openssl #46

Closed
zpostfacto opened this issue Jan 18, 2019 · 4 comments
Closed

25519 support in openssl #46

zpostfacto opened this issue Jan 18, 2019 · 4 comments

Comments

@zpostfacto
Copy link
Contributor

zpostfacto commented Jan 18, 2019

We need to get openssl to be able to do the 25519 key exchange and signing and verification. This would enable us to delete our current custom code (which is fine, but not as fast as openssl or as closely scrutinized) and do everything with a single crypto provider.

If we use AES-GCM we could do everything with libsodium. That'd be fine, too. The main thing is to make it so that you can link with a single, standard crypto provider. (And not have any of our custom crypto code.). It might be easier to use libsodium for everything, including in steam. Upgrading openssl in the steam code is probably going to introduce a lot of complexities.

@rlabrecque
Copy link

rlabrecque commented Jan 18, 2019

Please take console and mobile platforms into consideration with these changes. I'm not sure what kind of restrictions they have over crypto but it may require using their crypto libraries? I do know they require it to varying degrees for basically all communication at this point.

Edit: Oh, the next tab I opened: #45 👍

zpostfacto added a commit that referenced this issue Jan 21, 2019
The basic change is that the base class will no longer store the raw key bytes in a buffer.  Instead, we have virtual functions to get and set the raw bytes, with the storage being specific to the key type and crypto provider.

The main purpose of these changes is to make it easier to get 25519 working in OpenSSL and bcrypt.

NOTE: This broke libsodium support.  We could fix it.  But I'm not sure we want to support libsodium or not.  If we support it, we should support it for all crypto needs, including per-packet encryption.  And that means accepting the 12-byte IV and 16-byte tag.  If that's what TLS does, there is some potential advantage to doing exactly what TLS does.  At the same time, I don't add 12 bytes to every packet lightly.

Reorganize 25519 files, made a placeholder for OpenSSL with a bunch of FIXMEs.  (Working on issue #46.)

Also, deleted RSA key support, since we don't need it for thiis project.
@zpostfacto
Copy link
Contributor Author

Refactored some stuff, should be much more straightforward to do this now.

These functions would be relevant.
https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_get_raw_private_key.html

This means we would require OpenSSL 1.1. (Or we could support older OpenSSL, using the existing Donna support? I kind of wanna delete all that code, though.)

@zpostfacto
Copy link
Contributor Author

Welp, I implemented all the functions in crypto_25519_openssl.cpp, but it's not working. EVP_PKEY_get_raw_public_key is failing. I need to actually step into OpenSSL, and I don't want to go through the work to get all that setup right now. I need to go back to actually shipping this in Steam.

If anybody else wants to poke at this, go for it!

I'll come back to this later.

@tycho
Copy link
Contributor

tycho commented Jan 22, 2019

This is now implemented! It will automatically use OpenSSL if available, and fall back to building with the reference implementations in src/external/ if not.

@tycho tycho closed this as completed Jan 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants