Cleanup to prep for crypto #160
Conversation
…ockSize() NonceLength is enforced by some servers and needs to be a specific lenght for various security policies. MinPadding was used only in calculating the plain text block size so it was replaced with the more appropriate PlaintextBlockSize() method
Security header length is required for determining the portion of the data packet to encrypt and decrypt when utilizng security policies
The GetEndpoints service does not require a session. Some servers will reject the ActivateSessionRequest without a specific PolicyID, which is received from the GetEndpointsRequest.
| ) | ||
| } | ||
|
|
||
| // Len returns the Header Length in bytes. | ||
| func (h *SymmetricSecurityHeader) Len() int { |
There was a problem hiding this comment.
Do we still need the Len() methods? I've removed them from all other structs.
There was a problem hiding this comment.
Yes; I’ll need these two for the crypto to figure out which bytes to encrypt and which to leave plaintext.
The message header and the (A)symmetricSecurityHeaders stay plaintext and the rest is encrypted so I need a way to find that barrier in the encoded byte stream.
Obviously the Asymmertic one is more important as it’s variable length but having both makes the code easier to understand.
| @@ -51,3 +51,14 @@ func (a *AsymmetricSecurityHeader) String() string { | |||
| a.ReceiverCertificateThumbprint, | |||
| ) | |||
| } | |||
|
|
|||
| // Len returns the Header Length in bytes. | |||
| func (h *AsymmetricSecurityHeader) Len() int { | |||
There was a problem hiding this comment.
Do we still need the Len() methods? I've removed them from all other structs.
|
@dwhutchison I've invited you to the org so that we can work on a branch. |
|
Also, let me know if you need help on the secure channel logic for the server. Curious what kind of changes are required. |
|
Awesome, thanks. |
|
Closing; superseded by #166 |
A few small updates I wanted incorporated as I work on the server side of the crypto code. Currently restructuring a lot of secure channel logic to allow for incoming server connections as well as outgoing client connections. These are some of the simpler changes from #156 that won't be affected by future secure channel changes.