Begin work moving to trait-based encryption #189
Conversation
This file contains hidden or 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
Currently, we rely on the `SecurityPolicy` enum to decide on choice of algorithms, keys, etc. for OPC-UA encryption. This breaks down if we want to support elliptic curve cryptography, because the key _types_ will be different. In order to make this possible, what we'll likely want is some kind of `SecureChannelState<T: SecurityPolicy>`, where key types are associated types on `SecurityPolicy`. This takes the first steps towards that, by refactor existing security policies to all implement a new trait `SecurityPolicyImpl`, which exposes a bunch of different methods we need. To avoid excessive boilerplate, I also refactor a lot of the existing AES code to use traits for different types of encryption. IMO the result is pretty neat, with each policy just denoting a few core properties and four different algorithms for asymmetric and symmetric encryption and padding. This is very unlikely to be final, since there are still places where the AES-specific key types leak, but the PR is already large enough, and is nicely self contained. There are technically some breaking changes here, since I remove some public exports, but for normal users this shouldn't be noticable at all. This is obviously a scary change, but thankfully it is fundamental enough that if I managed to mess up any of the numbers or types, the tests against the .NET server would certainly break.
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.
Currently, we rely on the
SecurityPolicyenum to decide on choice of algorithms, keys, etc. for OPC-UA encryption. This breaks down if we want to support elliptic curve cryptography, because the key types will be different.In order to make this possible, what we'll likely want is some kind of
SecureChannelState<T: SecurityPolicy>, where key types are associated types onSecurityPolicy. This takes the first steps towards that, by refactor existing security policies to all implement a new traitSecurityPolicyImpl, which exposes a bunch of different methods we need.To avoid excessive boilerplate, I also refactor a lot of the existing AES code to use traits for different types of encryption. IMO the result is pretty neat, with each policy just denoting a few core properties and four different algorithms for asymmetric and symmetric encryption and padding.
This is very unlikely to be final, since there are still places where the AES-specific key types leak, but the PR is already large enough, and is nicely self contained.
There are technically some breaking changes here, since I remove some public exports, but for normal users this shouldn't be noticable at all.
This is obviously a scary change, but thankfully it is fundamental enough that if I managed to mess up any of the numbers or types, the tests against the .NET server would certainly break.
In other fun news, I also spent an increasingly frustrating afternoon trying to figure out where I'd messed up before realizing that my problem was that newer versions of OpenSSL actively disables SHA1 unless you set a special environment variable, producing a weird and opaque error message if you try to use it anyway. Since the .NET server uses OpenSSL, I set that in the main function of our external server tests.