-
Notifications
You must be signed in to change notification settings - Fork 88
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
Support for EdDSA certificates #328
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The algorithm can easily be recomputed from the private key. Moreover the local private key is not necessarily used for signature only. It can be used for RSA encryption too.
So that signature and verification functions are always used with the same pattern. This reduces differences between TLS12 and TLS13 code, as well as client and server.
Function storePrivInfo is used from server code too, where the CertificateType part is not needed. This can be split into two distinct functions.
This alert is to be used when validation of KX signatures, Finished messages, or PSK binders fails. This is consistent with RFC 5246 section 7.2.2: decrypt_error A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message. This message is always fatal. and RFC 8446 section 6.2: decrypt_error: A handshake (not record layer) cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message or a PSK binder.
ECDSA is not implemented yet as we don't have secure implementation of signature generation. But this resolves #272. It will also be useful if ECDH private keys are added to the data type.
Handshake state now contains both local private and public keys. This avoids deriving the public key for schemes like EdDSA.
kazu-yamamoto
approved these changes
Dec 10, 2018
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds and enables EdDSA support with TLS12 (described in RFC 8422) and TLS13.
EdDSA with TLS12 completes the refactoring started in #236 and adds a
KeyExchangeSignatureAlg
data type for reason already explained: ECDHE_ECDSA is used for both ECDSA and EdDSA.EdDSA private-key operations need the public key, so the local public key is taken from the certificate chain and stored in the handshake state along with the private key. Otherwise deriving from the private key would add approx. 20% more time to the signature of a 10KB message.
I also align the TLS13 utilities used to generate and verify signatures to what exists with other versions, as well as other modifications explained in commit messages.