On 15-11-16 03:13, Arne Schwabe wrote:
> I think that
>
> cipher_ctx_reset (ctx->cipher, tag);
>
> belongs into the encrypt block instead of the auth block.
Yes and no. It's part of the encryption, but SIV uses the auth tag as
the IV, so this function needs to be called within the scope
Am 13.11.16 um 14:14 schrieb Steffan Karger:
> Hi,
>
> Thanks for reviewing! Replies inline.
>
> On 13-11-16 17:41, Arne Schwabe wrote:
>>
>>> This boils down to the following on-the-wire packet format:
>>>
>>>-opcode- || -session_id- || -packet_id- || auth_tag || * payload *
>>
>> I am
Hi,
On Sun, Nov 13, 2016 at 08:14:05PM +0100, Steffan Karger wrote:
> I have an automated test for this in the OpenVPN-NL test suite, that now
> verifies this works in UDP and TCP modes, and also checks that the
> authentication fails if the wrong keys are used. And then there are of
> course
Hi,
Thanks for reviewing! Replies inline.
On 13-11-16 17:41, Arne Schwabe wrote:
>
>> This boils down to the following on-the-wire packet format:
>>
>>-opcode- || -session_id- || -packet_id- || auth_tag || * payload *
>
> I am pretty that opcode is *not* authenticated looking the code.
> This boils down to the following on-the-wire packet format:
>
>-opcode- || -session_id- || -packet_id- || auth_tag || * payload *
I am pretty that opcode is *not* authenticated looking the code. Which
is probably not a problem but should not be documented as authenticated.
(There is a
This adds a --tls-crypt option, which uses a pre-shared static key (like
the --tls-auth key) to encrypt control channel packets.
Encrypting control channel packets has three main advantages:
* It provides more privacy by hiding the certificate used for the TLS
connection.
* It is harder to
